How Open Becomes Closed - and What Might Reverse It
© Barnaby Harris, May 2026
Cathedral, Bazaar, Exchange, Fortress — the four tiers rendered as architecture. (Image created by GPT5)
Raymond’s Moment and Its Legacy
In 1997, Eric Raymond stood before a Linux conference and described two ways to build software. One he called the Cathedral: centralised, carefully planned, released only when ready. The other he called the Bazaar: distributed, chaotic, released early and often. The essay that followed became foundational text for a generation of developers, entrepreneurs, and policymakers trying to understand what open source meant and why it worked.
Raymond’s exemplars were deliberate. The Cathedral was GNU Emacs under Richard Stallman - a masterwork of careful architecture, revealed to the world in polished form. The Bazaar was the Linux kernel under Linus Torvalds - a rolling conversation among thousands of contributors, with bugs fixed in public and releases measured in days rather than years.
Raymond’s core claim was counterintuitive at the time: the bazaar produced better software, faster, because parallel debugging and evolutionary selection outperformed centralised planning.
The essay gave language to something practitioners already sensed, and that language changed what was possible. Open source moved from curiosity to credibility. Businesses built models around it. Governments wrote policies referencing it. The Cathedral and the Bazaar became shorthand for a choice that seemed to matter: open or closed, distributed or controlled.
But Raymond’s model carried assumptions that were easier to miss than to see. It was a binary: two modes, one superior. It focused on the production of software - how code gets written - rather than the operation of services or the economics of platforms. It assumed that openness and distribution naturally aligned, that a project run in the open would remain open in its effects. And it was written before the smartphone, before cloud computing, before the platform giants, before the current generation of AI. The landscape Raymond mapped has since evolved in ways his binary cannot capture.
So whilst the essay was precisely suited to its moment, and its influence was earned, the model has aged. The Cathedral and the Bazaar gave us a vocabulary for 1997; extending that vocabulary for the present is a reframing of Raymond’s work, not a refutation of it.
What follows is an attempt at that extension. The binary becomes a four-tier model: Cathedral, Bazaar, Exchange, and Fortress. Each tier has its own logic of governance, its own tempo of change, its own conditions of entry. Together they describe a landscape in which systems move - usually toward capture.
Four Shifts That Broke the Binary
Raymond wrote at the threshold of the web era. The browser wars were underway, but the internet was still primarily a medium for sharing code and conversation, not a substrate for services, commerce, and daily life. Four shifts since then have made the Cathedral/Bazaar binary insufficient.
The Rise of Standards Bodies
Some of the most consequential work in digital infrastructure happens in neither cathedral nor bazaar. The World Wide Web Consortium (W3C), the Internet Engineering Task Force (IETF), and the International Organization for Standardization (ISO) produce the specifications that make interoperability possible. HTTP, HTML, TCP/IP, Unicode - these are not software projects but normative agreements about how software should behave.
Standards bodies operate by consensus, often painfully slow. Participation requires showing up to meetings, following procedures, sustaining engagement over years. They produce documents, not code. Their governance is procedural rather than meritocratic - influence comes from participation, not contribution. This is neither the controlled artistry of the Cathedral nor the evolutionary churn of the Bazaar. It is something else: a layer that defines the rules both must follow.
Platform Economics
The 2000s and 2010s brought a new formation that borrowed the aesthetics of the Bazaar while building something quite different. Platforms like Facebook, Apple’s App Store, and Amazon Web Services offered open APIs and cultivated developer ecosystems. They spoke the language of openness. But the underlying economics were extractive: value created by developers and users flowed upward to platform owners, while switching costs accumulated downward.
This was “open” as surface, capture as structure. Network effects became a governance mechanism more powerful than any license. The app store model revealed a new tier - a marketplace where participants competed within rules set by an authority they did not control. Interoperability was required for participation, but interoperability did not mean freedom.
Cloud and Service Dominance
Raymond’s model concerned software: artefacts that could be copied, modified, and redistributed. The cloud shifted power from code to operations. When software runs on someone else’s infrastructure, access replaces ownership. The source code might be open, but the service is not.
“Open core” business models formalised the ambiguity: a free, open-source base with proprietary extensions for paying customers. Users became tenants. The freedom to fork remained in theory, but the practical cost of self-hosting - operational complexity, security burden, integration loss - made it illusory for most. The Bazaar had not disappeared; it had been paved over.
AI and Data Gravity
The current moment adds another layer of complexity. Machine learning models depend on training data, and that data is often captured rather than contributed. The resulting weights - the numerical patterns that encode a model’s capabilities - have become a new proprietary asset class.
What does “open” mean for AI? Open weights are not open training data. Open training data is not open process. A model trained on the captured outputs of millions of unwitting contributors may be released freely, but the extraction has already occurred. The Bazaar’s gift economy assumed contributors chose to give; data gravity inverts that assumption. New capture mechanisms operate in Raymond’s vocabulary while violating its spirit.
These four shifts - standards bodies, platform economics, cloud dominance, and AI - do not replace the Cathedral and the Bazaar. They reveal that the binary is now incomplete, and has become inadequate to describe where power now resides.
The Four-Tier Model
If the binary is insufficient, what replaces it? I propose four tiers, each with distinct logics of governance, change velocity, and entry conditions.
Cathedral: The Specification Layer
The Cathedral, in this extended model, is not a mode of software development but a mode of standardisation. It produces normative documents: protocols, data models, interoperability rules. Bodies like the W3C, IETF, ISO, and IEEE operate in this tier.
Governance is procedural and consensus-driven. Decisions are slow, sometimes glacially so, because they must accommodate diverse stakeholders with conflicting interests. Membership often requires institutional affiliation or sustained individual commitment. Influence accrues to those who show up, follow process, and endure.
The Cathedral’s outputs are not code but specifications that code must follow. HTML, HTTP, TCP/IP, JSON, Unicode - these define the grammar of interoperability. Their stability is a feature: systems built on Cathedral standards can trust that the ground beneath them will not shift without warning.
Entry requires participation. You cannot contribute to a W3C recommendation by submitting a pull request; you must join working groups, attend meetings, navigate procedures. This creates legitimacy - standards are not imposed by fiat - but also creates barriers. Well-resourced organisations can sustain participation; individuals and smaller groups often cannot.
Significantly, the Cathedral’s impact can be undermined because it is open to disproportionate influence. When powerful actors dominate working groups, standards can be shaped to favour incumbents. The process is transparent in principle, but attention is a scarce resource; those who can afford sustained engagement hold disproportionate influence.
Bazaar: The Implementation Layer
The Bazaar remains recognisable from Raymond’s account, but its scope is narrowed. It is the tier of implementation: code, reference software, tooling, libraries, competing approaches to the same standard. The Linux kernel, Apache projects, Kubernetes, and most of what lives on GitHub operate here.
Governance is contribution-weighted. Influence follows from code, documentation, maintenance, and community trust. Foundations like the Linux Foundation and Apache Software Foundation provide institutional scaffolding, but authority ultimately rests with maintainers - those who do the work.
Change velocity is high. Release cycles are short, experimentation is encouraged, and failure is cheap. The evolutionary logic Raymond described still operates: many variations, selection by use, rapid iteration toward fitness.
Entry requires contribution. You participate by submitting code, fixing bugs, writing documentation, reviewing pull requests. Credentials matter less than demonstrated competence and sustained engagement. This is more meritocratic than the Cathedral, but not without its own exclusions - maintainer burnout, implicit cultural norms, and the gravitational pull of corporate sponsorship all shape who thrives.
For the Bazaar, sustainability is an issue. Maintainers are often unpaid or underpaid. Corporate employers can redirect contributor priorities. Projects can be abandoned, forked acrimoniously, or captured by companies that hire key maintainers. Openness does not guarantee durability.
The Bazaar is also being reshaped from within. Practices like ‘vibe coding’ - building software through natural-language prompts to AI agents, often without the contributor reading the resulting code - and Spec-Driven Development, where the specification is the version-controlled artefact and the implementation is generated from it, both unsettle Raymond’s foundational premise. The Bazaar’s logic assumed many human eyes reviewing each other’s work; it is not yet clear what governance looks like when implementation is partly delegated to systems that are themselves controlled by Fortress actors. This is a tier in transition.
Exchange: The Operational Layer
The Exchange is the tier that Raymond’s model largely missed. It describes interoperable services and deployments that compete within shared standards or conventions, coordinated by economic incentives rather than shared code or formal specifications.
Cloud marketplaces (AWS, Azure, GCP), app stores (Apple, Google Play), API ecosystems, and payment networks operate here. Participants may not collaborate on implementations - indeed, they may be fierce competitors - but they maintain compatibility to remain viable. The rules of engagement are set by the platform or by market convention, not by consensus process or maintainer authority.
Governance is economic. The Exchange rewards what sells, scales, or reduces friction. Compatibility is enforced not by license but by business necessity: if your service cannot interoperate, customers go elsewhere. This creates a kind of discipline, but it is the discipline of the market, with all the pathologies markets produce - races to the bottom, winner-take-most dynamics, and the relentless pressure to extract.
Entry requires compatibility. You must meet the platform’s requirements, accept its terms, maintain interoperability with its ecosystem. The barrier is not procedural participation or code contribution but conformance and commercial viability.
The Exchange introduces asymmetry: platform owners set the rules that participants must follow. An app store can change its fee structure, a cloud provider can deprecate an API, a marketplace can preference its own offerings. Participants compete on a field they do not control.
Fortress: The Closed Layer
The Fortress is vertically integrated, custodial, and proprietary. It exercises tight control over data, interfaces, and internal processes. Contribution is not invited; interoperability is strategically constrained; direction is set by internal governance and commercial priorities.
Meta, Palantir, Salesforce’s core platform, most enterprise SaaS, and the walled gardens of AI systems operate here. Users interact through interfaces the Fortress defines, with data stored on infrastructure the Fortress controls. Exit is possible in principle but costly in practice.
Governance is internal. Decisions are made by executives, boards, and shareholders, not by communities or standards bodies. Change velocity is strategic - fast when competitive advantage demands it, slow when stability serves retention. The Fortress reveals what it chooses to reveal and conceals the rest.
Entry is passive. You become a customer, an employee, or an acquisition target. You do not participate in shaping the system; you use it on terms set by its owners.
The Fortress’s strength is the perceived coherence it brings users. Vertically integrated systems can deliver seamless user experiences, rapid internal iteration, and defensible economics. Its weakness is misalignment: the Fortress serves its owners’ interests, which may not coincide with users’ interests. When they diverge, users have few levers and high switching costs.
Mapping the Current Landscape
The four-tier model is not merely taxonomic. It illuminates where different parts of the digital landscape sit - and how unstable some positions are.
The web is a key part of this landscape. At the Cathedral tier, W3C specifications define HTML, CSS, and the Document Object Model. At the Bazaar tier, browser engines like Chromium and Gecko implement those specifications, with open-source communities contributing code and competing on performance. At the Exchange tier, hosting providers, content delivery networks, and advertising platforms compete within the conventions the lower tiers establish. At the Fortress tier, walled gardens like Facebook’s Instant Articles or Google’s AMP once sought to recapture content within proprietary frames.
Another is identity. The Cathedral tier is emerging through specifications like Decentralised Identifiers (DIDs) and Verifiable Credentials (VCs) at W3C. The Bazaar tier includes open-source wallet implementations and identity libraries. The Exchange tier comprises identity-as-a-service providers competing on features and price. The Fortress tier is dominated by Apple ID, Google Account, and other custodial identity systems where users have accounts but not control.
AI has an emergent place in this landscape. The Cathedral tier is nascent - the EU AI Act represents regulatory specification, but technical standards for interoperability, safety, and interpretability are immature. The Bazaar tier includes Hugging Face, PyTorch, and the ecosystem of open model development. The Exchange tier is emerging through model marketplaces and API services. The Fortress tier includes OpenAI, Anthropic, and other providers whose models are accessible only through controlled interfaces, trained on data users cannot inspect.
Some systems defy easy placement. Kubernetes began in the Bazaar but increasingly operates at Exchange dynamics: managed Kubernetes services from cloud providers commoditise the open-source project while capturing the value of operations. Android’s codebase is open (Bazaar), but Google Play Services - required for most practical deployments - is firmly Fortress. OpenAI carries “open” in its name but operates as Fortress in practice.
These ambiguities are not flaws in the model; they are features of the landscape. Systems migrate between tiers, and the direction of migration matters.
Movement Between Tiers
Systems move. The question is: in which direction, and by what forces?
The typical trajectory is toward capture. Standards enable implementations; implementations enable markets; markets consolidate toward dominant players; dominant players become fortresses. The Cathedral produces specifications that the Bazaar implements, the Exchange commercialises, and the Fortress encloses.
This is the gradient: each transition offers immediate benefits - stability, scale, convenience - while accumulating long-term costs that are diffuse and deferred. Users gain seamless experiences; communities lose control.
Capture operates at each transition:
From Cathedral to Bazaar, the mechanism is the captive reference implementation. A specification is abstract; the first credible implementation becomes the de facto standard. The clearest contemporary case is the web itself: W3C and WHATWG produce the formal specifications, but Chrome’s Blink rendering engine has become the authoritative implementation against which all others are measured. When Chrome ships a feature, the standard follows; when Chrome declines to support one, the standard withers. The specification remains nominally open, but practical authority has migrated to a Bazaar implementation controlled by a single Fortress actor.
From Bazaar to Exchange, the mechanism is operational enclosure. Open-source code can be run by anyone, but running it well requires infrastructure, expertise, and ongoing maintenance. Cloud providers offer managed services that remove operational burden - and capture operational value. “Open core” models formalise this: the Bazaar produces the base; the Exchange sells the usability.
From Exchange to Fortress, the mechanism is winner-take-most dynamics. Network effects, data gravity, and integration depth favour consolidation. As one player dominates an Exchange, it accumulates the power to change rules, preference its own offerings, and raise barriers. The marketplace becomes a fiefdom.
From Fortress back to Cathedral, the mechanism is strategic standards participation. Dominant players do not ignore standards bodies; they join them. With resources to sustain long-term engagement, Fortress actors can shape the specifications that nominally govern everyone. The Cathedral is captured not by exclusion but by disproportionate inclusion.
This cycle is not inevitable, but it is the default gradient, and reversing it requires deliberate structural choices - and those choices have costs that markets do not naturally reward.
Some counter-examples suggest resistance is possible. The GDPR functions as a regulatory forcing function, requiring Fortress actors to provide data portability and interoperability at the Exchange boundary. Projects like Matrix and Element have deliberately halted at the Bazaar tier, maintaining federation as a structural defence against capture. The Fediverse, built on ActivityPub, distributes control by design, accepting the user experience costs that come with decentralisation.
But these remain exceptions. Sustainability, scale, and user experience gaps limit their reach. The capture gradient is not overcome by good intentions; it requires architecture that makes capture structurally difficult.
The Inverse Trojan Horse
The Trojan Horse is an old metaphor for technology, and an apt one. It describes infiltration disguised as gift: something that appears beneficial but functions as a capture mechanism.
Platform economics perfected the technique. “Free” services that harvest attention and data. “Open” APIs that create dependency. Developer ecosystems that cultivate contribution while concentrating value. The pattern is consistent: enter as gift, operate as extraction. The user is not the customer but the product, or the bait.
What would it mean to invert this?
The traditional Trojan Horse infiltrates to conquer. The Inverse Trojan Horse sends the Horse into the Castle so that the captives can escape. It is infrastructure designed to enable exit, not enforce retention.
This is not merely a rhetorical inversion. In comparison to ‘capture logic’, liberation logic requires specific commitments. It must:
Enable portability. Data should be exportable in open formats, at any time, without friction or penalty. The system should make leaving easy, even if leaving is against the operator’s short-term interest.
Build on open, federated standards. No single operator should control the grammar of interaction. Interoperability should be structural, not granted as a favour to be withdrawn.
Treat switching ease as a feature. If users stay, they should stay because the system serves them, not because departure is prohibitively expensive.
Make network effects multiply options. Each additional participant should increase the value of participation and the viability of alternatives. This is harder to engineer than lock-in, but it is not impossible - email, the web, and the telephone network all achieved it.
Grow through preference. The system must be good enough to be chosen, repeatedly, by people who could leave.
These principles have structural implications. Consent must be architectural, not a policy overlay applied after the fact. Provenance must be default - users should know where data came from, who touched it, what was done. Federation must be foundational - cooperation without consolidation, interoperability without centralisation. Exit rights must be design primitives, not afterthoughts.
Unfortunately, liberation infrastructure is harder to build than capture infrastructure. Capture is the default gradient; every shortcut, every convenience optimisation, every growth hack tends toward enclosure. Liberation requires deliberate counterforce sustained over time. It requires economic models that do not depend on capture - which means it is largely incompatible with venture capital’s expectations of rapid, exponential return.
This is why most “open” projects drift toward Fortress economics. The path is well-worn and well-funded. Building the alternative requires accepting constraints that the market does not impose and that investors rarely reward.
But the alternative is not a chimera - it existed in the web before enclosure. It is email, still federated despite decades of pressure. It is the IETF’s rough consensus and running code. It is the cooperative and mutual traditions that predate digital technology and continue alongside it. Liberation infrastructure is unusual in the current landscape, but it is not unprecedented. It is a choice - structural, sustained, and difficult - but a choice that remains available.
Implications and Applications
If this model is useful, what follows from it?
Standards bodies shape what is possible downstream, and capture at this layer propagates through the entire stack. Standards work should be funded independently of Fortress interests where possible. Specifications should consider implementation and operational incentives, not merely technical elegance. The Cathedral must watch for disproportionate influence and design processes that resist it.
For open source communities the work is to name the tier you inhabit; be explicit about transitions. A project that begins in the Bazaar may be drawn toward Exchange or Fortress economics through funding, hiring, or hosting. This is not inherently wrong, but it should be visible. Governance should be designed for sustainability, not only for contribution. Recognise that Bazaar aesthetics can coexist with Exchange extraction or Fortress control; the license is not the only thing that matters.
Policy makers must be aware of the tiers and how they operate. Interoperability mandates operate at the Exchange layer, forcing Fortress actors to maintain compatibility. Data portability requirements operate at the Fortress/Exchange boundary, creating exit rights that would not otherwise exist. Standards funding operates at the Cathedral layer, shaping the specifications that govern everyone. Effective digital policy requires intervention across tiers, calibrated to where capture occurs and where liberation is possible.
Systems designers need to be aware that every architectural decision positions a system within this landscape. Building liberation infrastructure means designing against the capture gradient - choosing federation over centralisation, portability over lock-in, consent over extraction, provenance over opacity. These choices have costs: performance, usability, growth rate, funding compatibility. They are trade-offs, not free goods. But they are trade-offs that can be made, if the goal is clear.
Conclusion - Beyond the Binary
Raymond’s Cathedral and Bazaar gave us language for a pivotal moment. It clarified a choice that seemed to matter and equipped a generation to advocate for openness. That contribution deserves acknowledgment and respect.
But models are maps, not territories. The landscape has changed. The binary - open or closed, distributed or controlled - no longer captures where power resides or how it flows. The four-tier model offers a more complete map: Cathedral, Bazaar, Exchange, Fortress, each with its own logic, tempo, and conditions of entry.
This map reveals the capture gradient that pulls toward consolidation. It clarifies why “open” so often becomes enclosed, and where the points of intervention might be. It does not offer easy solutions - the gradient is real, the pressures are strong, and the path toward liberation is steeper than the path toward capture.
The Inverse Trojan Horse is not a product but a design orientation. It asks: what would infrastructure look like if it were built to enable exit rather than enforce retention? The answer involves structural commitments - consent, provenance, federation, portability - that run against the grain of platform economics.
So ultimately the question is: what are you building, for whom, and who gets to leave?