[This was first published on 10/5/2006. I'm putting all of the articles I've published on here so that I'll have one place I can look for all of them.]
People often talk about a software project's bus factor -- the number of people on your project that need to get hit by a bus to leave you with no one familiar with your codebase. In the open source world, the disappearance of even one developer can herald the death of your project -- if you don't prepare in advance.
The most important thing you can do to bus-proof your project is to attract a strong developer community for it. Since open source developers usually first get involved in a project as users, you need to attract users for your project. This means that you need to create something that people want to use and then listen carefully to the user feedback -- today's user may turn out to be tomorrow's release manager.
Start by creating something that people want to use. If you create a project to scratch a particular itch, you may attract a few contributors, but unless it's something that people actually use, it will succumb to bit rot after the initial itch is scratched. Interest in something built only for its own sake can only last so long.
You'll usually work on a project that people (namely you) want to use, and your project will attract a community of users and developers, with people fixing patches and making suggestions. If you want to keep these users around, you need to keep your project in good working order. That means vetting bug reports, fixing bugs, and working on new features. Regardless of the technical level of your project's users, odds are that they see your project differently than you do, so it may take a lot of dialog to understand a user's bug report or feature request. It can be a lot of work to translate a user's feedback into something that a developer can make sense of. But listening to your users, fixing bugs that they report, and paying attention to their feature requests will keep them coming back to use your software, and in many cases make them some of your biggest proponents. They'll usually wind up bringing you -- yep, you guessed it -- more users.
Now, to be clear, I'm not advocating that you spend your valuable time fixing every tiny bug and implementing every whimsical feature that a user requests. But before your project has grown to more than 10 or 15 developers, it's usually in your best interest to at least let your users know that they've been heard. Even if your email is only to let them know that you likely won't be implementing their pet feature, you let them know that you're listening by responding to them (and drop their requests into your issue tracker so they won't get lost).
As your project attracts more users, you'll inevitably pick up the odd developer (and believe me, some of them will be odd) as part of the community that you're building around your project. The first you'll usually hear from a potential new developer is in the form of a patch to fix an existing (often trivial) bug -- be it a code bug or a minor documentation fix. Users that show up on a development discussion list with patch in hand merit careful attention, because if you determine that their patch is a good patch and you apply it promptly, you could wind up with the ongoing attention of another project contributor, and attention is the common coin of the open source world. If this new developer is clueful, understands your project and the direction you're taking it, and keeps submitting patches, you'll find yourself wanting to let him just commit their own work. If you offer him commit access to your project as soon as you determine that he'll make a good team member, he'll usually stick around for a while to help you with your project.
Now you've got a project with a thriving user community and a small community of developers. You start to dream of a large castle with your minions bowing before you, paying homage to your greatness as a project leader, making offerings of Amazon wishlist items and PayPal donations.
Stop. Right. There.
Running your project with an iron fist is no way to increase your project's bus factor -- specifically, your bus factor.
Life changes can have a drastic effect on the amount of time that you can put into your project. You might get married or have a child. If you don't have a job, you might get one. You might get hit by a bus (or a meteorite) or contract a terminal disease or, heaven forbid, actually lose interest in your project.
Relinquish control.
Build a community of developers who make decisions by consensus and you'll have a project community that is not only lacking a single human point of failure, but that has the flexibility to lose one or more committers either temporarily or permanently. This kind of community allows developers to take turns leading the project (as much as you can "lead" a project run by consensus) and is remarkably robust as developers depart and return to contribute as their time allows. This is the true hallmark of a long-lived, productive open source project.
There are many other things that you can do to make your open source project successful, but by maintaining interest, paying attention to your users, and building a strong community, you're well on your way to developing a project that will grow for years to come. Best of all, you can stop panicking every time you see an oncoming bus on the way to lunch.
Author's note: Thanks to Karl Fogel and C. Michael Pilato for reading drafts of this article.
