There’s a tech talk How Open Source Projects Survive Poisonous People (And You Can Too) on Google Video, where the guys who developed Subversion and currently work at Google (the company tends to hire a bunch of open source developers including VIM creator) share their tips on running an open source project.
Here’s a synopsis of their tips, although the video is worth watching for real-life stories and anecdotes they tell.
- Don’t strive for perfection – you will end up polishing and improving and adding on instead of releasing actual software?
- Don’t “paint the bikeshed” – spend 1 day on discussing the nuclear power plant plans and spend 1 week discussing which color to paint the bike shed for the workers who ride bikes to work.
- Don’t get obsessed with the process – you’re building a product, not optimal process.
- Have a direction – don’t just try to build the best software ever, and wind up with a feature creep. Pick a direction and stick with it.
- Send people to mail archives for a discussion that already happened in the past.
- Keep documentation on design decisions, bug fixes, mistakes.
- Have developers write consistent log messages.
- Send commit e-mails – this allows everybody to be in the loop on what’s being worked on and who does what.
- Don’t let people submit mega-projects they quietly worked on for the past few months – no one can review it, no one can test it, there should be incremental commits and branches.
- Don’t let people put their names at the top of the source code files – this discourages additions and bug fixes, since people feel the file is being “owned” by the author.
- “Patches welcome” should be a reply to the users who request a variety of new features that primarily suits their own specific use case.
- Try to avoid people that genuinely would like to code, but cannot follow a self-paced learning schedule, and require hand-holding and explanations almost on every issue they face.
