A good article on how to ensure that your open source project continues even if you get hit by a bus:
IT Manager's Journal | How to "bus-proof" your open source project
| Quote: |
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. (continued) |