Scrolls
4 min read
On this page

Governance Models

Governance is how decisions get made. In a small project, governance is invisible: the maintainer decides everything, and nobody questions it because the project is small enough that one person's judgment works. As projects grow, invisible governance breaks down. Disagreements arise that cannot be resolved by one person's authority. Contributors want a say. Companies want predictability. Users want stability. The governance model you choose determines who has power, how decisions are made, and what happens when people disagree.

BDFL: Benevolent Dictator For Life

The BDFL model concentrates decision-making power in a single person, usually the project's creator. The title is tongue-in-cheek, but the power is real. The BDFL has final say on all decisions, from code style to project direction.

How BDFL works:

  Decision process:
    1. Community discusses an issue or proposal
    2. Contributors offer opinions and suggestions
    3. The BDFL decides
    4. The decision is final

  Power structure:
    BDFL
      |
      v
    Core contributors (advisory, no veto power)
      |
      v
    Contributors (submit code, file issues)
      |
      v
    Users (use the project, report bugs)

Real-World BDFL Examples

Python (pre-2018):
  Guido van Rossum was Python's BDFL from 1991 to 2018.
  He made final decisions on PEPs (Python Enhancement Proposals).
  The model worked for 27 years because Guido was widely trusted
  and his judgment was consistently good. He stepped down after
  the contentious PEP 572 (walrus operator) debate exhausted him.
  Python then moved to a steering council model.

Linux (ongoing):
  Linus Torvalds is the BDFL of the Linux kernel. He delegates
  subsystem decisions to trusted lieutenants but retains final
  authority over what gets merged into the mainline kernel.
  The model works because Linus focuses on technical excellence
  and has a deep understanding of the entire codebase.

Vim (ongoing):
  Bram Moolenaar was Vim's BDFL from its creation until his
  passing in 2023. His death raised urgent questions about
  succession in BDFL-governed projects.

Strengths & Weaknesses

Strengths:
  - Fast decisions: no committees, no voting, no delays
  - Consistent vision: one person's taste shapes the whole project
  - Clear accountability: everyone knows who decides
  - Works well for small to medium projects

Weaknesses:
  - Bus factor of one: if the BDFL leaves, the project is in crisis
  - Scales poorly: one person cannot understand every part of a large project
  - Can become autocratic: contributors may feel their input does not matter
  - Succession is hard: who replaces an irreplaceable leader?

Meritocracy

In the meritocratic model, those who contribute the most have the most influence. Decision-making power is earned through sustained, quality contributions. The Apache Software Foundation popularized this model and calls it "community over code."

How meritocracy works:

  Contributor ladder:
    User        — uses the project
    Contributor — submits patches, files bugs
    Committer   — earned commit access through sustained contribution
    PMC Member  — earned project management committee membership
                  through sustained committer-level contribution

  Decision process:
    1. Proposal is made on the mailing list or in an issue
    2. Committers and PMC members discuss
    3. Consensus is sought through lazy consensus (see decision-making)
    4. If consensus cannot be reached, PMC members vote
    5. PMC chair has a tiebreaker vote but rarely uses it

Real-World Meritocracy Examples

Apache Software Foundation:
  Over 350 projects follow the Apache Way. Every project has a
  PMC that oversees its direction. PMC membership is earned, not
  appointed. The Foundation provides legal and infrastructure
  support but does not direct individual projects.

  Notable Apache projects: Kafka, Spark, Hadoop, Airflow, Cassandra

PostgreSQL:
  Core team of 5-7 people, all long-term contributors. Committer
  access is earned through years of contribution. Decisions are
  made by consensus among committers. The core team handles
  administrative tasks and has final authority on disputes.

Strengths & Weaknesses

Strengths:
  - Power is earned, not inherited or appointed
  - Encourages sustained contribution
  - Distributes knowledge across multiple people
  - Scales better than BDFL for large projects

Weaknesses:
  - "Merit" is subjective and often biased
  - Favors people with more free time (often those with privilege)
  - Can create an old guard that resists new ideas
  - Contribution is measured in code, undervaluing docs, design,
    community management, and other non-code work

The word "meritocracy" itself has become controversial. Critics argue that what projects call meritocracy often reflects existing privilege rather than pure merit. The Apache Software Foundation continues to use the term but has acknowledged these concerns.

Committee Governance

In committee governance, an elected or appointed group makes decisions collectively. This model adds structure and accountability compared to BDFL, and avoids the bias concerns of pure meritocracy by using formal elections.

How committee governance works:

  Structure:
    Governing body (council, TSC, core team)
      - Elected by contributors or appointed by the previous body
      - Serves fixed terms (typically 1-2 years)
      - Makes decisions by consensus or majority vote

  Decision process:
    1. Proposal submitted (RFC, issue, discussion)
    2. Community discussion period
    3. Committee reviews and discusses
    4. Committee votes or reaches consensus
    5. Decision documented and communicated

Real-World Committee Examples

Rust:
  Governed by the Rust Leadership Council (replaced the core team
  in 2023). The council consists of representatives from each
  Rust team. Teams handle domain-specific decisions (compiler,
  language design, documentation). The council handles cross-team
  decisions and project-wide governance.

  Rust teams: compiler, lang, libs, cargo, docs, release, infra, etc.

