Sustainable Maintenance

Building an open source project is the easy part. Maintaining it is the hard part. The initial excitement of launching carries you through the first few months: stars are climbing, issues are flowing in, people are using your work. Then the novelty fades. The stars plateau. The issues keep coming, but now they feel like obligations instead of validation. You realize that maintaining a popular open source project is an unpaid part-time job that you cannot quit without consequences.

The Maintenance Burden

Most people who start open source projects do not anticipate what maintenance actually looks like. Building a feature takes days. Maintaining it takes years.

What maintenance actually involves:

  Responding to issues
    Bug reports, feature requests, support questions, duplicates.
    A project with 1,000 users might get 5-10 issues per week.
    Each one needs triage, a response, and often a follow-up.

  Reviewing pull requests
    Reading code, testing changes, requesting modifications,
    explaining why something cannot be merged.
    A single PR review can take 30 minutes to 2 hours.

  Keeping dependencies updated
    Security patches, breaking changes in upstream libraries,
    new language versions, new OS versions.
    Dependabot opens 10 PRs per week. Each one needs review.

  CI/CD maintenance
    Build systems break. Test runners update. Cloud providers
    change their free tiers. GitHub Actions deprecate versions.

  Documentation updates
    Every new feature needs docs. Every breaking change needs
    a migration guide. Every FAQ needs updating.

  Community management
    Answering questions on Discord, moderating discussions,
    welcoming new contributors, handling conflict.

  Release management
    Writing changelogs, tagging releases, publishing packages,
    testing on multiple platforms.

The Scale Problem

Maintenance burden by project popularity:

  10 stars     — manageable as a hobby, a few issues per month
  100 stars    — starting to feel like work, weekly issues
  1,000 stars  — part-time job, daily issues and PRs
  10,000 stars — full-time job, but you are not getting paid
  100,000 stars — a team effort, impossible for one person

The effort does not scale linearly with users. It scales worse.
More users means more edge cases, more platforms, more
configurations, more opinions about how things should work.

Setting Boundaries

Sustainability starts with boundaries. Without them, the project consumes every available hour and then demands more.

Response Time Expectations

Set explicit expectations about how quickly you will respond. Document them in your README or CONTRIBUTING.md so users know what to expect.

Example response time policy:

  ## Response Times
  This project is maintained in my free time. Please expect:
  - Issue triage: within 1 week
  - Bug fix PRs: reviewed within 2 weeks
  - Feature PRs: reviewed within 1 month
  - Feature requests: may take months or may be declined

  I do not provide guaranteed SLAs. If you need production
  support, consider [commercial alternatives / sponsoring].

This is not rude. It is honest. Users who understand the constraints are more patient. Users who need faster response times can contribute or sponsor.

Scope Limits

Not every feature request belongs in your project. Saying no is one of the most important skills a maintainer can develop.

Valid reasons to decline a feature request:

  "This is outside the scope of this project."
    The project is a markdown parser. Adding a built-in web server
    is not in scope. Suggest a plugin or a separate project.

  "The maintenance cost is too high for the benefit."
    Adding Windows support when 98% of your users are on Linux
    triples your CI matrix and testing burden.

  "This conflicts with the project's design philosophy."
    The project is deliberately minimal. Adding every requested
    feature would turn it into something nobody asked for.

  "We don't have the expertise to maintain this."
    Adding GPU support sounds great, but if nobody on the team
    knows CUDA, it will rot immediately.

"Won't Fix" Is Okay

Some bugs are not worth fixing. Some feature requests will never be implemented. Closing issues with a clear explanation is better than leaving them open indefinitely, giving false hope.

How to close an issue kindly but firmly:

  "Thanks for reporting this. After consideration, we've decided
  not to fix this because [specific reason]. If this is critical
  for your use case, you might want to look at [alternative] or
  maintain a fork with this change.

  I'm closing this issue, but if the situation changes in the
  future, feel free to reopen with new context."

Sindre Sorhus, who maintains over 1,000 npm packages, is a master of polite but firm issue closure. His responses are consistently kind, explain the reasoning, and suggest alternatives. This approach protects his time without alienating users.

Avoiding Burnout

Open source burnout is not a personal failing. It is a structural problem. When the demands of unpaid work exceed the maintainer's capacity, burnout is inevitable. The solution is not to try harder. It is to change the structure.

Warning signs of maintainer burnout:

  - Dreading opening GitHub notifications
  - Feeling guilty about unresponded issues
  - Resenting users for asking questions
  - Working on the project out of obligation, not enjoyment
  - Neglecting personal health, relationships, or paid work
  - Snapping at contributors in code reviews
  - Fantasizing about mass-closing all issues and archiving the repo

Take Breaks

You are allowed to take breaks. You are allowed to not respond for a week. You are allowed to go on vacation without announcing it. If your project cannot survive a two-week absence, that is a structural problem to fix, not a reason to never take time off.

How to take a break:

  Short break (1-2 weeks):
    Pin a message on your repo: "Maintainer away until [date].
    Issues and PRs will be reviewed when I return."
    Disable GitHub notifications on your phone.

  Long break (1+ months):
    Find a co-maintainer to handle critical issues.
    Set up a bot to auto-respond to new issues with a note
    about reduced activity.
    Accept that some issues will go stale. That is fine.

  Indefinite break:
    See succession planning. Transfer ownership or archive.
    It is better to archive than to let a project rot.

