Project GovernanceCopy Anchor Link

Governance answers "who decides?" — who can merge a patch, who can cut a release, who owns the trademark, and what happens when the project outgrows its founder.

---

1. Governance modelsCopy Anchor Link

Most real projects are hybrids. Python moved from BDFL (Guido van Rossum stepped down July 2018) to an elected five-person Steering Council with PEPs as the design process. Rust has teams plus a Council plus an RFC process.

2. Roles and the contributor ladderCopy Anchor Link

Publish the criteria for each step. "N merged non-trivial PRs over M months, plus consistent review of others' work" is enough. Ambiguity reads as favouritism.

3. The documents that make it realCopy Anchor Link

4. Decision processesCopy Anchor Link

• Lazy consensus — propose on the list with a deadline; silence means consent (Apache's default).
• RFC / PEP / KEP / DEP — design documents reviewed in public before implementation. Heavy, but the written rationale survives personnel turnover.
• Quorum voting — binding votes for releases and legal matters (ASF: at least three +1s, no veto).
• Veto — ASF committers may veto code commits, but it must be justified and can be overridden by vote.
• SIG ownership — divide by subsystem so most decisions never reach the centre.

Write the removal process too. Governance that can only promote cannot handle an inactive or abusive maintainer.

5. CLA vs DCOCopy Anchor Link

Corporate contributors need employer permission either way — an employment agreement assigning IP to your employer means your hobby commits may not be yours to give.

6. Releases, versioning and EOLCopy Anchor Link

• Semantic Versioning (MAJOR.MINOR.PATCH) is the expected default. Say explicitly if you are pre-1.0.
• LTS policy: which versions get backports, for how long. Kubernetes ~12 months; Ubuntu LTS 5 years (10 with ESM); Node.js 30 months.
• Deprecation ladder: announce → warn at runtime → remove in next major. Never silently break.
• CHANGELOG generated from conventional commits, hand-curated at release time.
• Reproducible builds and signed tags so downstream can verify what you shipped.
• Deprecating a project: archive the repo, say so in the README, nominate successors.

7. Security policyCopy Anchor Link

1. Publish SECURITY.md with a private reporting channel and a GPG key.
2. Register as a CVE Numbering Authority, or route through your foundation / GitHub's CNA.
3. State your disclosure timeline. Coordinated disclosure with a fix-and-ship window is the norm; Project Zero historically used 90 days; CERT/CC uses 45.
4. Announce via a security advisory; publish the CVE and a VEX statement where possible.
5. Backport to supported branches in one release so downstream can ship without cherry-picking.

8. Forking: the escape hatchCopy Anchor Link

Forking is expensive — it splits maintainers and duplicates CI. It is also the threat that keeps single-vendor stewardship honest.

9. AntipatternsCopy Anchor Link

• Bus factor 1 with no documented release process — the condition that enabled the xz backdoor.
• Governance by press release: announcing a foundation without transferring the trademark.
• Undocumented power: maintainers who merge by fiat while advertising a community process.
• No CODEOWNERS — PRs sit for weeks because nobody knows whose job review is.
• Endless RFCs with no decider — process as a substitute for decisions.
• Unfunded maintainers expected to meet SLAs — the path to burnout.

---

See also: Foundations · Contributing · Licenses · Business models