Node.js:
  The Technical Steering Committee (TSC) governs the project.
  TSC members are elected by existing TSC members and active
  contributors. The OpenJS Foundation provides legal and
  administrative support.

Python (post-2018):
  After Guido van Rossum stepped down, Python adopted a steering
  council of 5 members elected by core developers. The council
  serves one-year terms and can be re-elected. PEPs still drive
  the proposal process, but the council makes final decisions
  instead of a BDFL.

Strengths & Weaknesses

Strengths:
  - Distributes power across multiple people
  - Formal elections provide legitimacy and accountability
  - Fixed terms prevent entrenchment
  - Clear decision-making process reduces ambiguity

Weaknesses:
  - Slower decisions: committees need to convene, discuss, vote
  - Bureaucratic overhead: elections, term limits, process documents
  - Committee members may not represent the broader community
  - Risk of gridlock when members disagree
  - Political dynamics: factions, campaigning, lobbying

Foundation-Backed Governance

In foundation-backed governance, a legal entity (a non-profit foundation or consortium) provides the governance structure, legal protection, and often funding for the project. The foundation may employ staff, hold trademarks, and manage finances.

The foundation sits above the project's technical leadership, providing legal entity for holding trademarks, fiscal sponsorship for donations, event organization, infrastructure, conflict resolution, and sometimes employing staff who work on the project full-time.

Real-World Foundation Examples

Linux Foundation:
  Hosts Linux, Kubernetes, Node.js, and hundreds of other projects.
  Annual budget exceeds $250 million. Employs staff, organizes
  KubeCon and other conferences. Member companies include Google,
  Microsoft, Amazon, Intel, and most major tech companies.
  Projects maintain their own technical governance; the Foundation
  provides the umbrella.

CNCF (Cloud Native Computing Foundation):
  A Linux Foundation project that hosts Kubernetes, Prometheus,
  Envoy, Helm, and other cloud-native projects. Projects go
  through a maturation process: sandbox, incubating, graduated.
  Graduated projects meet strict criteria for governance,
  security, and community health.

Apache Software Foundation:
  One of the oldest open source foundations (1999). Hosts 350+
  projects. All projects follow the Apache Way (meritocratic
  governance). The Foundation provides legal protection, including
  patent defense. Notable for its consensus-driven culture.

OpenJS Foundation:
  Hosts Node.js, jQuery, Electron, webpack, and other JavaScript
  projects. Formed from the merger of the Node.js Foundation and
  the JS Foundation in 2019.

Foundation governance provides legal protection, neutral ground, sustainable funding, and trademark protection. The downsides are bureaucratic overhead, potential capture by large corporate members, and a level of structure that smaller projects may not need.

No Governance

Many small projects have no formal governance at all. The creator does whatever they want, and there is no process for resolving disagreements beyond "it's my project."

No governance works for solo projects, small user bases, personal tools shared publicly, and early-stage projects. It breaks when contributors disagree on direction, companies depend on the project, the maintainer disappears, or the community grows beyond what one person can manage. The transition to formal governance is often triggered by a crisis. It is better to adopt lightweight governance before you need it than to scramble during a crisis.

Choosing a Governance Model

Project size and maturity -> recommended model:

  Solo hobby project:
    No governance. You decide. Keep it simple.

  Small project (2-5 contributors):
    Informal BDFL. Document who has merge access and how
    decisions are made, even if it is just "the creator decides."

  Medium project (5-20 regular contributors):
    Lightweight committee or documented BDFL with a clear
    succession plan. Write a GOVERNANCE.md file.

  Large project (20+ contributors, corporate users):
    Formal committee governance with elections, terms, and
    documented processes. Consider foundation backing.

  Critical infrastructure (used by thousands of companies):
    Foundation-backed governance with legal protection,
    professional staff, and corporate membership.

Common Pitfalls

  • No governance until it is too late. When the first major disagreement happens, there is no framework for resolving it. People argue about the decision and the process simultaneously. Adopt lightweight governance early.

  • Copying a large project's governance for a small one. Kubernetes governance has dozens of SIGs, working groups, and formal processes. Your 500-star project does not need that. Match governance complexity to project size.

  • BDFL who cannot delegate. A BDFL who reviews every PR and decides every issue becomes a bottleneck. Good BDFLs delegate most decisions and only intervene on project-defining choices.

  • Meritocracy that only values code. If "merit" means "lines of code," you exclude contributors who write documentation, manage community, design UX, or do project management. Define merit broadly.

  • Foundation governance as a silver bullet. Joining a foundation does not solve community problems. It provides structure and resources, but toxic culture, unclear direction, and burnout persist regardless of the legal entity.

Key Takeaways

  • BDFL governance works well for small to medium projects where one person's vision drives the project. It is fast but fragile, with a bus factor of one.
  • Meritocratic governance earns decision-making power through contribution. It scales better than BDFL but can entrench existing contributors and undervalue non-code contributions.
  • Committee governance distributes power formally through elections and terms. It provides legitimacy and accountability but adds bureaucratic overhead.
  • Foundation-backed governance provides legal protection, funding, and neutral ground for large projects. It is the right choice for critical infrastructure but overkill for small projects.
  • No governance is fine for small projects but breaks at scale. Adopt lightweight governance before you need it, not during a crisis.
  • Match governance complexity to project size. A 500-star project does not need a steering council and bylaws.