# Governance And Sustainability

> Keep a project and its maintainers alive over years. Use when deciding how decisions get made, writing GOVERNANCE.md or a code of conduct enforcement process, adding or removing maintainers, handling burnout or stepping away, setting up funding (GitHub Sponsors, Open Collective, a foundation), handling a fork or a hostile takeover attempt, or archiving a project responsibly. Also use for scope disputes, entitled users, and saying no well.

- Skill: `the-open-agent/governance-and-sustainability` (Agent Skill)
- Install (CLI): `npx skillmds@latest add the-open-agent/governance-and-sustainability`
- Raw SKILL.md: https://api.skillmd.com/api/skills/the-open-agent/governance-and-sustainability/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: the-open-agent (https://skillmd.com/u/the-open-agent)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/the-open-agent/governance-and-sustainability

---


# Governance and Sustainability

Most open-source projects do not die from technical debt. They die because the person
maintaining them stopped wanting to, and there was no structure for anyone else to
take over.

## Add process only when the pain is real

Governance documents for a one-person project are cosplay. Match structure to size:

| Size | Governance |
|---|---|
| 1 maintainer | None. A `Scope` section in the README is enough. |
| 2–3 maintainers | A written norm: who merges, how you break ties. A paragraph. |
| 4–10 | `GOVERNANCE.md`: roles, how maintainers are added/removed, decision process. |
| 10+, or corporate stakeholders | Formal: steering committee, voting, possibly a foundation. |

Grow into each level when the previous one visibly fails — typically at the first
disagreement nobody knows how to resolve.

## Decision-making models

- **BDFL** — one person decides. Fast, clear, and the default. Fails on bus factor and
  when the BDFL burns out or becomes unresponsive. Honest, and fine for years.
- **Consensus-seeking** — discuss until nobody blocks. Works well for 3–8 people who
  trust each other. Requires someone empowered to call the question, or threads run
  forever.
- **Voting** — for formal projects with real stakes. Slow, and adversarial by design;
  reserve it for the decisions that need legitimacy more than speed.
- **RFC process** — for user-visible changes in projects with many stakeholders. A
  written proposal, a public comment period, an explicit decision recorded in the repo.
  Adopt this when design arguments start recurring in issue threads. It is heavier
  than it looks; do not add it before you need it.

Whatever the model, **record decisions where people can find them.** An ADR
(`docs/decisions/0007-drop-node-18.md`) with context → decision → consequences takes
ten minutes and prevents the same argument in a year, with a different person.

## GOVERNANCE.md, minimal version

```markdown
# Governance

## Roles
- **Contributor** — anyone who opens a PR or issue.
- **Committer** — merge rights. Added by maintainer consensus after sustained
  contribution. Listed in MAINTAINERS.md.
- **Maintainer** — committer + release rights + CoC enforcement.

## Decisions
Day-to-day changes: one committer approval merges.
Breaking changes, new dependencies, scope changes: an issue with the `needs-decision`
label, open at least 72 hours, resolved by maintainer consensus. Any maintainer may
block with a stated technical reason.

## Adding maintainers
Nominated by an existing maintainer, approved by consensus. Criteria: sustained
contribution, good review judgment, helps other contributors.

## Removing maintainers
12 months of inactivity moves a maintainer to emeritus (no access, credit retained).
Reinstatement on request. Removal for cause requires consensus of the others.

## Scope
<What this project does and, specifically, what it does not.>
```

That last section prevents more conflict than all the rest.

## Code of Conduct, and enforcing it

