Some tidbits from Producing Open Source Software by Karl Fogel:
- Keep all discussions in the open. Avoid the temptation to discuss subjects which impact the whole project in private sidebars.
- Make it easy to get set up and running with the project right away. “It’s in alpha” is no excuse: this is the time when it’s even more important to attract users, who may turn into developers.
- Credit is the primary currency of the open source software world. Give credit in every circumstance possible, even for the smallest of contributions.
- OSS projects tend to start as benevolent dictatorships, and later morph into democracies.
- If a substantial portion of the work on a project is being done by a single company, employees of that company should not be treated any different from hobbyist developers. For example, someone hired specifically to work on that project should not be granted commit access automatically: they through the process of submitting patches to the mailing list and getting community approval before getting full commit rights.
- Announce product releases on the blog, front page of the website, mailing list, and news sites (i.e., freshmeat, rubyforge) simultaneously. Smaller announcements (e.g., date of an upcoming release) go to the mailing list only.
- Archive all discussions, with permanent URLs.
- “Open source is fundamentally a writer-responsible culture: it’s much more important to make things easy for the tens or hundreds of people who may read the bug than for the three or five people writing about it.”
- The bike shed phenomenon: it’s easier to get approval to build an atomic power plant than a bike shed. Because the power plant is so vast, expensive, and complicated, most people cannot grasp it; and rather than try, they fall back on the assumption that somebody else checked all the details before it got this far. But a bike shed everyone understands. So no matter how well-prepared your shed proposal, someone will seize the chance to show that he is doing his job by challenging the color of the bike shed and countless other small details.
- Don’t assume everyone on the project has the same motivations that you do. Some people will be really motivated to get a working release out the door; others are focused on their pet features. Some people are motivated by respect and community attention; others just want to hack on interesting code. There’s no wrong motivations, and having differently motivated people involved produce a well-rounded team. But when engaging in discussions, don’t get caught in the trap of assuming others value the same things you do.