Maintainer Boundaries:Saying No Without Burning the Project

Open source dies in two ways: abandonment and burnout. Boundaries are how maintainers stay present. They are not rudeness. They are how a volunteer project remains sustainable.

This is for people who maintain tools others rely on, especially alone or in tiny teams.

Scope Is a Feature

Write down what the project is not. Feature requests that fight the scope are easier to decline when the README already said so.

A clear non-goal prevents endless debate disguised as product discovery.

You Can Close Without Drama

It is allowed to:

Close issues that lack detail after asking once
Decline PRs that expand scope
Mark something wontfix with a short reason
Ignore entitlement dressed as urgency

Be polite. Be brief. Do not write essays for every no.

Response Time Is Not a Contract

Users may depend on your software; they are not entitled to your evenings. Publish expectations: best-effort support, security channel if any, no guaranteed SLA.

Silence after a clear policy is better than guilt-driven half-replies.

Protect Review Capacity

Large drive-by PRs are expensive. Ask for small diffs. Require tests for behaviour changes. Use "needs discussion" before "needs code."

Your review time is the scarcest resource in most projects.

If the project grows, add CODEOWNERS, triage help, or co-maintainers carefully. Access is trust. Document how decisions are made so new helpers do not guess.

Handing over keys without shared norms creates new burnout.

Take Breaks Visibly

Archive, mark unmaintained, or post a hiatus note when life demands it. Users can fork or pin. Surprise disappearance hurts more than an honest pause.

Closing Thoughts

Maintainer boundaries keep the lights on. Scope clearly, decline cleanly, protect review time, and tell the truth about capacity. A smaller living project beats a large abandoned one.