The Bazaar and the Cathedral

​In a blog post from some time ago, Penitenziagite!, I wrote about linguistic impedance in software: the way systems shout incomprehensible demands at contributing developers, forcing them to think in the wrong language. That post was about architecture as translation – the scriptorium at the centre speaking Latin for precision, and the gate speaking the vernacular so people can actually participate.

This post is about governance.

Specifically: why Ooloi is open source, but not open in the way some people expect. And why it cannot be.

The Myth of the Open-Source Bazaar

​There is a persistent belief among developers that open source implies a particular governance model. In this vision, design is open, debate is open, architecture is open, decision-making is open, and even the rewriting of foundations is treated as normal community activity. The project becomes a bazaar: a bustling marketplace of patches and opinions, competing visions and negotiated direction.

This model works for some kinds of software. It fails for others. Music notation software belongs firmly in the latter category.

The problems Ooloi addresses – temporal coordination, concurrent structural mutation, global layout decisions, semantic correctness across voices – are not decomposable into independent opinions. They cannot be negotiated piecemeal. They require conceptual unity, which is another way of saying they require architectural closure.

A bazaar cannot produce that. However, a cathedral can.

What 'Closed' Means Here

Ooloi's core is closed – but not in the sense of secrecy. The code is MPL-2.0: inspectable, forkable, modifiable. What I mean by closed is something more precise: closed in the sense of authority over semantics.

The musical model is fixed. The invariants are fixed. The staged pipeline is fixed. The authority boundaries are fixed. This does not mean that development has stopped, or that new functionality will not appear. It means that the conceptual foundations are no longer under negotiation.

Closure is not Stagnation

​A closed semantic core is often misread as a claim of finality: finished, complete, unchangeable. That is not what I mean.

What is closed is the space of permissible reinterpretation. New features will arrive, new capabilities will arrive, refinements and extensions will arrive – but they must fit within the established model rather than redefine it.

This distinction matters because most architectural failure in open projects does not come from lack of innovation. It comes from uncontrolled semantic drift: the gradual erosion of guarantees as each contributor reinterprets the foundations to suit local convenience. Ooloi explicitly forbids that drift.

Why the Core must be Closed

​Ooloi's correctness depends on architectural decisions that only work as a coherent whole.

Immutability is treated as a semantic guarantee rather than a performance trick. STM is not merely one possible concurrency implementation among several; it is the concurrency model, because the alternatives import failure modes that Ooloi is explicitly designed to eliminate. Structural sharing is not optional; it is a prerequisite for the kind of scale where a full orchestral score can be edited in real time without the system grinding to a halt. Computation is staged because global layout decisions are otherwise intractable. Piece state is single-authority because reconciliation architectures – the kind where multiple sources of truth must be merged – create exactly the class of bugs that have plagued notation software for forty years.

These are not interchangeable components. They are constraints, and constraints that reinforce each other. You cannot selectively replace one of them. You cannot introduce mutability 'for performance'. You cannot swap out the concurrency model. You cannot dissolve authority boundaries. Each such change collapses guarantees that are only meaningful because the other constraints hold.

The cathedral stands because the architecture must stand.

Why This Enables Real Openness

​Here is the paradox: by closing the core, Ooloi makes everything around it genuinely open.

Because the centre does not move, APIs stop being provisional. Semantics do not drift. Performance characteristics remain predictable. Plugin contracts remain valid across versions, which means plugin authors can build with confidence rather than anxiety about the next breaking change.

Plugins become first-class citizens rather than tolerated afterthoughts. Any JVM language can participate without translation into a single house dialect. Boundaries stay explicit. Failure modes stay contained.

This is the same pattern that made TeX durable, SQLite coherent, and the JVM stable enough to host entire ecosystems. A fixed centre enables freedom at the edges.

The Cuckoo-Chick Problem

Visibility attracts contributors. Most are helpful; some are enthusiastic but misaligned; a few arrive with expectations the project cannot and will not meet.

I have learned to recognise two failure modes.

1: Misaligned help

These contributors mean well. They propose changes that would, in effect, produce a different system entirely.

They might want the core rewritten in another language. They might want STM replaced with actors, or argue for mutability 'for performance'. They might want the semantic model redesigned, or the staged pipeline replaced with heuristics. They are not malicious – they simply assume the architecture is provisional, a starting point for negotiation rather than a finished foundation.

As you have seen, it is not.

2: The arena-seeker

Here the motivation is not technical at all. The project becomes a venue for resolving old arguments, validating preferred tools, or reenacting disputes imported from elsewhere. When the architecture does not bend, pressure escalates. When boundaries hold, frustration surfaces.

At that point refusal is often reinterpreted as hostility, silence as arrogance, and constraint as personal exclusion.

This is a category error. Refusal is governance. In Ooloi, it is exercised deliberately.

Why Refusal is Non-Negotiable

If the core were open to redesign, plugin contracts would break. Semantics would drift. Stages in the rendering pipeline would start interfering with each other. Concurrency guarantees would dissolve. Correctness would become probabilistic – which is to say, the system would regress to precisely the type of architecture Ooloi was built to escape.

By enforcing architectural closure, contributors learn where pressure will not be applied. Plugin authors learn what will not change. Users get stable behaviour. The system remains intelligible.

Boundaries are not unkind. They are protective.

Open Source Without Negotiation

​Ooloi is open source in a precise, literal sense: inspectable, forkable, extensible, durable.

It is not open in the sense of open-ended architectural debate. It is not open in the sense of consensus-driven semantics. It is not open in the sense of renegotiating authority with each new voice that arrives.

The core is not a public workshop. It is a composition. Collaborative compositions exist – devised theatre, collectively improvised music – but they are specialised forms suited to particular purposes, not universal methods. Ooloi's architecture is not that kind of work. Its structure must be fixed before others can build upon it.

The bazaar is not inside the cathedral; it is outside, at the gate, where plugins flourish without threatening the foundations.

The Gate & the Bazaar

The Penitenziagite! post argued that architecture should not shout incomprehensible demands at its users. This post argues the complement: governance should not shout incomprehensible demands at its contributors.

Ooloi's structure is explicit. There is the cathedral/scriptorium: the core, architecturally closed and semantically fixed, where the hard problems are solved. There is the library: canonical plugins and reference implementations, where patterns are demonstrated rather than debated. And there is the gate and the bazaar beyond it: the plugin ecosystem, open and multilingual and creative, but separated from the core by a boundary that preserves the integrity of the whole.

This is not a contradiction. It is a design pattern.

A stable centre enables a flourishing perimeter. A closed semantic core enables an open ecosystem. A cathedral enables a bazaar – but only if the gate between them holds.