The single most effective defense against burnout is having multiple maintainers. A project with one maintainer is fragile. A project with three maintainers is resilient.

How to share the load:

  Identify regular contributors
    Who has submitted multiple PRs? Who answers questions
    in discussions? Who reviews other people's PRs?

  Invite them as collaborators
    Give them triage access first (label and close issues).
    Then review access (approve PRs).
    Then write access (merge PRs).
    Then full maintainer status.

  Define responsibilities
    "You own the CLI module. You decide what gets merged there."
    "You handle issue triage on Mondays and Wednesdays."
    Clear ownership prevents diffusion of responsibility.

  Document processes
    The release process, the review checklist, the triage workflow.
    If only you know how to do a release, you can never take a break.

Say No

Saying no is not selfish. It is necessary. Every yes is a commitment of future time. Maintainers who say yes to everything eventually burn out and say no to everything by disappearing.

Things you are allowed to say no to:

  - Feature requests that do not align with the project's vision
  - PRs that are well-intentioned but poorly implemented
  - Support requests that belong in Stack Overflow
  - Requests for free consulting disguised as bug reports
  - Demands for immediate attention from users who do not contribute
  - Speaking engagements, conference appearances, podcast interviews
  - "Quick" integrations with every framework and platform

The Myth of the Solo Maintainer Hero

The open source narrative celebrates solo maintainers: one brilliant developer who single-handedly builds and maintains a project used by millions. This narrative is harmful because it normalizes an unsustainable model.

Solo maintainers who hit the wall:

  core-js (Denis Pushkarev)
    Used by 90% of websites through transitive dependencies.
    Maintained by one person who asked for financial support
    and was largely ignored. Eventually posted appeals for
    help that went viral, exposing how much critical
    infrastructure depends on unpaid solo maintainers.

  Babel (Henry Zhu)
    The JavaScript compiler used by virtually every major project.
    Zhu was the sole full-time maintainer for years, funded
    through donations that barely covered living expenses.
    He wrote extensively about open source burnout.

  curl (Daniel Stenberg)
    Used by billions of devices. Maintained by Stenberg for 25+
    years. He manages it alongside a full-time job and has been
    open about the unsustainability of the model. Other
    contributors help, but the project's continuity depends
    heavily on one person.

  left-pad (Azer Koculu)
    An 11-line npm package that broke the entire JavaScript
    ecosystem when its single maintainer unpublished it in 2016.
    Demonstrated the fragility of depending on solo maintainers.

The fix is not to find more heroic individuals. It is to build projects with multiple maintainers from the start, fund maintenance through sponsorships or foundations, and normalize the idea that maintaining open source is real work that deserves compensation.

Sustainable Pace Over Heroic Sprints

Sustainability means working at a pace you can maintain indefinitely, not sprinting for three months and then burning out for six.

Sustainable pace practices:

  Time-box your open source work
    "I spend 5 hours per week on this project, max."
    Track your time. When you hit the limit, stop.

  Batch similar work
    Triage all issues on Monday. Review PRs on Wednesday.
    Write docs on Friday. Context switching kills productivity.

  Automate repetitive tasks
    Stale bot for abandoned issues. Auto-labeling with GitHub
    Actions. Automated releases. Dependabot for dependency
    updates with auto-merge for patch versions.

  Lower the bar for releases
    Ship small releases frequently instead of massive releases
    rarely. Smaller releases mean less risk and less pressure.

  Celebrate what you have built
    It is easy to focus on the growing issue count and forget
    that your project helps thousands of people. Step back
    occasionally and appreciate the impact.

Common Pitfalls

Treating every issue as urgent. Not every bug is critical. Not every feature request is important. Triage ruthlessly. Most issues can wait. Some should be closed immediately.
Feeling personally responsible for every user's experience. You built a free tool. You are not their on-call support team. It is okay for users to hit rough edges. It is okay for them to switch to a different project.
Growing the scope instead of the team. Adding features without adding maintainers is a recipe for burnout. Before saying yes to a new feature, ask whether you have someone to maintain it long-term.
Ignoring the warning signs of burnout. If you dread opening GitHub, that is a signal to change something, not to push through. Burnout does not get better by trying harder.
Comparing yourself to full-time maintainers. Some maintainers work on open source full-time with corporate backing. You are doing it in your spare time. Different situations require different expectations.

Key Takeaways

Maintenance is harder than building. The initial excitement fades, but the issues, PRs, and support requests keep coming. Plan for the long haul, not the launch.
Setting boundaries is not rude. Explicit response time expectations, scope limits, and "won't fix" decisions protect your time and set realistic user expectations.
Burnout is a structural problem, not a personal failing. The fix is sharing the load, taking breaks, and saying no, not trying harder.
The solo maintainer hero is a myth that normalizes unsustainable work. Build projects with multiple maintainers and document everything so no single person is a bottleneck.
Sustainable pace means working at a rate you can maintain indefinitely. Time-box your work, automate repetitive tasks, and ship small releases frequently.