Clear patterns have emerged from governance reviews across 72 CNCF projects, distinguishing between what the CNCF requires at each maturity level versus what the data recommends for long-term project health. This post captures those patterns as guidance for projects choosing or evolving their governance structure.

What the data shows

Governance reviews across 72 graduated, incubating and archived projects show:

Projects with maintainers from multiple organizations at sandbox entry graduate at 2.07x the rate of single-org projects (59.1% vs 28.6%).
Projects with steering committees or org-balanced voting sustain maintainer diversity longer than those without structural mechanisms.
Documentation without structural mechanisms often fails to prevent concentration. Multiple projects with well-written governance docs experienced maintainer concentration because their governance lacked org-balance voting or steering committee limits.
20% of graduated projects now show post-graduation governance concentration, all lacking org-balance mechanisms at incubation. One archived incubating project had org diversity rules on its governance committee but not its maintainer body. This data reinforces that org-balance mechanisms need to cover where the work happens, not just the governance layer.
Contributor count alone does not predict project health – governance structure, organizational diversity, and contributor pathways matter more.

Three governance models

The CNCF project template repository provides three governance templates. Each maps to a project archetype:

1. Maintainer Council

Best for: Focused, single-repo or tightly-scoped projects with a small, cohesive group of contributors.

A self-selecting council of maintainers makes all project decisions. There is no distinction between the people who write the code and the people who govern the project. Decisions are made by lazy consensus (no objections within a defined timeframe means approval) among maintainers, with formal votes reserved for disagreements or governance changes.

When it works well: – The project has a clear, bounded scope – 3-10 active maintainers who regularly collaborate – Most contributors know each other and communicate directly – Most decisions are uncontroversial and made by consensus

Key elements: – MAINTAINERS file with names, affiliations, and domains of responsibility – Documented process for adding and removing maintainers (including inactivity) – Emeritus status for maintainers who step back – Lazy consensus as the default, with defined voting thresholds for governance changes – Security response team (can be the same as the maintainer group for small projects)

When to evolve this model: If a single organization comes to dominate the maintainer list through hiring, acquisition, or attrition of external contributors, consider adding org-balanced voting or transitioning to an elected steering committee. See The transition points below.

2. Elected Steering Committee

Best for: Large projects with established contributor communities where leadership accountability to the broader community matters.

A steering committee is elected by eligible contributors and provides strategic direction, while delegating technical work to working groups or Special Interest Groups (SIGs). Elections create accountability, and term limits and company representation limits ensure diversity of perspective.

Some projects call this a Technical Steering Committee (TSC) or Governance Committee (GC) with an explicitly technical scope. Some use both a steering committee (administrative) and a TSC (technical).

When it works well:

The project has a large enough contributor base to hold meaningful elections
Multiple organizations are actively contributing
There are enough decisions and enough scope that a dedicated governance body adds value
The project benefits from separating strategic direction from day-to-day technical decisions

Key elements:

Election process with documented eligibility, nominations, and voting procedure
Term limits (typically 1-2 years)
Limitations on company representation (e.g., no more than 1-2 members per org)
Clear delegation of authority to working groups and SIGs
Documented process for removing steering members (including non-performance during term)
Public meeting notes and decision records

Why this model correlates with sustained diversity: Projects that separate governance (steering) from execution (maintainers) sustain organizational diversity longer because committee membership has organizational limits even when maintainer composition shifts. The steering committee’s organizational limits act as a structural safeguard independent of who is writing the most code.

When to evolve this model: Governance structure should match the current project scale, and that means simplifying when the project has matured or contracted. If committees have overlapping scope, working groups lack active leads, or coordination overhead slows decisions rather than improving them, it’s time to consider consolidation. Merging redundant bodies, reducing seats, or collapsing working groups with converging scope are legitimate governance transitions.

3. Federated Subproject Governance

Best for: Umbrella projects composed of multiple semi-independent subprojects, each with its own maintainers and release cadence.

A steering body coordinates across subprojects, while each subproject governs itself. The steering body handles cross-cutting concerns: shared infrastructure, brand, security response, and conflict resolution between subprojects.

When it works well:

The project is genuinely composed of distinct subprojects with different contributor groups
Subprojects have different release cadences, scopes, or user populations
Forcing all subprojects into a single governance structure would create friction
There is enough shared infrastructure or brand that coordination adds value

