As long as a project has a single author, governance is simple: the author decides. As soon as other contributors arrive, however, questions appear that code cannot answer. Who can accept a change? Who chooses when to release? What happens if two maintainers disagree? Who can grant or revoke write access? Governance is the set of answers to these questions, and a project that does not write them down lives with them anyway, just implicitly.
Why write it before the problems
Governance conflicts almost always erupt at the worst moment: during a heated debate about a feature, after the founder changes jobs, when a company starts contributing heavily. If rules already exist, they are applied. If they do not, every decision becomes a matter of personal power.
Explicit governance also helps those evaluating the project from outside: an organisation that has to depend on a piece of software for years wants to know how decisions are made.
The most common models
Benevolent dictator
One person, usually the founder, has the final say on everything. The term is Benevolent Dictator For Life (BDFL). It works when that person has a clear vision, time and the community's trust.
- Pros: fast decisions, technical consistency.
- Cons: everything depends on one person; succession is an unsolved problem.
Several well-known projects moved from this model to a collegial one when the founder decided to step back.
Group of maintainers
A set of people with write access decides by informal consensus. Often each one is responsible for part of the code, documented in a file such as CODEOWNERS or MAINTAINERS.
- Pros: spreads the load, reduces dependence on one person.
- Cons: without rules for disagreements, controversial decisions stall.
Technical committee or steering council
Larger projects often separate two levels: a technical committee that decides on architecture and releases, and a body that handles non-technical matters such as funds, trademarks and the code of conduct. Members are elected by active contributors or appointed under written rules, with fixed terms.
- Pros: stability, legitimacy, representation of different interests.
- Cons: slower processes, the need for elections and minutes.
Tiered meritocracy
Some communities define a ladder of roles: user, contributor, committer, committee member. You move up through contributions recognised over time, on the proposal of someone already at the higher level.
How decisions are made
Whatever the model, concrete mechanisms are needed. The most common:
| Mechanism | How it works | When it fits |
|---|---|---|
| Lazy consensus | A proposal passes if nobody objects within a deadline | Routine decisions |
| Vote with veto | Each maintainer can block, with reasons | Risky code changes |
| Majority | Votes of eligible members are counted | Elections, internal rules |
| Proposal document | An RFC is written and discussed publicly | Architecture or API changes |
Lazy consensus is valuable because it avoids everything needing a meeting: the proposer writes «if there are no objections within 72 hours I will proceed», and silence becomes approval.
What to put in a GOVERNANCE.md
A useful governance file is not long. It must answer a few precise questions:
- Roles: which exist and what each can do.
- Access to roles: how you become a maintainer, who decides, on what criteria.
- Leaving roles: inactivity, resignation, removal for violations.
- Decisions: which mechanism is used for which kind of choice.
- Disagreements: who has the final say when consensus does not come.
- Changes to governance: how these very rules are changed.
An example of a clear rule: «A contributor becomes a maintainer on the proposal of an existing maintainer, if no other maintainer objects within seven days. Maintainers with no activity for twelve months move to emeritus status and lose write access, which they can regain on request.»
Frequent mistakes
- Copying the governance of a huge project into one with three people: it creates bureaucracy without benefits.
- Leaving write access with inactive people: it is a security risk as well as a governance one.
- Not distinguishing between those who contribute and those who pay: a funding company should not automatically gain decision-making power unless that is stated.
- Rules written but not applied: worse than no rules, because they undermine trust.
In my work, when a project asks me for an opinion on its organisation, the first question I ask is always the same: if the lead maintainer vanished tomorrow, who would hold the keys to the repository, the domain and the published packages? The answer shows how far the project is really governed.
In short
- Governance always exists: writing it down stops it becoming a matter of personal power.
- The main models range from the benevolent dictator to an elected committee, with many variants.
- Clear decision mechanisms are needed, such as lazy consensus, reasoned veto and RFCs.
- A good GOVERNANCE.md defines roles, access, exit, decisions and how disagreements are resolved.
