How to Be a Good Open Source Maintainer

Most open source runs on one unpaid maintainer, and the silent close is the default. How to build a project that answers contributors on your worst week.

Ally Piechowski · · 11 min read
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 costs one sentence. “This doesn’t fit the project’s scope, but thanks for the detailed write-up” is the same decision as a silent close with a completely different signal attached: the contributor can learn from it or argue with it instead of just leaving.

I watched the silent version up close in a plugin project I contribute to. Three PRs from the same outside contributor, closed within a 3-second window, no comment on any of them, in the same session where a maintainer’s own PRs were getting merged. Two hours later a third person asked, on the record, why they’d been closed without resolution. That question has never been answered. The 3-second window is the tell (nobody evaluates 3 pull requests in 3 seconds); a queue was being emptied, and everyone subscribed to those threads watched it happen.

Karl Fogel’s rule prevents most of this: decisions belong in archived, public channels. If the real conversation happened in Discord, summarize it back onto the PR before you close it. I’d extend the rule from decisions to plans. Publish the roadmap and the scope, however rough, because it does 2 jobs at once: your closure reasons stop evaporating (closing an out-of-scope PR becomes a link instead of an essay), and beginners can find right-sized work you actually want before they spend a weekend on work you don’t.

The on-ramp has to be real

Two-tier process teaches a good contributor that the gate is about who they are rather than what they wrote: outsiders get branch protection, required review, and a 2-week wait, while insiders self-merge in seconds. On that same plugin project, I pulled the last 100 closed PRs and grouped them utilizing GitHub’s author_association field (search API, 2026-07-09): insiders had a 79.8% merge rate, true outsiders 16.7%. Nearly a 5x gap, in a repo whose README asks for contributions.

Closing the gap is mostly self-discipline. Utilize the same branch protection you point at outsiders, and get one other set of eyes on your own non-trivial changes; the cooling-off it forces on you is small compared to the credibility it buys. I see the same dynamic in legacy codebases I audit: when most commits go straight to main and review is something that only happens to other people’s pull requests, the project’s real standard is “trust the in-group,” and everyone outside the group can feel it.

The checks have to be real too. Same project again: CI ran on every PR and came back green every time, because useJUnitPlatform() was never configured in the Gradle build. Every module’s test task discovered 0 tests and reported BUILD SUCCESSFUL, across the whole monorepo. Contributors were trusting a badge that had never once executed a test. This is super easy to check: break a test on purpose and make sure something goes red. Then keep one local command that reproduces what CI does, so a contributor can reach green before pushing instead of pushing into a black box.

Additionally, price the first contribution honestly:

In fairness to maintainers, the largest study of PR abandonment (SayedHassan Khatoonabadi and colleagues, 265,325 pull requests) found the obstacles contributors cite most are on their own side, time and shifting priorities, with review friction close behind. You can’t fix their calendars. The cheap on-ramp is you fixing the half you control.

This section is also where the load-sharing comes from. The newcomer who lands a first merge because the path was walkable is the person who takes triage off your plate a couple years from now.

Make it survivable for you

This all assumes I still want to maintain the thing. What if I don’t?

The survey numbers say that’s the normal case, and no checklist answers it. Three moves help anyway, because they shrink the project to fit whatever interest you have left.

Narrow the scope to the part you still care about, in writing. If the plugin ecosystem around your core grew past your interest, say so in the README and mark those areas as seeking owners. A smaller project you like maintaining beats a complete one you dread opening.

Hand off whole areas to the people who keep showing up, and mean it: their name in CODEOWNERS, their finger on the merge button. Half-delegation, where you still re-review everything, is just review with extra steps.

Stop treating open issues as personal debt. An issue is a public record of a known thing. Labeled honestly (“known, low priority, patch welcome”), it can sit for a year without you owing anyone a Friday night.

None of this guarantees the interest comes back. John-David Dalton has talked about burning out on Lodash; his recovery took years and included false starts, and he’s still here. Walking away is a legitimate ending, and the last section is about doing it well, but it isn’t the only ending available.

An ownership rule for AI

The volume problem has a new accelerant. Jeremiah Lowin put it well: “code is now cheap, and we see it offered in lieu of discourse.” It’s already killing real infrastructure: Daniel Stenberg ended curl’s bug bounty in January 2026 because AI-generated reports drowned it, dropping the confirmed-vulnerability rate from over 15% of submissions to under 5%. That program paid out more than $100,000 across 87 real vulnerabilities over its lifetime. It’s gone now, and fabricated reports are why.

Ghostty comes closest: disclosure required, the human must fully understand every line, bad-faith contributors get publicly blocklisted. tldraw paused all external contributions entirely, GitHub is building volume controls. What’s still missing everywhere is the maintainer’s half of the bar. The contributor’s half is the Ghostty shape: disclose the tool, be able to explain every line you submitted, and fabrication (the confidently invented vulnerability that burns a maintainer’s afternoon) gets you banned, first offense. The maintainer’s half: once someone meets that bar, “this looks AI-generated” stops being a reason. Dismissing explainable work without saying what’s wrong with it fails the exact ownership standard you just set, and it’s the silent close wearing a trendier excuse.

Put the rule in the PR and issue templates, where the behavior happens.

Plan for the day you walk away

Losing the core team is the normal lifecycle of an open source project. A study of 36,464 projects by Olivier Nourry and colleagues (titled, helpfully, “Myth: the loss of core developers is a critical issue”) found 89.65% lost their entire core team at least once, and about 27% of those attracted at least one new core developer and kept going. Metabase’s bus factor analysis of the top 1,000 GitHub projects by stars puts roughly half at a bus factor of 2 or less. So this is a when, and the projects that survive it are the ones where the knowledge outlived the person.

Succession is a file in the repo. How releases happen, who holds which keys, and what someone has to do to earn commit access, written down while you still remember why. Eric Raymond said it cleanly: “when you lose interest in a program, your last duty to it is to hand it off to a competent successor.”

Security intake belongs in the same write-it-once bucket. A real SECURITY.md (private intake, a response commitment you’ll actually keep, an explicit out-of-scope list that pre-answers the recurring false positives) plus required 2FA for anyone with push access. Popular code held up by one unpaid person is precisely the condition the xz-utils backdoor exploited, and the runbook costs an afternoon.

And if the honest answer is that you don’t want any of this… say that, in the repo. SQLite states plainly that it’s open-source but not open-contribution: patches only from people who’ve signed an affidavit dedicating the work to the public domain, and even then expect yours rewritten from scratch. Nobody holds it against them, because nothing about the project pretends otherwise. Resentment shows up where the README says “contributions welcome” and the queue says nothing. If you’re done entirely, archive the repo, so a thousand dependents can tell “I’m done” apart from “slow month.” Downstream users notice the difference: a Carnegie Mellon interview study on navigating dependency abandonment found they get little to no guidance when a package is abandoned, partly because abandonment is rarely marked in any consistent way.

Overall: you don’t need to become a better person on your worst week. Spend one decent week building the things that answer for you on the bad ones: a second responder, a public reason on every close, an on-ramp that grows your replacement, and 2 rules you write once.

If you’re on the contributor side of this, sizing up a project before you spend a weekend on it, a handful of git commands will tell you whether anyone’s home before you open a PR.

Related Articles