The Cathedral and the Bazaar

Linux is subversive. Who would have thought, even five years ago, that a world-class operating system could coalesce as if by magic out of part-time hacking by several thousand developers scattered all over the planet, connected only by the tenuous strands of the Internet?

Certainly not I. By the time Linux swam onto my radar screen in early 1993, I had already been involved in Unix and open-source development for ten years. I was one of the first GNU contributors in the mid-1980s. I had released a good deal of open-source software onto the net. And I thought I knew how it was done.

Two Models of Software Development

I believed that the most important software 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, 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. As I learned my way around, I worked hard not just at individual projects, but also at trying to understand why the Linux world not only didn't fly apart in confusion but seemed to go from strength to strength at a speed barely imaginable to cathedral-builders.

The Mail Must Get Through

I began my serious testing of the bazaar theory with a project called fetchmail. I needed a POP3 mail client. What I found on the net wasn't quite what I wanted. But I didn't just sit down and start designing a new one from scratch. Instead, I considered which of the existing tools came closest, and I decided to build on one of them — a program called "popclient."

The first important lesson: Every good work of software starts by scratching a developer's personal itch. Perhaps this should have been obvious, but too often software developers spend their days grinding away for pay at programs they neither need nor love. But not in the Linux world.

Another lesson: Good programmers know what to write. Great ones know what to rewrite (and reuse). I was not trying to be original. I was trying to be effective. The most efficient way to get somewhere is often not to build a road, but to find one that already goes in the right direction.

Linus's Law

I think the crucial turning point was when I realized that by treating my users as co-developers, I was getting rapid feedback on my code that was almost as good as having many collaborators working in parallel.

Linus was directly aiming to maximize the number of person-hours thrown at debugging and development, even at the possible cost of instability and of the codebase becoming a mess. Linus was behaving as though he believed something like this:

Given enough eyeballs, all bugs are shallow. I call this "Linus's Law." More formally: Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

The difference in perspective is illuminating. In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've worked them all out. In the bazaar view, you assume that bugs are generally shallow — or at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers.

Lessons from the Bazaar

Over the course of developing fetchmail, I distilled many lessons. Here are several that resonate far beyond software:

Release early. Release often. And listen to your customers. The bazaar model demands short release cycles. The more rapidly you release, the more quickly users can spot problems, and the more effectively you can iterate.

If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. People want to contribute. They want to feel that their feedback matters. Give them that, and they will surprise you with the quality of their contributions.

To solve an interesting problem, start by finding a problem that is interesting to you. Motivation matters enormously. The best work comes from people who genuinely care about the problem, not from people who are merely competent.

Perfection in design is achieved not when there is nothing more to add, but when there is nothing more to take away. When your code is getting both better and simpler, that is when you know it's right. And in the process, the design will evolve into something more elegant than any single mind could have planned.

Beyond Software

The cathedral and the bazaar are not just two ways to build software. They are two ways of thinking about any creative or collaborative endeavor. The cathedral says: plan everything, control everything, trust only the experts. The bazaar says: start with something, share it widely, let the crowd find the problems and contribute the solutions.

The lesson of the bazaar is perhaps the most radical of all: that when you give up some control, the result can be better than anything you'd have achieved alone.

Based on the essay by Eric S. Raymond, first presented at the Linux Kongress in 1997. Excerpted and adapted for educational purposes.