Most open source projects follow one of three governance models: a benevolent dictator for life (BDFL), a meritocracy, or a liberal contribution model. The model decides who can approve changes, who can take over, and what happens if a key person leaves. Knowing it tells you which continuity risks to check.
The three models
The Open Source Guides describe them this way.
BDFL. One person, usually the original author, has final say on major decisions. Smaller projects are often BDFL by default because they have only one or two maintainers, and projects that began inside a company can fall into this category. Python is the guide's classic example.
Meritocracy. Active contributors who demonstrate merit get a formal decision role, usually by voting consensus. The guide credits the Apache Foundation with pioneering it, and says contributions are made by individuals representing themselves, not by a company. The guide also notes that the word carries negative connotations for some communities.
Liberal contribution. The people doing the most current work have the most influence, based on present work and not historic contributions. Major decisions come from seeking consensus rather than pure votes. Node.js and Rust are the examples given.
What each means for a consumer
These are interpretations, not claims from the guide.
| Model | Strength to look for | Continuity question to ask |
|---|---|---|
| BDFL | Clear direction, fast decisions | Who takes over if the lead leaves? |
| Meritocracy | Documented path to commit rights | Is the voting group still active? |
| Liberal contribution | Broad base of contributors | Is current work spread across people and organizations? |
No model guarantees safety. A committee can go quiet as easily as a single maintainer can.
How to find out which one applies
- Look for a GOVERNANCE file, and read how decisions are made and how someone becomes a maintainer.
- Check the roles named in the README or on a team page.
- Look at who merged the last twenty changes. If it is one name, the project behaves like a BDFL project whatever the document says.
- Check whether a company employs the main contributors. The guide advises corporate-origin projects to explain publicly how the company will or will not be involved.
- Check whether a foundation hosts it. For differences, see open source foundation governance models.
What to record
For each important dependency, write one line: the governance model, how many people can merge, and the date you checked. That one line makes later reviews fast.
The guide also says there is no right time to write governance down, and that it is easier once community dynamics have played out. So a young project without a governance file is normal. A large, widely used project without one is worth a question.
Next steps
If you depend on a BDFL project, read single maintainer risk. Safeguard can help with the inventory part. Its SBOM and dependency scanning lists what your projects actually pull in, so you can see which components you depend on and decide where to look closer. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is BDFL governance a security risk?
Not by itself. It concentrates decisions in one person, so check succession and whether others can release.
Do foundation projects always use meritocracy?
No. The guide credits Apache with pioneering it and says all Apache projects use it, but other foundations and projects use different models.
Sources
Last reviewed: 19 October 2026.
