---
name: maintainer-sustainability
description: Keep a project alive without burning out its maintainers, through scope limits, shared load, and honest signals about capacity. Use when maintenance feels like an obligation you cannot decline.
---

# Maintainer sustainability

Open source burnout comes from an asymmetry: everyone can ask and one
person must answer. Sustainability is mostly about making the project's
real capacity visible and letting the scope match it rather than
absorbing every request quietly.

## Method

1. **State the project's scope and status plainly.** Maintained,
   maintenance-only, or seeking maintainers, written where users will
   see it. Ambiguity generates expectations you never agreed to.
2. **Say no early and kindly.** A feature accepted reluctantly becomes
   permanent support work. Declining with a reason and pointing to a
   fork or plugin path is a complete answer (see feature-sunsetting).
3. **Bound the response commitment.** Publish what people can expect and
   nothing more. Unpaid maintainers do not owe a service level, and
   pretending otherwise is what breaks people.
4. **Automate the repetitive parts.** Formatting, linting, testing, and
   release, so review is about design rather than mechanics (see
   release-management).
5. **Grow reviewers before you need them.** Trust is granted gradually
   through review participation, and a bus factor of one is a project
   risk that only looks fine until it does not (see project-governance).
6. **Take real breaks and say so.** A stated pause is better than
   silence, which reads as abandonment and prompts more pings rather
   than fewer.

## Boundaries

- Sustainability practices reduce load; they cannot make an
  under-resourced project meet commercial expectations.
- Funding helps and does not by itself fix scope or time, since money
  without hours changes little.
- Some projects should be archived, and doing that deliberately is
  better stewardship than a slow fade.