Who Decides? Inside the Governance Experiments Shaping Open Infrastructure

In a conventional technology company, the question of who decides is answered by an org chart. When a product roadmap needs to change, a budget dispute needs resolution, or a contributor's behavior needs to be addressed, there is a chain of authority that—however imperfect—provides a mechanism for reaching a conclusion. Open infrastructure projects do not have that chart. What they have instead is governance: the sometimes formal, sometimes improvised set of structures through which communities make collective decisions.

Governance is not a glamorous subject. It does not generate the kind of attention that a new API release or a funding announcement does. But for any open-source platform or nonprofit infrastructure project operating at meaningful scale, governance is arguably the most consequential design decision the organization will make. Get it right, and the project can absorb disagreement, adapt to changing conditions, and sustain contributor energy over years. Get it wrong, and even technically excellent projects can fracture under the pressure of a single contentious decision.

The Spectrum of Models in Practice

Open infrastructure governance is not a single thing. It exists along a spectrum that runs from highly informal arrangements—where a small founding group makes decisions by rough consensus—to elaborately structured systems with elected councils, documented decision rights, and formal appeals processes.

At the informal end, many projects begin with what is sometimes called the benevolent dictator model: a founding contributor or small core team whose judgment is trusted by the community and whose decisions are accepted, even without a formal mandate. This arrangement works reasonably well in early stages, when the community is small and shared purpose is strong. It tends to break down as projects grow, because it concentrates authority in people who may not remain available, may develop interests that diverge from the broader community, or may simply become overwhelmed by the volume of decisions required.

The Apache Software Foundation's model represents one well-established alternative. Projects under its umbrella operate through Project Management Committees composed of elected contributors, with decisions made by lazy consensus—a process in which a proposal moves forward unless a formal objection is raised within a defined window. This structure distributes authority and creates a paper trail, but it also requires significant administrative overhead and can produce slow decisions in time-sensitive situations.

More recently, some projects have experimented with governance structures that incorporate token-based or stake-weighted voting, borrowed from the decentralized finance world. The appeal is obvious: a transparent, auditable mechanism for aggregating community preferences. The practical results have been more complicated. Projects that have adopted token voting frequently discover that participation concentrates among technically sophisticated contributors or early adopters, replicating the power imbalances the mechanism was intended to dissolve.

Where Governance Breaks Down Under Pressure

The real test of any governance model is not how it performs during normal operations but how it behaves when something goes wrong—a funding dispute, a values conflict, a technical fork, or a contributor whose conduct the community cannot agree how to address.

A recurring failure pattern in open infrastructure governance involves what might be called decision paralysis by process. Projects that have invested heavily in consensus-based structures sometimes find that those structures, designed to prevent unilateral action, also prevent any action. When a critical security vulnerability requires an immediate response, or when a grant deadline demands a rapid product decision, a governance model that requires broad stakeholder alignment before anything can be approved becomes a liability rather than an asset.

A research data platform operating out of a consortium of US universities experienced exactly this dynamic when a major institutional funder requested a significant change to the platform's data retention policies. The change was not unreasonable on its face, but it affected contributors from multiple institutions with different legal and ethical obligations. The project's governance structure required consensus from a working group that had not met in several months and whose membership had partially turned over. The decision process took nearly a year. The funder grew frustrated. Two smaller institutional partners quietly reduced their involvement during the interval.

Conversely, projects that centralize decision-making for the sake of efficiency can find that speed comes at the cost of legitimacy. When contributors feel that important decisions are being made without meaningful input, they disengage—first quietly, then vocally, then permanently.

Structures That Demonstrate Resilience

Among the governance models that have shown genuine durability in mission-driven contexts, a few characteristics appear consistently.

First, the most resilient projects tend to distinguish between different categories of decisions and assign different processes to each. Routine technical decisions might be delegated to individual maintainers or small working groups. Strategic decisions—about roadmap priorities, funding relationships, or major policy changes—might require input from a broader council. Crisis decisions might be handled by a defined emergency committee with a mandate to act quickly and a requirement to report back to the full community afterward. This layered approach avoids the trap of applying the same governance mechanism to every situation regardless of its urgency or stakes.

Second, effective governance structures in open infrastructure tend to have explicit mechanisms for handling contributor exit and leadership succession. Many projects operate for years without addressing what happens when a key maintainer leaves or a founding organization withdraws support. Those that have addressed it in advance—through documented succession plans, role rotation requirements, or institutional memory practices—navigate transitions with considerably less disruption.

Third, the projects that sustain contributor trust over time are generally those that make their decision-making processes visible and accessible. Not just in the sense of publishing minutes or posting proposals in a public forum, but in the sense of actively explaining decisions to people who were not in the room—why a particular direction was chosen, what alternatives were considered, and what conditions might prompt a revisit. This transparency is not merely procedural. It is what allows newcomers to trust a project's governance before they have experienced it firsthand.

The Governance Question Is Also a Mission Question

For organizations building or joining open infrastructure, governance deserves the same level of attention that is typically given to technical architecture or financial sustainability. A platform's governance model shapes who feels welcome contributing to it, how quickly it can respond to external pressures, and whether it can maintain coherence across years and across changes in leadership.

The open infrastructure community in the United States is still in relatively early stages of accumulating institutional knowledge about what governance arrangements actually work. Organizations like the Software Freedom Conservancy, the Linux Foundation, and various academic open-source program offices have begun to document lessons from projects at different stages of maturity. That knowledge base is imperfect and incomplete, but it is growing.

The question of who decides is ultimately a question about what kind of organization a project wants to be—and who it wants to remain accountable to. Answering it thoughtfully, before a crisis forces the issue, may be the most important governance decision of all.