Solo Maintainers Carry Six Projects and One Income
One person, six repositories, one salary. That arrangement is ordinary in open source, and the tooling world runs on it. This piece settles what the work actually involves, why the bus factor stays at one, and which habits and automations measurably reduce the wear. It is written for maintainers and for the teams that depend on them.
The Six-Project Maintainer Reality
A maintainer with six active repositories is not an outlier. Package managers, build systems, editors, and CI runners all depend on small projects that one person started and never handed off. The bus factor for such a project is one, and it stays one because nothing forces a second person to learn the release process.
Burnout shows up in the issue queue before it shows up anywhere else. A maintainer who stops answering triage for three weeks does not announce it; the queue simply grows. By the time contributors notice, the backlog is large enough that returning feels like a punishment rather than a task.
Funding rarely matches the load. Donations arrive in bursts, often after an outage or a security scare, then taper. The maintenance hours that prevent the next outage are the ones nobody pays for, which is why a project can be widely used and chronically underfunded at the same time.
The arithmetic is easy to underestimate. A repository with a few hundred open issues and a handful of incoming pull requests a week can absorb ten to fifteen hours of attention before any new code is written. Multiply that across six projects and the week is gone. The maintainer is not lazy or disorganized; the workload is simply larger than one person can carry without dropping something, and the thing that gets dropped is usually the work with no deadline attached.
What the Work Actually Involves
Triaging issues comes before writing code. A maintainer reads a bug report, asks for a reproduction, closes duplicates, and labels the rest. On a busy project this can consume the first hour of every working session, and none of it produces a commit.
Reviewing patches from unknown contributors is the second drain. A pull request that looks small can touch a release script or a dependency pin, and the reviewer carries the risk if it breaks downstream. Trust has to be built one merged patch at a time.
Cutting releases under time pressure is the third. A downstream project needs a fix tagged before its own window closes, so the maintainer writes a changelog, bumps the version, and hopes the CI matrix covers the platform that reported the bug.
Documentation is the work nobody pays for. It is also the work that determines whether a new contributor can help at all. Projects that skip it stay at bus factor one longer, because the onboarding cost never drops.
There is also the invisible labor of correspondence. Security reports arrive with embargo expectations, downstream maintainers ask for backports, and conference organizers request talks. None of it shows up in a commit graph, and all of it competes for the same hours. A maintainer who answers every message quickly trains the ecosystem to expect that speed, which makes the eventual slowdown look like neglect.
Bus Factor as a Design Constraint
Single-maintainer projects fail silently. There is no outage announcement, just a repository that stops receiving commits. Users keep installing the last release until a dependency breaks, and by then the original author has moved on.
Handover documents are rare and usually stale. A MAINTAINERS file listing one name is common; a file explaining the release process, the signing keys, and the infrastructure accounts is not. This site has argued that signing keys often outlive the contracts that fund them, and the same pattern applies to repository access.
Succession planning is close to nonexistent. Few projects name a backup maintainer, and fewer grant that person the permissions to act. When the primary maintainer steps away, the practical backup is a fork, which splits the user base and the issue tracker.
Forks become the de facto continuity plan. That is not a design choice so much as a default. A fork preserves the code but not the community, and the new maintainer inherits the same bus factor problem on day one.
The constraint is structural, not personal. A project with one maintainer and no documented process has effectively outsourced its continuity to chance. The fix is unglamorous: write down how a release happens, grant permissions to someone else, and accept that the second maintainer will do things differently. Insisting on your own way is how a project ends up with a bus factor of one forever.
Funding Models That Miss the Mark
Donations spike after outages and then fade. The pattern is predictable enough that maintainers plan around it, treating a surge as a short runway rather than a budget. Recurring small contributions are more useful, but they are harder to attract.
Corporate sponsorship tends to favor new features over maintenance. A company will fund a logo on a README or a specific integration, because that spend is visible. Paying someone to keep the test suite green is harder to justify internally, even though it prevents the outages that cost more.
Grants rarely cover maintenance hours. Grant programs often want deliverables, timelines, and reports, which map poorly onto the work of answering issues and reviewing patches. A maintainer who takes a grant can end up spending the funded time writing updates about the funded time.
Platform fees erode small contributions. A one-dollar donation routed through a payment processor can lose a meaningful fraction before it arrives. The aggregate effect is that micro-funding works better in theory than in practice, and maintainers notice.
There is a deeper mismatch: funders want to pay for artifacts, while maintenance is a service. A funded feature ships once and can be pointed to; a funded maintenance hour disappears into a closed issue. The result is that the visible parts of a project attract money and the invisible parts attract burnout. Some maintainers respond by bundling maintenance into feature grants, which works until the feature is done and the maintenance obligation remains.
Tools That Reduce Maintainer Wear
Automated dependency updates save hours each month. A bot that opens version-bump pull requests and runs the test suite turns a recurring chore into a review task. The trade-off is review fatigue: a project with weak tests will merge bad bumps, so the automation only pays off behind a real CI matrix.
CI matrices catch regressions early, which lowers the cost of every later decision. A release that fails on one platform during the matrix run is a five-minute fix; the same failure after tagging is a support thread. This site has covered how build caches can hide regressions until a bisect finds them, which is the failure mode automation is meant to prevent.
Issue templates cut triage noise. A form that asks for version, platform, and reproduction steps removes the first round of back-and-forth. It will not stop low-quality reports, but it makes the good ones actionable on first read.
Release automation lowers cognitive load. A script that builds, tags, and publishes removes the manual steps where maintainers make mistakes under time pressure. The cost is setup time and a new thing to maintain, which is why small projects often delay it until the second or third release.
A less obvious tool is a public status page for the project. A short note saying that triage is paused until a given date does more for contributor patience than silence does. It also gives the maintainer a boundary to point at. The habit costs almost nothing and removes the guilt of an unanswered queue.
Concrete Steps for Sustainable Maintenance
Document handover in the repository root. A file naming the backup maintainer, the release steps, and where the signing keys live turns a future crisis into a checklist. Update it when the process changes, not once a year.
Set a public maintenance window and honor it. Posting that triage happens on Tuesdays, for example, resets expectations and gives the maintainer permission to ignore the queue on other days. Contributors adapt faster than most maintainers expect.
Rotate triage duties with trusted contributors. Granting label and close permissions to two or three regulars distributes the first hour of every session and starts building the second maintainer the project lacks.
Publish a funding link in the README and keep it current. A single line near the top is enough, and it converts occasional visitors into small recurring supporters. Pair it with a note on what the money covers, such as review time or infrastructure.
Automate one repetitive task per quarter. Dependency bumps, changelog drafts, and release tagging are all candidates. The goal is not a fully automated project but a maintainer who spends the saved hour on the work only a human can do.
Finally, treat maintenance as a first-class deliverable. Write it into grant proposals, sponsorship conversations, and job descriptions. The work exists whether or not anyone funds it, and naming it is the first step toward getting it paid for.
