Thinking about starting a new open source project? Great! Thinking about hosting it yourself? Hold on there, sparky. Whether it’s an individual project, or something your company is behind, I’ve got at least four good reasons you should start the project on an established hosting site instead.
Free and open source software is all about not re-inventing the wheel. Yet one of the first things many companies and projects want to do is re-invent the wheel when it comes to project hosting. Overcoming that is a good step towards success, for many reasons. Here’s the top four.
Location, Location, Location…
You’ve heard the business adage, “location, location, location,” right? It’s as true for open source projects as it is for restaurants or shops. Yes, a really excellent restaurant can thrive in a poor location with the right combination of luck, advertising, and word of mouth — but it’s better and more effective to open up shop where traffic is good. In other words, yes — some sponsored projects draw enough interest that they can justify and sustain a separate infrastructure elsewhere. Most don’t. Leverage the existing sites to help draw interest to your project.
Likewise, why require contributors to invest time in yet another round of sign-ups, passwords, usernames, etc. just to play in your sandbox? Find a forge suitable to your project, and use it. If your most likely audience is using (primarily) Launchpad, host there (like Rackspace smartly chose to do with OpenStack). If you want to attract really strong Free Software supporters, think about using Savannah.
It’s Been Done, Better, Elsewhere
SourceForge, Google Code Hosting, Savannah, Launchpad, GitHub, Gitorious, Fedora Hosted, and many other hosting options have been available for years and already have addressed most of the problems and needs that open source projects have, from small to large. It may be possible to provide better hosting infrastructure for FOSS projects than these offerings, but it would take some doing and focus on really providing a quality service. Is that something your organization is prepared to do?
Probably not. I’ve seen a number of companies try and fail, and it can cost a project a lot of contributor goodwill and participation. There’s also danger in picking the wrong hosting provider, so choose carefully — but almost any of the well-established services should be suitable.
Tear Down the Wall
Another major problem with hosting open projects using corporate resources is that it complicates giving access to the community. Host a project on Google Code, Launchpad, or Gitorious and all the members of your community can have equal access depending on the role in the project — not whether they have a company badge.
When hosted systems mix with other corporate servers, IT is going to be hesitant to grant access to members of the project who don’t work for the company. Even when IT is willing to grant access, your project usually has to queue up with all the other requests. Something vital to a project member, like getting SSH access to make changes on a server, can be very unimportant to an overworked admin who has 500 other projects that their boss is concerned about.
Some companies handle this well, but many don’t. It’s better to have a shared infrastructure on trusted third party service than put all the eggs in the company basket.
There’s also a small matter of trust. When a company holds all the cards, it’s less encouraging for contributors who don’t get a paycheck from the company. Host a project on a third party site, and it’s clear that it will (or can) go on without the company’s engagement.
The argument many managers make for self-hosting is that the company doesn’t want to give up control. This is an argument that needs to be taken out back and shot. Participating in a FOSS project is not about retaining control, and potential users and contributors have every right to be suspicious when companies start trying to stack the deck like this.
Additional Infrastructure and Headaches
New projects require a lot of infrastructure, aside from the obvious code repository. They need Web hosting, mailing lists, IRC channels, wikis, bug trackers, and the list goes on and on. All of that needs to be set up, maintained, updated, and planned for. That requires man hours, hardware, and new processes. And it’s never-ending. As projects grow, more hardware is needed. New problems crop up. Servers need to be upgraded, security holes need to be addressed, occasionally there’s a break-in and that’s a whole lot of hassle for projects and the parent companies that need to do the clean-up. Your PR department will be thrilled to see those headlines, I’m sure.
Other companies or groups deal with hundreds or thousands of hosted projects, and have the infrastructure for dealing with the user accounts, privacy policies, legal requests, and everything else. Let them.
You can find examples of companies sponsoring hosted projects that are successful, no doubt. But it takes much more work than people expect, and often the projects fail or do less well than they could because they’re limited to the resources a single company can provide.
This isn’t to say that hosting a project on, say, Google Code is going to make it successful. Many other elements come into play. (Maybe, just maybe, the project isn’t that interesting?) But hosting with a trusted service that provides the tools a contributor community needs, plus giving all contributors equal footing, is another step towards success. Other factors, like governance, also come into play but are a little outside the scope of the hosting discussion.
If you’re starting a project, do it on the right foot and start it on Google Code, GitHub, Gitorious, or another major service. If you have an existing project that doesn’t see the kind of contributions you want, you might think about taking it where the action is.