How to Be a Good Open Source Maintainer

A competent outsider shows up with a small, clean fix. They’ve read the contributing guide and written a test; the diff is easy to review. What happens next decides whether they ever come back, and whether the next 10 people who would have followed them ever start.

Nobody defends what usually happens next. Letting a PR rot isn’t a decision anyone makes, and the silent close is rarely malice. These are the defaults of overload: most popular open source runs on one unpaid person, and a queue with one server always has the latency of that person’s worst week. The contributor forming a permanent opinion of your project can’t see which week they landed in.

You can’t fix that by promising to be more present, because you’d already be present if you could. You fix it by building a project that stays responsive on your worst week. The good news: the list of changes that keep good contributors coming back and the list of changes that make the project lighter to carry turn out to be the same list. Three moves do most of the work: stop being the only person who can answer, put every decision somewhere public, and make the on-ramp cheap enough that the load can actually be shared. Then there are 2 things you write down once so they stop costing you anything at all: your AI rule and your exit.

Why good maintainers go quiet

Nadia Eghbal’s Working in Public lands on one structural fact: the scarce resource in open source is maintainer attention. Most projects are drowning in issues and PRs while the attention to process them belongs to almost nobody. Tidelift’s 2024 survey of 437 maintainers counts the almost-nobody: 60% of maintainers are paid nothing for the work, and 61% of those unpaid maintainers have no co-maintainer at all. Meanwhile the job keeps growing; the same survey found time spent on security work nearly tripled, from 4% of maintainers’ time to 11%. So the typical open source maintainer of the code you depend on is one unpaid person whose job got bigger this year.

Maintainers owe you nothing, and I mean that literally. Rich Hickey put it flatly: “you are not entitled to the attention of others.” And if someone is rude, Mike McQuaid’s advice is the right advice: block them and move on.

Anyway, a clean “no” survives overload just fine, it’s cheap. What overload destroys is the “no” itself: the answer degrades from “no, because” to “no” to nothing, and silence is the one response a contributor can’t learn anything from. The person emitting that silence is usually closer to the exit than their commit graph shows. In a Sonar survey, 58% of maintainers had either quit a project (22%) or seriously considered it (36%). When they named reasons, competing life and work priorities came first (54%), but loss of interest was nearly tied at 51%, ahead of burnout at 44%. That near-tie matters for everything below: this is a motivation problem as much as a capacity problem, and a productivity checklist alone won’t hold.

Stop being the only one who can respond

The retention lever is the first human reply, and it arrives much later than the dashboards claim. A study of 111,094 pull requests across ten large projects, from Kazi Amit Hasan and colleagues, found just over 80% got a first response within a day. Sounds responsive, except roughly 70% of the responses that arrived inside 10 minutes were bots (a CLA check, a CI label). The first time a human says something specific about the work is often weeks out, if it comes at all. The same study measured what a same-day human reply is worth: a newcomer who got one was about 15% more likely to ever contribute again at the median project, and the effect held in every project studied. For a thing that costs one sentence, that’s a lot of retention.

You will not become that reply by trying harder, because your bad weeks set the ceiling. The way out is more than one possible responder, and the first responder doesn’t need the merge button: a triager who acknowledges the PR and asks one clarifying question is a real human response. Project Jupyter structures this directly: Carol Willing has described a “Red Team” of more-active maintainers and a “Blue Team” of less-active ones, with people free to move between them.

That’s the double duty this whole post is chasing. A wider pool of responders keeps a contributor’s PR from hanging on any one person’s week, and the Blue Team is where you rest without feeling like you’ve abandoned the project. If money ever shows up, spend it in the same direction: more than half of paid maintainers have 2 or more co-maintainers, versus the mostly-solo unpaid ones, so the highest-return purchase is a second responder rather than more hours from the first one.

Decide in public, with a reason

A rejection...