Eric Raymond's

The Cathedral and the Bazaar

A Reflection

Eric Raymond's essay has a lot of insights, and he presents them convincingly. I came away from reading it wanting to convert my current project -- indeed all my software projects -- into his bazaar model. But I don't think that is likely to happen any time soon. Let me explain why.

Before getting into the main issues here, I would like to comment on a couple of provocative remarks Raymond makes that are essentially unrelated to his main thesis.

In one case he marvels at the "stunning variety, quality, and depth of Linux documentation." Like Microsoft documentation, I assume it exists somewhere, but I have been stunned only by its inaccessibility and/or irrelevance. Google can find on the internet many third-party alternatives to the Microsoft documentation fiasco, but Google is no help at all finding anything useful for how to make Linux do reasonable things -- like compile itself. That has been a continuing disappointment.

I have only admiration for Raymond's second notable remark, which he calls

the 'SNAFU Principle': "True communication is possible only between equals, because inferiors are more consistently rewarded for telling their superiors pleasant lies than for telling the truth."
I have long held that honesty is the only reasonable basis for communication and friendship, but in the circles I frequent I seem to be a lone voice crying in the wilderness. I really wish Christians could tolerate honesty as much as the pagans do.

On with the show...

There are two fundamental problems with implementing Raymond's bazaar software development model in my projects. He is aware of and mentions both problems, but he does not give them a fair treatment.


The first problem is the matter of design. He admits to the "value [of] design originality in bazaar projects." This is a refreshing admission, in stark contrast to the thinking of many other computer professionals who want to believe only in incremental evolution. Raymond himself likes to believe in evolution and used the word frequently in his essay, but the bottom line is, "Insight comes from individuals" [his emphasis]. There is no substitute for design insights.

Raymond mentions the development of the GNU Emacs editor as an instructive example; it absorbed the efforts of hundreds of contributors over 15 years, but only one person (its author, Richard Stallman) was continuously active during all that time. Raymond does not come out and say so, but that one person preserved the consistent architectural vision that Raymond did praise in the project. Similarly, it was Linus Torvalds who did the same thing for Linux, and Eric Raymond himself who provided the focus and vision driving his featured Fetchmail project.

Open source has many bazaar-like advantages over managed "cathedral" projects, but design is not one of them. You still need the lead designer with a vision for where the project needs to go and the control to make it go there. Furthermore, that designer must do much of the work to get it there before the bazaar can even work at all. Raymond admits the program must be running well enough for people to see what it can do before they will buy into it as an OS project.

Linus Torvalds adapted the idea of Minix, but completely rewrote it and had it working before Linux took off and acquired a life of its own. Eric Raymond did the same for Fetchmail. In both cases the software subsequently grew and "evolved" so that little or none of the original code is left, but the designer started essentially as a solo project. Linux and Fetchmail were both small enough that they could be done that way; my BibleTrans project is much larger -- but I am still stuck with the one-designer model. Although I can't think of any at the moment, I can imagine ideas too big and complex to be done alone in a garage on nights and weekends. Actually, BibleTrans is too big for nights and weekends. It's a full-time project spanning many years -- and it still isn't good enough to inspire a community of users, let alone co-developers.

Which brings me to


Raymond has another crucial insight that he gives scant attention to: "To make the bazaar model work, it helps enormously if you have at least a little skill at charming people." It's worse than that. The project has to scratch the itch of more than just a couple people -- and these people must be programmers -- or else open source is irrelevant.

Anybody who has gone through a college computer science curriculum can be interested in the way operating systems work, so Linux qualifies. Programmers love text-based editors like Emacs. But Raymond himself notes how hard it was to get the open-source version of Netscape going. Although it came after he wrote this essay, it would be interesting to see Raymond's observation on how it took a single guy's vision (and rewrite) to make Firefox take off.

Selling an anti-programmer operating system like my MOS to programmers is a different matter. Linux may be the the best thing since sliced bread from a programmer's perspective, but it's really hard for non-programmer types to use. This is a fundamental problem with the bazaar model. Out of 100 million evangelical Christians in America we can find only a thousand or so interested enough in Bible translation to do anything about it; good luck in finding five programmers among them!

I am not a charismatic extrovert like Raymond, my skills are elsewhere. It seems to me that the bazaar only works for hucksters. Well, I can't seem to sell my ideas to the bishop in the cathedral either.


Tom Pittman
2007 April 6