The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary

by Eric S. Raymond

Seymour Cray, designer of the Cray line of supercomputers, was among the greatest. He is said once to have toggled an entire operating system of his own design into a computer of his own design through its front-panel switches. In octal. Without an error. And it worked. Real Programmer macho supremo.

The proprietary-Unix players proved so ponderous, so blind, and so inept at marketing that Microsoft was able to grab away a large part of their market with the shockingly inferior technology of its Windows operating system.

Quality was maintained not by rigid standards or autocracy but by the naively simple strategy of releasing every week and getting feedback from hundreds of users within days, creating a sort of rapid Darwinian selection on the mutations introduced by developers. To the amazement of almost everyone, this worked quite well.

Or, to put it another way, you often don’t really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right.

Smart data structures and dumb code works a lot better than the other way around.

released early and often (almost never less often than every ten days; during periods of intense development, once a day). I grew my beta list by adding to it everyone who contacted me about fetchmail. I sent chatty announcements to the beta list whenever I released, encouraging people to participate. And I listened to my beta-testers, polling them about design decisions and stroking them whenever they sent in patches and feedback.

Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaar mode. Linus didn’t try it. I didn’t either. Your nascent developer community needs to have something runnable and testable to play with.

Human beings have an innate drive to compete for social status; it’s wired in by our evolutionary history.

The simplest way is the command hierarchy. In command hierarchies, scarce goods are allocated by one central authority and backed up by force.

Command hierarchies scale very poorly;Note 27 they become increasingly brutal and inefficient as they get larger. For this reason, command hierarchies above the size of an extended family are almost always parasites on a larger economy of a different type. In command hierarchies, social status is primarily determined by access to coercive power.

Our society is predominantly an exchange economy. This is a sophisticated adaptation to scarcity that, unlike the command model, scales quite well. Allocation of scarce goods is done in a decentralized way through trade and voluntary cooperation (and in fact, the dominating effect of competitive desire is to produce cooperative behavior). In an exchange economy, social status is...

Abundance makes command relationships difficult to sustain and exchange relationships an almost pointless game. In gift cultures, social status is determined not by what you control but by what you give away.

multi-millionaire’s elaborate and usually public acts of philanthropy. And thus the hacker’s long hours of effort to produce high-quality open-source code.

“You may not work to get reputation, but the reputation is a real payment with consequences if you do the job well.” This is a subtle and important point. The reputation incentives continue to operate whether or not a craftsman is aware of them; thus, ultimately, whether or not a hacker understands his own behavior as part of the reputation game, his behavior will be shaped by that game.

In the hacker community, by contrast, one’s work is one’s statement. There’s a very strict meritocracy (the best craftsmanship wins) and there’s a strong ethos that quality should (indeed must) be left to speak for itself. The best brag is code that “just works”, and that any competent programmer can see is good stuff. Thus, the hacker culture’s knowledge base increases rapidly.

Talking softly is also functional if one aspires to be a maintainer of a successful project; one must convince the community that one has good judgement, because most of the maintainer’s job is going to be judging other people’s code. Who would be inclined to contribute work to someone who clearly can’t judge the quality of their own code, or whose behavior suggests they will attempt to unfairly hog the reputation return from the project?

point of Brooks’s observation, and Bentley’s, isn’t merely that you should expect first attempt to be wrong, it’s that starting over with the right idea is usually more effective than trying to salvage a mess.

Above that, however, the combination of Linus’s Law and Hasler’s Law suggests there is a large-project range in which the costs and problems of traditional management rise much faster than the expected cost from duplication of effort. Not the least of these costs is a structural inability to harness the many-eyeballs effect, which (as we’ve seen) seems to do a much better job than traditional management at making sure bugs and details are not overlooked. Thus, in the large-project case, the combination of these laws effectively drives the net payoff of traditional management to zero.