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:

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

# 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 — 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 , and keeping the core to 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.

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:

> **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.