How Open Source Projects Are Governed

Why Governance Matters

Open source code is publicly available, but that does not mean anyone can change it. Every project needs rules about who can merge code, who decides the technical roadmap, and what happens when contributors disagree. Without clear governance, projects rely on implicit power structures, which usually means the original author or the most vocal participants make all decisions. This works for small projects but breaks down as a community grows, because newcomers have no way to understand how to influence the project or earn trust.

Good governance also protects against external risks. If a project's sole maintainer becomes unavailable, a governance structure that distributes authority prevents the project from stalling. If a company tries to exert undue control over a project that others depend on, governance rules can prevent that concentration of power. And when contributors disagree about technical direction, governance provides a process for resolution that does not depend on whoever argues the loudest or threatens to fork the project.

Benevolent Dictator for Life (BDFL)

The BDFL model places final decision-making authority in a single person, typically the project's creator. The term was coined to describe Guido van Rossum's role in the Python community, though Linus Torvalds' leadership of the Linux kernel is the most prominent example. The "benevolent" and "for life" parts of the title are descriptive rather than contractual: the dictator is expected to act in the community's interest, and they hold the role as long as they choose to (or until they step down, as van Rossum did in 2018).

The BDFL model's strength is efficiency. When a single trusted person has final authority, decisions can be made quickly without the overhead of committee deliberation or community voting. The BDFL can resolve disputes definitively, maintain a consistent technical vision, and cut through debates that might otherwise stall a project. For Torvalds, this authority allows the Linux kernel to release new versions every nine weeks, incorporating thousands of changes per cycle, with a speed that would be difficult to achieve through committee governance.

The model's weakness is the single point of failure. When the BDFL becomes unavailable, burns out, or makes a decision that alienates a significant portion of the community, there is no institutional mechanism for transition. Python addressed this when van Rossum stepped down by creating a Steering Council elected by core developers, effectively transitioning from BDFL to committee governance. The Linux kernel has not yet faced this transition, and questions about succession remain an open concern in the Linux community.

A variant of this model is the "BDFL delegate" pattern, where the leader formally delegates authority for specific areas to trusted individuals. Torvalds delegates to subsystem maintainers who have final authority over their portions of the kernel, creating a hierarchy of trusted decision-makers rather than a single bottleneck. This delegation structure allows the BDFL model to scale to much larger projects than a single person could review directly.

Technical Steering Committees

Technical steering committees (TSCs) distribute authority among a small group of experienced contributors. This model is used by Node.js, Kubernetes, and many CNCF projects. TSC members are typically elected or appointed based on their contributions and technical expertise, and the committee makes decisions about the project's technical direction, reviews proposals for major changes, and resolves disputes that cannot be settled by individual maintainers.

The TSC model provides more resilience than BDFL governance because authority is not concentrated in a single person. If one committee member steps down or becomes unavailable, the others can continue making decisions. The committee also provides a natural forum for discussing cross-cutting concerns that affect multiple parts of the project, something that individual subsystem maintainers might not address on their own.

The challenge with TSC governance is decision-making speed. Committees require discussion and either consensus or voting, which takes longer than a single person making a call. Committees can also develop internal politics, factions, and gridlock if members have conflicting priorities (especially when they represent competing companies). Well-designed TSC charters address this with clear voting procedures, quorum requirements, and term limits that prevent stagnation.

Node.js provides an instructive example. After a community crisis in 2014-2015 that led to a fork (io.js), the reunified project adopted a TSC governance model with documented procedures for decision-making, a clear contributor ladder (contributor, collaborator, TSC member), and explicit rules about how corporate interests should be balanced against community interests. This restructured governance stabilized the project and restored contributor confidence.

The Apache Way

The Apache Way is the governance philosophy of the Apache Software Foundation, and it has influenced open source governance far beyond the 320+ Apache projects that follow it directly. The Apache Way is built on several interconnected principles that together create a distinctive community culture.

Community over code means that a healthy, diverse, self-governing community is more valuable than any particular codebase. A project with excellent code but a toxic or single-vendor community is considered less successful than a project with adequate code and a thriving multi-stakeholder community. This principle directly affects how the ASF evaluates projects for incubation and graduation: technical quality is necessary but not sufficient, and community health is the primary criterion.

