The Cathedral and the Bazaar

Eric Raymond’s 1999 essay The Cathedral and the Bazaar contrasts two ways of building software. The cathedral: a small team builds in private, releases are polished and infrequent, development is planned and controlled. The bazaar: development happens in the open, anyone can contribute, releases are early and often. It’s about open source, but the deeper argument is about how complex things get built when you can’t predict everything upfront.

The bazaar shouldn’t work

That was the conventional wisdom. You needed careful coordination, controlled access, and a master plan to build quality software. Linux proved otherwise - a loose, distributed community with no central design authority built one of the most reliable operating systems in history.

Raymond identified why. “Given enough eyeballs, all bugs are shallow” - he called this Linus’s Law. With many people looking at the code, a bug that baffles one developer is obvious to another who’s seen the pattern before. But this only works if the code is actually visible to many eyeballs. Transparency isn’t a nice-to-have. It’s the mechanism.

The other half is speed. Release early, release often. The feedback loop is the point - the faster you close the gap between what you have and what users need, the faster you converge on something good. And when you treat users as co-developers, the line between using and contributing blurs. Someone who reports a bug well is contributing. Someone who writes a patch is contributing more. The bazaar lowers the barrier and lets people self-select into the problems they care about.

I’ve seen this dynamic play out in every open source project I’ve worked on. The contributions that matter most often come from people you’d never have thought to hire. They show up because they have the problem, they have the context, and the barrier to contributing is low enough that it’s easier to fix it than to work around it. That’s a kind of intelligence a cathedral can’t access.

Two ways of thinking

The essay is about open source, but the models map onto a lot more than software licensing. I keep seeing them in how teams and organizations work.

Cathedral thinking is imperative. A small group decides what to build, plans the work, assigns the tasks, controls the timeline. It works when the problem is well-understood and the environment is stable. If you know exactly what you’re building and nothing will change, a cathedral is efficient. I’ve been on teams that operated this way, and when the problem really was well-scoped and predictable, it worked fine. Ship the spec, hit the deadline, move on.

But most interesting problems aren’t like that. Most of the time you’re building something where the requirements are shifting, the constraints aren’t fully understood, and the people closest to the work have context the planners don’t. That’s when bazaar thinking wins.

Bazaar thinking is closer to a desired state system. You declare a goal - build an operating system, create a programming language, solve this problem - and let a distributed set of contributors figure out how to get there. Nobody prescribes every step. People find the gaps and fill them. The system converges through iteration and feedback rather than top-down planning.

The reason this works in complex, uncertain environments is the same reason desired state systems beat imperative ones: reality is too messy to plan your way through. The cathedral assumes you can predict what needs to be built and in what order. The bazaar assumes you can’t - and compensates with fast feedback loops and many independent agents working on the problem simultaneously.

Agency is the mechanism

What makes the bazaar powerful isn’t just the number of people. It’s that each person has agency. Contributors choose what to work on. They scratch their own itches - Raymond saw this as a feature: “Every good work of software starts by scratching a developer’s personal itch.” The cathedral funnels all decisions through a small group and loses the distributed intelligence of everyone else. The bazaar trusts that many people, each with their own context and judgment, will find and fix problems faster than any central plan.

This is the same tension that shows up in leadership. The best teams I’ve worked with operate more like bazaars - clear goals, high autonomy, people self-organizing around the problems they’re best equipped to solve. The worst operate like cathedrals - every decision flows through a small group, contributors are assigned tasks rather than choosing them, and the distributed knowledge of the team gets wasted because nobody asked for it.

The instinct toward the cathedral is strong, especially under pressure. When things are going wrong, the reflex is to tighten control - more process, more approvals, more central coordination. And sometimes that’s right. But often it’s exactly backwards. The system is struggling because it can’t adapt fast enough, and adding control makes it slower. What it actually needs is more autonomy with better feedback - more bazaar, not less.

Where the cathedral wins

Raymond wasn’t saying cathedrals are always wrong. Some things need tight coordination. Security-critical code, protocol design, anything where consistency matters more than speed - these benefit from controlled development. You wouldn’t want a bazaar designing a cryptographic algorithm.

And the bazaar has real costs. Coordination overhead grows. Quality varies. Not every contributor understands the big picture. Linus Torvalds makes the bazaar work partly because he’s an exceptional maintainer who can hold the whole system in his head and make good judgments about what to accept. The bazaar needs taste at the center - someone who can tell good contributions from bad ones, who can maintain coherence without prescribing every decision. Without that, you get a mess. With it, you get something that adapts faster than any cathedral could.

The interesting question isn’t which model is better in the abstract. It’s recognizing which kind of problem you’re facing. Cathedral problems have clear specs, known constraints, and a stable environment. Bazaar problems have shifting requirements, distributed knowledge, and more uncertainty than any small group can reason through. Most people default to the cathedral when they shouldn’t, because the instinct to control feels safer than the messiness of trusting distributed agents to converge on something good.

The default

I think Raymond’s deepest observation isn’t about open source specifically. It’s that we systematically underestimate how well distributed, autonomous, loosely coordinated systems work - and systematically overestimate how much central planning is needed.

This is a bounded rationality problem. No small group has enough information to make all the decisions. The cathedral is a bet that the planners know enough. The bazaar is a bet that they don’t - and that the collective intelligence of many agents, each with local context, will outperform central planning in complex environments. That bet keeps winning, in open source, in organizations, in markets. And people keep being surprised by it, because the cathedral feels so much more legible and controllable.

The mess is the feature. It’s what makes the system adaptive.