How to find a new maintainer for your open source project

Why this is hard, and why most projects don't do it

Tidelift's 2024 maintainer survey found that 60% of maintainers have quit or considered quitting an open source project. 44% report burnout specifically. 60% are unpaid. Of the projects that get dropped, only a fraction are ever properly handed off — the rest become bit-rot on GitHub, depending on which random fork happens to be alive when someone needs the code to work.

The reason is not that maintainers don't care. The reason is that doing the handoff well takes 5-10 hours of work at exactly the moment you have no bandwidth to spare. This guide is how to compress that into a 2-hour weekend, and how to make sure the next person can actually pick it up.

Step 1 — Decide: step down, or get help?

The cheapest way to rescue an overstretched project is to add a co-maintainer, not to hand the whole thing off. Ask yourself three questions before doing a full handoff:

• Do I want to keep any involvement? If yes, you don't need a handoff — you need a co-maintainer. A co-maintainer can take triage and releases; you keep final say.
• Is the problem time, or is the problem motivation? If you still love the project but have no time, a co-maintainer fixes it. If you've stopped caring about the problem space, a full handoff is the honest move.
• Am I burned out, or am I just tired? Burnout is structural. Stepping back for 3-6 months often recharges more than any other intervention. Announce a maintenance pause, not a handoff, if you think you might come back.

For the rest of this guide we'll assume you've decided on a full handoff. If you decide on a co-maintainer instead, you can skip directly to Step 4 (Set the signals) and use the same looking-for-maintainer vocabulary — just be explicit in your post that you want to stay involved.

Step 2 — Document what's left to do

The single most common reason handoffs fail is that the original maintainer thought out loud and the new maintainer took it literally. "It's mostly working" turns out to mean 47 known issues, 12 PRs that need rebase, 3 half-finished refactors, and a CI pipeline that has not run green in 8 months.

Spend 90 minutes writing a "Next Steps" section. A stranger should be able to read it and ship a release in their first week. Six things to include:

1. What the project is and who uses it. 2 sentences. If you can't write this in 2 sentences, you don't know what you're handing off.
2. Known issues, ranked by severity. Not just a link to the issue tracker — your judgment on what's blocking vs what's nice-to-have.
3. Release-blocking things. What's the one thing that has to ship before a v1.0.0 can go out? Be specific.
4. Architecture notes that aren't in the code. The "why" behind the most important decisions. The non-obvious dependencies. The thing that broke twice and you fixed it differently both times.
5. Where the "users" hang out. Discord, Slack, mailing list, subreddit. The new maintainer should be able to find them in 5 minutes.
6. What you would do next, if you had time. Your roadmap, in priority order. They can ignore it, but they need to know it existed.

Step 3 — Pick a path: chosen successor or open adoption

Andrew Nesbitt's June 2026 taxonomy breaks this down into three states: chosen successor (you hand it to a specific person you trust), open adoption (you publish a public search), and deliberate ending (you archive it on purpose). Most projects should pick the first two.

Chosen successor

If you have an active contributor who has been carrying the project with you — someone who has reviewed PRs, triaged issues, cut a release — ask them first. A direct handoff takes one conversation and one repo transfer. The community sees a smooth transition. The bus factor goes from 1 to 1, but at least the new 1 has context.

Open adoption

If you have no obvious internal candidate, publish a "Looking for new maintainer" notice. You'll get 0-5 serious responses, of which 0-2 will be realistic. The risk: the project fragments across multiple competing forks while you're trying to decide between them. The mitigation: pick a successor within 30 days of the notice, and announce your choice as a single recommendation, not a vote.

The November 2025 Kubernetes Ingress NGINX retirement is the model for this. The maintainer team announced the retirement, published migration guidance to the official successor, and ran a 6-month window where both projects coexisted. Read their announcement before doing yours.

Step 4 — Set the signals

The signal vocabulary for "this project is looking for a new maintainer" is well-defined. Use all of these, in combination — they compound. A project with the adopt-me tag, the shields.io badge, a pinned GitHub issue, and a BreakPoint drop will be found by someone within 30 days. A project with just a vague "I'm stepping back" line in the README will not.

1. The adopt-me tag (repo metadata)

Add the adopt-me topic to the repo on GitHub (Settings → Topics). This is a WordPress convention that has spread to the broader community. It makes the project show up in the GitHub adopt-me topic search and in every Adoptoposs / pickhardt / BreakPoint scraper that looks for it.

2. The shields.io looking-for-maintainer badge

Drop this into your README:

![Looking for maintainer](https://img.shields.io/badge/maintenance-looking--for--maintainer-orange.svg)

Generated at shields.io/badges/looking-for-maintainer. This is the same vocabulary used across CPAN, RubyGems, and PyPI — when a developer sees the badge, they know the project's intent.

3. A pinned "Seeking new maintainer" GitHub issue

Open a GitHub issue, pin it to the repo, and link it from the README. A good template:

## Status: Looking for a new maintainer

I've been the sole maintainer of [project] since [year]. I'm stepping back
because [brief reason — burnout, job change, life event, lost interest].

The project is real and [N] people / [M] packages depend on it. I'd love to
hand it off to someone who has the time and interest to take it forward.

**Next steps (see Next Steps section in README):**
- Triage the [N] oldest open issues
- Cut a [next version] release
- Update dependencies / CI
- [One specific concrete thing]

**How to take over:**
1. Comment on this issue saying you're interested
2. Open a PR addressing any of the open issues
3. Once we've worked together for 2-3 weeks, I'll transfer the repo

**I'll stay as a co-maintainer for 3-6 months** for release sign-off and
occasional triage. After that, full ownership is yours.

If nobody steps up by [date 60-90 days out], I'll archive the project and
publish a final "thanks" post. — [Your name]

4. Drop it on BreakPoint

Submit a "drop" on BreakPoint — a structured handoff record that includes the project story, the "next steps" you just wrote, and a conversation thread with the next maintainer. BreakPoint ranks drops by language and project type, so the right kind of developer is more likely to find it. The median time from drop to first PR is 23 days.

Step 5 — Announce everywhere, and pick a deadline

The signals above make your project findable. The announcement is what tells the people already paying attention that the time is now. Cross-post to:

• Adoptoposs — add your project to the directory
• pickhardt/maintainers-wanted — open a PR adding your project to the curated list
• The project's normal channels: Discord, Slack, mailing list, subreddit
• Your own channels: blog, Twitter/X, LinkedIn — anyone who knows you is a possible bridge to the next maintainer

Set a deadline. "If nobody steps up by [60-90 days out], I archive the project" is a kind ending. It gives the search real urgency, and it gives you permission to stop feeling guilty. Archive is not failure — it is a graceful end that the XZ Utils and Kubernetes stories taught us to value.

What if nobody wants it?

This is the most common outcome for projects with fewer than 100 GitHub stars or fewer than 5 active users. That's fine. You tried. The project was small enough that it never had a real community to hand it to.

Archive the repo with a clear "this project is no longer maintained" README banner. Link to any forks that did appear, even if they look unmaintained themselves — a stranger might find your repo, see the fork, and revive it from there. Write a final blog post. Move on. Build the next thing.

Frequently asked questions

Related reading