The mythical (open-source) man month?

It turns out that 10 to 12 developers on a project may well be the optimal number for maximum efficiency and productiveness. No surprise, then, that all open-source projects of which I'm aware have 15 (or fewer) core developers. So why do we in the open-source world often make so much of the "thousands of eyeballs?"

Because open source is not about aggregating a community to work on the code, but rather an array of communities to work on code. Open source works, even when a project becomes big, by staying small.

I therefore found this blog entry on software development (via Zack Urlocker) from Bob Warfield fascinating:

Mark Masterson reminds us that people have been saying for a long long time in places like the Mythical Man Month book that system design integrity is best achieved through the work of a single mind. The alternative is design by committee, which dooms us to understanding by committee and all the inefficiency and waste that goes along with that approach...Abstractions properly constrain the performance and functionality bottlenecks of a system to make them more comprehensible. Yet how often do we really focus on making architectures or code understandable? In what actionable way is that something you can measure and act on?

So far, the best answer is simply to use fewer people and live with what they can get done. It will automatically lead to simplifications and abstractions that act as firewalls. On the other side of the firewalls are initially very simple implementations, but they are placeholders. Some chief architect decided an abstraction was needed so that there would be a place to stand with a big enough lever to move the software's world should it be necessary.

(Good) Open source follows this principle by divvying up complex software into manageable, modular chunks that small groups (of 10 to 12 developers, generally) can tackle. When we speak of a globally developed Linux kernel, for example, we're not literally talking about thousands of developers holding hands to work on the same line of code at the same time. We're talking about each of these developers scratching individuals itches as part of a larger whole.

These disparate developers bring particular needs, talents and interests, and the melding together of these different developers makes for a richer project. That's the benefit of open source for development.

Also, the more people that focus on the "grunt work" of bug finding and fixes, the more time the core developers can spend doing...core development. Open source, then, is doubly efficient in parceling out development tasks. Proprietary software can attempt to replicate this, but it has difficulty matching the bug-fixing pool of any successful open-source project.

So, if you're starting an open-source project, your goal should be to keep your software modular enough that you never need development-by-committee. Even massive projects can offer bite-sized problems for developers to tackle. That's the open-source way.