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.
In other news, I’m working on a list of 2005 goals for the desktop project. It’s sometimes difficult to separate desktop goals from Gentoo-wide goals — perhaps I shouldn’t try. One is simply a subset of the other.
Gentoo does a great job of “microgoals” within individual projects, but it has trouble tying them together into distribution-wide “macrogoals.” As a result, a lot of times it seems as if we don’t have a cohesive vision to base our progress on. Improving that is a personal 2005 goal.
Over the next week or two, I’ll probably be writing more about how we can create cohesive goals and improve our development methods, and other, established open-source projects we can learn from, such as Mozilla and FreeBSD.
I picked up the Pegasos from Scott last night and didn’t delay a moment before slamming Gentoo back over its measly Debian and YDL installs.
The previous hardware problems disappeared — I compiled all night long and into today, and I heard nary a whisper from the hardware. Props to the folks at Genesi and bPlan for working with me on this and fixing the problem.
At the same time, I managed to run into a huge bug in glibc somewhere. So the system is mostly non-working at present because portage died most of the way through installing a broken glibc.
Most of my executables don’t run, and I’m afraid to log out of ssh because I don’t want to have to figure out how to get back in neatly.
In other news, I’m setting up a few VMWare installs to see how the “competition” is: Just did FreeBSD tonight, later will do Fedora and Ubuntu. Maybe others if I really get bored.