A GOVERNANCE.md for a company-led project says who makes decisions, how contributors become maintainers, how disputes are settled, and what role the company plays. Write it before outside contributors arrive, keep it short, and update it as the community grows.
Definition
Governance is the set of rules for how a project makes decisions. The Open Source Guides say that growing projects benefit from formal rules, that there is no right time to write them down, and that early documentation of behavior expectations and contributor process will inevitably shape governance anyway. For a company launching a project, the Guides say an internal discussion before launch is worth having about how the company expects to maintain it and decide, and a public explanation of anything particular to the company's involvement.
Sections to include
| Section | Question it answers |
|---|---|
| Roles | What do maintainer, contributor and committer mean here? |
| Decision making | Who decides, by vote, consensus or one lead? |
| Becoming a maintainer | What is the path, and who approves it? |
| Company role | Does the company employ maintainers, hold trademarks or have special rights? |
| Conflict resolution | Who handles disputes, and how are conflicts of interest handled? |
| Security | Who receives vulnerability reports, who can publish releases? |
| Changes to governance | How is this file itself amended? |
The Guides note that roles mean whatever you define, and that you can use broad definitions to encourage more forms of contribution, including documentation and triage.
Three common models
The Guides describe three structures:
- A single lead. One person has final say, often the founder. It is fast and clear, but depends on that person.
- Meritocracy. Active contributors who demonstrate merit get a formal decision role, usually by consensus voting. The guide notes this model, pioneered by one foundation, requires contributions from individuals representing themselves, not a company.
- Liberal contribution. Those doing the most current work have the most influence, and big decisions seek consensus, not a vote.
For most company-led projects, a single lead or a small maintainer team is the honest starting point. Pretending to a community model you do not operate erodes trust.
Company-specific points to state plainly
- Whether the company can change the license, and under what conditions. See who can change an open source project's license.
- Whether paid and unpaid contributors are treated alike. The Guides say paid developers should not get special treatment, and each contribution should be judged on technical merit.
- Who owns the trademark and logo.
- What happens if the company stops funding the project. An exit plan reassures users. See archive, transfer or delete a retiring repo.
Practical safeguards
The Guides suggest moving a project from a personal account into a GitHub organization and adding at least one backup admin, so access does not depend on one person. Add that to your checklist, and require two-factor authentication for every maintainer.
Where Safeguard fits
Safeguard's policies and gates help a maintainer team enforce review rules on pull requests, and its dependency scanning keeps the project's own dependencies visible. A free scan is available at gold.safeguard.sh/scan.
Quick check
Do we need GOVERNANCE.md at launch?
There is no required time. Write down what you can at launch, especially behavior expectations and the contribution process, and expand as the community grows.
Can a company run a project under a single lead model?
Yes. Say so openly, so contributors know how decisions are made.
Sources
Last reviewed: 19 October 2026.
