I’m looking at some other projects for examples of how they run things, in addition to referring to a few books I’ve got lying around. For anyone interested, the books are Free/Open Source Software Development, a collection of papers edited by Stefan Koch, and The Cathedral and the Bazaar.
Here’s a few of the major points, some drawn from Koch’s book. Many of them may seem self-evident, but they’re easy to forget about when you’re trying to figure out what to do with 250+ developers.
- Developers prefer more loosely controlled projects with a flat hierarchy, relying on individual autonomy, tacit norms and self-organization rather than commands, control and explicit rules. FreeBSD and Mozilla projects rely on requesting contributors to follow rules of conduct rather than technical control mechanisms, although Mozilla was moving toward a strongly controlled modular setup.
- On a related note, the release plans are the only plans. There are no plans on more detailed levels and no timetable for the contributions that will eventually lead to the next release.
- Community testing is essential for finding and removing bugs. Keeping the developer and user communities close-knit aids bug-fixing, as ESR writes: “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.” Despite resistance from some users who want to remain purely users, we need to keep our community cohesive between developers and users to get the benefits of the open-source model.
- Openness is a primary principle. In nearly all cases, code, lists, bugs, and tests are available to everyone.
- A key motivation factor for contributors is quickly seeing the results of their work. We need to keep the bureaucracy required to contribute from becoming too complicated and time-consuming, or we will lose potential developers.
Next time, I’ll talk a little bit about each project’s rules and recommendations.
Striving for greatness 