Earned authority (often called meritocracy, though some ASF members have moved away from that term) means that influence in a project is earned through sustained, constructive participation. Anyone can contribute to an Apache project, but commit access, voting rights on releases, and membership in the Project Management Committee (PMC) are earned by demonstrating competence, reliability, and community-mindedness over time. Corporate title, seniority, or financial contributions do not translate into authority within the project.

Transparency means that all significant decisions must happen on public mailing lists. Private discussions, even among PMC members, are discouraged for anything that affects the project's direction. The rationale is that community members who are not present in a private conversation cannot contribute their perspective, and decisions made privately lack the legitimacy that comes from public deliberation. This principle is enforced by the ASF board, which can intervene if a project's PMC conducts too much business off-list.

Consensus means that decisions are made by agreement rather than majority vote. In practice, Apache projects use "lazy consensus," where a proposed change is considered approved if no PMC member objects within a defined time period (usually 72 hours). Formal votes are reserved for releases, new committer nominations, and other significant milestones. This approach works because most decisions are uncontroversial, and the formal vote mechanism provides a backstop for cases where consensus genuinely cannot be reached.

Democratic Governance

Some open source projects adopt formal democratic governance with constitutions, elections, and defined legislative processes. Debian is the most prominent example. The Debian Constitution, adopted in 1998 and amended several times since, establishes a Debian Project Leader (DPL) elected annually by the body of Debian Developers, a Technical Committee for resolving technical disputes, and a General Resolution process that allows the developer body to vote on any question by supermajority.

Debian's governance has been tested by several significant controversies, including the decision to adopt systemd as the default init system (which was resolved through a General Resolution after the Technical Committee's initial decision proved divisive) and ongoing debates about the relationship between Debian's free software principles and the practical needs of users who depend on non-free firmware. The formal democratic process has allowed these debates to be resolved through structured deliberation rather than community fracture, though the processes can be slow and contentious.

The Rust programming language underwent a significant governance transition in 2022-2023. After operating with a de facto BDFL structure through its early years at Mozilla and then a period of informal team-based governance, the Rust community created a formal Leadership Council composed of representatives from each of the project's top-level teams (compiler, language design, library, infrastructure, and others). This council handles cross-team coordination, resource allocation, and project-wide policy, while individual teams retain authority over their domains.

Corporate-Led Governance

Many commercially important open source projects are governed primarily by the company that created them. Android (Google), React (Meta), VS Code (Microsoft), and Swift (Apple) are examples of projects where the sponsoring company employs most core contributors, controls the roadmap, and makes final decisions about the project's direction. External contributions are accepted, but the company's priorities shape what gets built and when.

Corporate-led governance is efficient and well-resourced, but it carries risks for the broader community. If the company changes strategic direction, the project may be abandoned or taken in a direction that does not serve external users. If the company uses its control to disadvantage competitors, the project's neutrality is compromised. The tension between corporate control and community interests has led to several high-profile forks: MariaDB from MySQL (after Oracle's acquisition of Sun), LibreOffice from OpenOffice.org (also related to Oracle), and OpenTofu from Terraform (after HashiCorp changed its license).

To mitigate these risks, some companies preemptively transfer governance to a foundation. Google's donation of Kubernetes to the CNCF and Facebook's donation of GraphQL to the GraphQL Foundation are examples of companies recognizing that foundation governance increases community trust and participation, even though it means giving up some control.

Choosing a Governance Model

The right governance model depends on the project's size, community composition, and goals. Small projects with a single primary author typically start with informal BDFL governance and do not need more structure until they grow. Mid-size projects with multiple regular contributors benefit from a documented decision-making process, even if it is as simple as "the maintainers decide by consensus, with the original author breaking ties." Large projects with commercial participants almost always need foundation governance or at least a formal charter to ensure that no single company dominates.

The most important governance principles are consistent regardless of model: document how decisions are made, create a clear path for contributors to earn authority, conduct significant discussions in public, enforce a code of conduct, and build a succession plan so the project does not depend on any single person's continued involvement.