Key elements:

Individual subproject governance documents
Steering body with documented authority over cross-cutting decisions
Process for adding and removing subprojects
Subproject health criteria and lifecycle (active, maintenance, archived)
Clear escalation path from subproject to steering body

When to evolve this model: Federated structures should shrink as well as grow. Subprojects and SIGs that have lost active contributors, completed their scope, or converged with another group should be archived or consolidated rather than maintained as empty shells. An important part of governance is using it. For example, enforcing subproject lifecycle: dormant SIGs can create the appearance of broad governance while real work concentrates in fewer groups.

Organizational voting: A structural mechanism that works with any model

Organizational voting allocates governance votes per organization rather than per person, ensuring a company’s voting influence does not scale solely with its maintainer headcount. Limiting votes per organization – typically at one or two – prevents any single company from dominating governance through sheer numbers. This pattern has shown to be effective in preventing governance consolidation.

Org-balanced voting protects governance decisions, but it does not by itself guarantee a balanced maintainer composition. A project can have org-balanced voting while still having a majority of maintainers from one company – the mechanism ensures that this majority does not translate into proportional governance control. Projects should also decide how to scope the mechanism. In practice, effective versions of this mechanism put a limit on per-organization votes at one or two for governance decisions (steering elections, governance changes, strategic direction), while leaving technical decisions – code review, merge authority, release – with individual maintainers under lazy consensus. A limit higher than two has not proven productive: projects with six-voter limits still experienced concentration. Scope is what matters here and whether org-balance applies to all decisions or only to governance. It is most effective when paired with a contributor ladder that actively grows maintainers from outside the dominant organization.

This mechanism can also be applied to any of the three models above: a Maintainer Council can adopt it for governance decisions while keeping lazy consensus for day-to-day technical work, a Steering Committee can use org-balanced elections, and a Federated project can require org-balanced votes at the steering level.

Across 72 CNCF projects, this is the strongest observed predictor of sustained diversity. Projects without any org-balance mechanism are the most likely to experience post-graduation governance concentration.

Matching governance model to project size

The size thresholds in this table reflect how coordination changes as groups grow. Research on collaborative group dynamics – including Dunbar’s layered model of social group sizes – suggests that direct trust operates reliably in groups of roughly 5-15, while larger groups need delegation and formal structure to maintain accountability. In the CNCF data, projects with fewer than 8 maintainers overwhelmingly govern by consensus; above that, most adopt defined voting or role structures. The transition to steering committees and federated models is driven less by headcount and more by organizational complexity: multiple repos, multiple contributing companies, or concentration risk.

Project characteristic	Recommended model	Why
Single repo, 3-10 maintainers, 1-3 orgs	Maintainer Council	Low overhead, high trust. Governance should not be more complex than the project.
Single repo, 10-20 maintainers, 3-5 orgs	Maintainer Council with defined roles	Add SIG-like areas of responsibility and documented decision processes, but a full steering committee is premature.
Multi-repo, 20+ maintainers, 5+ orgs	Elected Steering Committee or Federated Subproject	The project is large enough that maintainers cannot all know each other’s work. Elections or delegation add accountability.
Umbrella of distinct subprojects	Federated Subproject	Subprojects need autonomy; the steering body provides coordination, not control.
Any project with >75% single-org contributions	Add org-balanced voting regardless of model	Without structural protections, concentration tends to persist and deepen over time.

The transition points

Projects that start with a Maintainer Council often need to evolve as they grow. The signals that a transition is needed include:

Decisions stall. When the maintainer group is too large for lazy consensus to work, or when decisions affect subgroups differently, a delegation structure helps.
New contributors can’t find a path in. If the only path to influence is “become a maintainer,” the project needs intermediate roles (reviewer, approver, SIG lead). Projects with intermediate roles produce more diverse maintainer pools because they give external contributors a visible progression path before maintainer nomination.
A single organization dominates. When one company holds a majority of maintainer seats, the governance should actively create mechanisms for other organizations to gain influence, such as company representation limits, org-balanced voting, or elections.
Subprojects diverge. When parts of the project develop their own contributor communities, release cadences, or user populations, federated governance gives them room to operate without constant coordination overhead.

What every project needs, regardless of governance model

