Cathedral vs Bazaar (Closed vs Open Development)

Raymond's metaphor contrasts development styles with different degrees of centralized coordination and exposure to distributed participation. It is not a simple closed-source versus open-source distinction.

Raymond contrasts relatively centralized, infrequently exposed development with a process that releases evolving work and invites distributed participation. The distinction is not identical to proprietary versus open-source licensing: cathedral-style development can also occur in open-source projects. Decide separately who can inspect, contribute, review, and accept changes, and how often work becomes available.

An open contribution process still needs maintainers, usable tasks, review capacity, and integration rules. More potential reviewers do not guarantee that anyone examines the difficult part. A project can combine a carefully governed core with broad experimentation around it. Choose the arrangement by the work and responsibilities rather than assuming openness ensures quality or that a critical system must be developed privately.

When to use it

When deciding between centralized planning and distributed development; when innovation has slowed under centralized control; when quality problems persist despite review processes (more eyeballs might help); when building platforms or communities where external contribution is possible.

How it can help

Choose how people inspect, contribute, review, and integrate work. Combine approaches where useful and retain clear responsibility for quality and releases.