The Cathedral and the Bazaar, Eric Raymond’s classic essay on open-source software development, is now 10 years old. I first read it soon after its publication. At that time the term “open source” was newly minted, and the movement was in the news chiefly because (a) it seemed to offer a threat to Microsoft, and (b) Netscape, at a late stage of its war with Microsoft, had decided to release its browser code under open-source license. I was editing Salon’s technology section in those days, and one of our central projects was Andrew Leonard’s thorough coverage of the open-source phenomenon. (He interviewed Raymond in early 1998.)
I think it’s fair to say that today CatB (as Raymond and others now call the essay) has proved its importance independent of its place in the long-concluded browser-war saga. I’ve reread it several times over the years since, and each time find something new and valuable.
In CatB Raymond identifies two different styles of open-source development:
I believed that the most important software (operating systems and really large tools like the Emacs programming editor) needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time. Linus Torvalds’s style of development — release early and often, delegate everything you can, be open to the point of promiscuity — came as a surprise. No quiet, reverent cathedral-building here — rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches (aptly symbolized by the Linux archive sites, who’d take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles. The fact that this bazaar style seemed to work, and work well, came as a distinct shock.
One of the most common misconceptions about the essay is to equate the “cathedral” approach with closed source. The line from cathedral to bazaar is actually orthogonal to the line from open source to proprietary software. There are plenty of examples of open-source “cathedrals.” And though it’s hard to imagine instances of true closed-source “bazaars,” there are enough examples of extensible proprietary software products with thriving communities of users building new functionality on top of the proprietary code to see the “bazaar” principle at work in some limited form, even in the closed-source world.
Raymond argued that the bazaar style exemplified by the Linux project represented a new methodological advance for software development. With a horde of volunteer developers collaborating across the Net, Brooks’ Law could be transcended, and large quantities of programmer brainpower could be harnessed without getting stuck in the tar pit. “Given enough eyeballs, all bugs are shallow.”
It’s important to note that Raymond explicitly excluded the initial work of a project from this principle:
It’s fairly clear that one cannot code from the ground up in bazaar style [IN]. 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.
When you start community-building, what you need to be able to present is a plausible promise. Your program doesn’t have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the foreseeable future.
Today the concepts in CatB — like ” 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),” and “Release early, release often” — have become commonplaces in the field. And a significant number of large open source projects have built on them.
Today’s rapid evolution of Web-based applications seems often to be built on open-source infrastructure foundations (the “LAMP” stack, with variations like Ruby on Rails). But it’s not clear to me that “Web 2.0” has produced many bazaars itself. Or maybe they just haven’t attained sufficient scale or prominence to have landed on my radar.
In a recent blog posting, Ted Leung (a developer and manager on the Chandler project that served as the central story of Dreaming in Code) discussed the many looming difficulties of developing what he calls “Rich Internet Applications” (RIAs). Leung, a longtime participant in the Apache project and a confirmed believer in open source methods, considers the available toolsets for RIA developers: AJAX is popular but, he says, a “nightmare” for cross-platform development. Adobe’s Flash/Flex is far less nightmarish. Trouble is, it’s proprietary.
To me, this suggests that, whatever other benefits the open source bazaar approach may have conferred on the world of Web development today, it has not provided solutions to the next wave of problems today’s developers confront. Not yet, anyway!
[tags]code reads, eric raymond, open source, cathedral and the bazaar, software development[/tags]
Post Revisions:
There are no revisions for this post.