Whether you use a Maintainer Council or an Elected Steering Committee, the following elements should be documented and actively practiced. Items marked Required are in the current application criteria; items marked Recommended are based on the governance analysis data.

Contributor Ladder

Recommended and currently Suggested at both levels

Document the path from first-time contributor to maintainer. At minimum: contributor, reviewer, approver, maintainer. Each level should have clear qualifications, responsibilities, and the process for moving up.

Strong contributor ladders tie specific, measurable criteria to each role and link eligibility to governance rights. The most effective ladders document a concrete contribution period before maintainer nomination and make the criteria visible so contributors outside the dominant organization can self-assess their readiness.

Maintainer Lifecycle

Suggested at incubation | Required at graduation

Document how maintainers are added, how they become emeritus, and how inactive maintainers are removed. Then demonstrate that the lifecycle is used – governance reviews look at MAINTAINERS file history to verify the lifecycle is practiced, not just documented.

Projects that never remove inactive maintainers accumulate names that no longer reflect the actual decision-making body. The governance analysis found multiple projects listing inactive external maintainers for years, creating an appearance of organizational diversity that did not reflect actual project governance.

Vendor Neutrality

Vendor-neutral metadata Required at incubation | Governance documentation of vendor neutrality Suggested at incubation, Required at graduation

Document how the project ensures that no single organization controls its direction. This includes leadership positions, community-owned infrastructure, open roadmap processes, and current affiliations in the MAINTAINERS file.

For projects where a single organization currently holds a majority of maintainer seats: this is common and not inherently a problem, especially for newer projects. The governance should demonstrate an intentional path toward broader participation, not just document the current state.

Decision-Making Process

Suggested at incubation | Required at graduation

Document how the project makes decisions at each level: technical decisions (PR review/merge), roadmap decisions, leadership decisions, and governance decisions. The most common gap in governance reviews is undocumented decision-making.

Security Response

Required at incubation

Document a security response process with a private reporting channel, named individuals responsible for triage, a target response time, and a disclosure process.

Code of Conduct

Required at all levels (starting at sandbox)

Adopt the CNCF Code of Conduct or a compatible project Code of Conduct. Cross-link from the governance documents.

Anti-patterns to avoid

Across the 72-project analysis, these patterns correlate with governance decline:

Anti-Pattern	What it looks like	Why it matters
Listed diversity that does not match contribution data	Maintainer list has external names but contributions are 80%+ from one org	Governance reviews check actual contribution data, not just the MAINTAINERS file.
Documented but never used	Contributor ladder, emeritus process, and election process are all documented but never applied	Governance that exists only on paper provides no structural protection.
Governance/code divergence	Steering committee is diverse but the actual code maintainers are not	Governance structures that don’t connect to who controls the code create an illusion of diversity.
No org-balance mechanism	Maintainer pool concentrates over time as one org out-invests others, with no structural check	Without org-balanced voting or steering committee organization limits, concentration tends to persist.
Lapsed governance	Steering committee terms have expired without renewal; elections are overdue	Even active projects can let governance processes lapse.

Getting started

For projects that do not yet have formal governance:

Start with the Maintainer Council template. Add a MAINTAINERS file with names, GitHub handles, affiliations, and domains of responsibility. Adopt the CNCF Code of Conduct.
Document your contributor ladder – even a simple one with contributor, reviewer, and maintainer levels. This is currently Suggested at incubation but the data strongly supports early adoption.
Consider org-balanced voting early. It costs nothing when diversity already exists and provides structural protection as the project evolves.

As the project grows, revisit the governance model. The right time to add structure is when the current model starts producing friction.

Resources

CNCF Project Template – governance templates for all three models
Org-Balanced Voting How-To – how to choose a variant, scope the mechanism, and implement org-balanced voting with any governance model
Governance Transitions How-To – when to add or simplify governance structure, common transition patterns, and bootstrapping guidance
Contributor Ladder Template – template for documenting contributor progression
Incubation and Graduation Application Templates – current criteria at each level
Governance Review Template – what reviewers evaluate
Governance Remediation Process – for projects experiencing governance challenges

Karena Angell is the Chair of the CNCF Technical Oversight Committee (TOC). The governance patterns described in this post are based on governance reviews conducted across 72 graduated, incubating and archived CNCF projects.

Related articles