Adopt [Contributor Covenant 2.1](https://www.contributor-covenant.org/) — it is
familiar to everyone and you avoid a bikeshed. The document is the easy part; the
enforcement process is what makes it real rather than decorative.

Before you need it, decide and write down: who receives reports (a real address,
monitored, not the public tracker), who investigates when the report concerns a
maintainer, and what the response ladder is — private warning → public warning →
temporary ban → permanent ban.

When enforcing:

- **Act on behavior, not on identity or intent.** "This comment violated X" is
  defensible; "you are a toxic person" is not.
- **Keep reports confidential.** Reporters are exposed; the details are not yours to
  share.
- **Respond privately first** for a first offense. Most people adjust.
- **Do not debate in public.** State the decision, then stop replying. A public trial
  harms the reporter and the project.
- **Escalate quickly for harassment**, doxxing, or threats. Ban, then document.
- **The unpopular part**: technically excellent contributors are not exempt. A
  brilliant contributor who drives away five others is a net negative, and everyone
  watching knows whether you will act.

## Saying no

The most important maintainer skill. Every accepted feature is permanent
maintenance you personally will carry.

- **Publish scope in the README.** It converts every "no" from a judgment about the
  requester into a reference to a rule.
- **Say no early and clearly.** A slow, ambiguous no wastes far more of someone's time
  than a fast one, and hurts more.
- **Give the reason, once.** Do not re-litigate a decided question; link the decision.
- **Offer the alternative** — a plugin hook, a fork, a downstream package, a
  configuration option.
- **"PRs welcome" is not a no.** If you would not merge it, say so. Otherwise you have
  invited someone to waste a weekend.

Template:

> Thanks for the proposal. I'm going to pass — supporting this means owning <X>, and
> keeping the core to <Y> is deliberate (README → Scope). If you'd like to build it,
> the `onParse` hook is the seam, and I'll link it from the README.

## Burnout

Recognize the pattern before it becomes an exit: dreading the notification badge,
resenting reasonable requests, letting the backlog grow because opening it feels bad,
guilt about all of the above. It is extremely common and it is not a character flaw.

Structural fixes, roughly in order of effectiveness:

1. **Reduce scope.** Say no more. Archive parts. Drop platform support you cannot test.
2. **Automate everything mechanical** — CI, releases, triage, formatting. See
   `ci-pipelines`, `release-engineering`.
3. **Add maintainers** — the only real fix (see `contributor-experience`).
4. **Set boundaries publicly.** "I work on this Sunday mornings" in the README
   recalibrates every expectation at once and nobody objects.
5. **Turn off notifications.** Batch. You are not on call.
6. **Take a break, and say so.** A pinned issue saying "paused until March" is
   respected; silence is interpreted as abandonment.

You owe users the license you granted them and nothing more. Every open-source license
in existence says the software is provided without warranty, and it means it.

**Handling entitlement**: some users are rude to volunteers. A single calm reply
setting the expectation — "This is maintained by volunteers; requests are welcome,
demands aren't" — is sufficient. Then stop replying, and enforce the CoC if it
escalates. Never argue with someone who is angry that free software was free.

## Funding

Money does not remove maintenance work, but it converts guilt into an obligation you
have consented to, and it can buy time.

| Model | Fits | Reality |
|---|---|---|
| **GitHub Sponsors** | Individuals | Low friction; most projects earn small amounts |
| **Open Collective** | Projects with a group | Transparent budget; needs a fiscal host |
| **Corporate sponsorship** | Projects companies depend on | Ask directly — companies often have budget and no process for finding you |
| **thanks.dev / tidelift** | Library maintainers | Aggregates small amounts from many companies |
| **Paid support/consulting** | Infrastructure projects | Real revenue; it is a job |
| **Open core / dual license** | Products with a commercial layer | Real business; changes the project's incentives |
| **Foundation** (Linux Foundation, Apache, NumFOCUS) | Multi-stakeholder infrastructure | Neutrality and legal cover; governance overhead is substantial |

Practical: put `FUNDING.yml` in `.github/` so a Sponsor button appears; state
concretely what money enables ("one day a week on this"); thank sponsors publicly; and
**do not promise features for money** unless you are running a support business —
sponsor-driven roadmaps end badly and predictably.

## Forks

Forking is a feature of open source, not an insult. When someone forks:

- **If it is a maintained alternative** — link to it. Users benefit, and the graciousness
  costs nothing.
- **If it is a hostile fork over a governance dispute** — do not fight publicly. State
  your position once, factually, and keep shipping. The community will decide, and it
  decides on merit and responsiveness far more than on rhetoric.
- **If you are the one forking** — try upstreaming first, publicly and patiently.
  Rename clearly, credit the original prominently, respect the license and the
  trademark, and state what is different.

**Trademark** is separate from copyright: an open-source license grants rights to the
code, not to the name and logo. Register the mark if the project's identity matters
commercially — this is what prevents a fork from shipping under your name.

## Stepping away

The responsible exits, best to worst:

1. **Hand over to an active maintainer.** Transfer gradually, verify identity, announce
   publicly. Never hand publishing rights to a stranger who volunteered (see
   `supply-chain-security`).
2. **Recruit from your contributor list** — post a pinned issue. It works more often
   than people expect.
3. **Archive it.** Read-only, with a README banner: status, why, the last known-good
   version, and recommended alternatives. Archiving is a gift to your users: it tells
   them the truth so they can plan.
4. **Transfer to a foundation or a relevant org**, if it is infrastructure.

The bad exit is silence — an unarchived repo with unanswered issues, a live publishing
token, and users who cannot tell whether it is maintained. If you do one thing on your
way out, put the status in the README:

```markdown
> **Status: unmaintained.** I'm no longer working on this. v4.2.0 is the last
> release and is stable. See [alternatives](link). Happy to transfer to an active
> maintainer — open an issue.
```

## Anti-patterns

- **Governance theater** — a steering committee for a two-person project.
- **A code of conduct with no enforcement process** or no contact address.
- **Never saying no**, then burning out from the scope you accepted.
- **"PRs welcome"** for changes you would never merge.
- **Bus factor of one with no succession plan**, on a project that companies depend on.
- **Ghosting** — the most common ending, and the one that hurts users most.
- **Accepting money without stating what it buys**, then feeling obligated to everyone.
- **Public arguments with users.** Nobody wins, and everyone reads it.
- **Handing over publish rights to a stranger.**
- **Treating a fork as betrayal.**