Amey-Thakur 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
- 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.
- 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).
- 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.
- Automate the repetitive parts. Formatting, linting, testing, and release, so review is about design rather than mechanics (see release-management).
- 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).
- 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.