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

by Eric S. Raymond

I discuss these theories in terms of two fundamentally different development styles, the “cathedral” model of most of the commercial world versus the “bazaar” model of the Linux world.

Every good work of software starts by scratching a developer’s personal itch.

Good programmers know what to write. Great ones know what to rewrite (and reuse).

“Plan to throw one away; you will, anyhow.” (Fred Brooks, The Mythical Man-Month, Chapter 11)

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. So if you want to get it right, be ready to start over at least once.Note

If you have the right attitude, interesting problems will find you.

When you lose interest in a program, your last duty to it is to hand it off to a competent successor.

Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

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

If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.

The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.

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

“Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.”

When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!

When your language is nowhere near Turing-complete, syntactic sugar can be your friend.

A security system is only as secure as its secret. Beware of pseudo-secrets.

A bazaar project coordinator or leader must have good people and communications skills. This should be obvious. In order to build a development community, you need to attract people, interest them in what you’re doing, and keep them happy about the amount of work they’re doing. Technical sizzle will go a long way towards accomplishing this, but it’s far from the whole story. The personality you project matters, too.

To solve an interesting problem, start by finding a problem that is interesting to you.

Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

software project management has five functions: To define goals and keep everybody pointed in the same direction To monitor and make sure crucial details don’t get skipped To motivate people to do boring but necessary drudgework To organize the deployment of people for best productivity To marshal resources needed to sustain the project

open-source developers are volunteers, self-selected for both interest and ability to contribute to the projects they work on (and this remains generally true even when they are being paid a salary to hack open source.) The volunteer ethos tends to take care of the “attack” side of resource-marshalling automatically; people bring their own resources to the table. And there is little or no need for a manager to “play defense” in the conventional sense.

Which brings us neatly to the question of motivation. An equivalent and often-heard way to state my friend’s point is that traditional development management is a necessary compensation for poorly motivated programmers who would not otherwise turn out good work.

There are, in general, three ways to acquire ownership of an open-source project. One, the most obvious, is to found the project. When a project has had only one maintainer since its inception and the maintainer is still active, custom does not even permit a question as to who owns the project.

The second way is to have ownership of the project handed to you by the previous owner (this is sometimes known as “passing the baton”).

The third way to acquire ownership of a project is to observe that it needs work and the owner has disappeared or lost interest.

There are reasons general to every gift culture why peer repute (prestige) is worth playing for:

First and most obviously, good reputation among one’s peers is a primary reward.

Secondly, prestige is a good way (and in a pure gift economy, the only way) to attract attention and cooperation from others.

Thirdly, if your gift economy is in contact with or intertwined with an exchange economy or a command hierarchy, your reputation may spill over and earn you higher status there.

In conflicts over open-source software we can identify four major issues: Who gets to make binding decisions about a project? Who gets credit or blame for what? How to reduce duplication of effort and prevent rogue versions from complicating bug tracking? What is the Right Thing, technically speaking?

As benevolent-dictator projects add more participants, they tend to develop two tiers of contributors; ordinary contributors and co-developers.

A co-developer who accepts maintainance responsibility for a given subsystem generally gets to control both the implementation of that subsystem and its interfaces with the rest of the project, subject only to correction by the project leader (acting as architect).

The tragedy of the commons predicts only three possible outcomes. One is the sea of mud. Another is for some actor with coercive power to enforce an allocation policy on behalf of the village (the communist solution). The third is for the commons to break up as village members fence off bits they can defend and manage sustainably (the property-rights solution). When people reflexively apply this model to open-source cooperation, they expect it to be unstable with a short half-life. Since there’s no obvious way to enforce an allocation policy for programmer time over the Internet, this model leads straight to a prediction that the commons will break up, with various bits of software being taken closed-source and a rapidly decreasing amount of work being fed back into the communal pool. In fact, it is empirically clear that the trend is opposite to this.

Part of the answer certainly lies in the fact that using software does not decrease its value. Indeed, widespread use of open-source software tends to increase its value, as users fold in their own fixes and features (code patches). In this inverse commons, the grass grows taller when it’s grazed upon.

It may be more to the point that this value is not merely hard to capture, in the general case it’s hard to even assign.

In analyzing this kind of cooperation, it is important to note that while there is a free-rider problem (work may be underprovided in the absence of money or money-equivalent compensation) it is not one that scales with the number of end users (see the endnote on Note 31 for discussion). The complexity and communications overhead of an open-source project is almost entirely a function of the number of developers involved; having more end users who never look at source costs effectively nothing. It may increase the rate of silly questions appearing on the project mailing lists, but this is relatively easily forestalled by maintaining a Frequently Asked Questions list and blithely ignoring questioners who have obviously not read it (and in fact both these practices are typical).

The real free-rider problems in open-source software are more a function of friction costs in submitting patches than anything else. A potential contributor with little stake in the cultural reputation game (see Chapter 3) may, in the absence of money compensation, think “It’s not worth submitting this fix because I’ll have to clean up the patch, write a ChangeLog entry, and sign the FSF assignment papers...”. It’s for this reason that the number of contributors (and, at second order, the success of) projects is strongly and inversely correlated with the number of hoops each project makes a contributing user go through. Such friction costs may be political as well as mechanical.

One reason has to do with symmetry. While most open-source developers do not intrinsically object to others profiting from their gifts, most also demand that no party (with the possible exception of the originator of a piece of code) be in a privileged position to extract profits.

The market mechanisms for funding (and making a profit from!) open-source development are still evolving rapidly.