How to take over an abandoned open source project

Why this matters in 2026

A 2024 Harvard / Linux Foundation study of the top 500 most-depended-upon open source packages found a median bus factor of 1 for the top 100. Tidelift's 2024 maintainer survey reported that 60% of maintainers have quit or considered quitting. Sonar's 2024 study put burnout at 44%. The "abandoned project" you just found on the BreakPoint feed is not an edge case — it is the default failure mode of open source.

The good news: the handoff is a solved problem. The WordPress adopt-me tag, CPAN's ADOPTME/HANDOFF pseudo-users, Debian's RFA process, PyPI's PEP 541, and the broader repostatus.com ecosystem all encode the same workflow. The hard part is doing it well. This guide is how.

Step 1 — Find the right project

Don't just search "abandoned" on GitHub — that's how you end up with a pile of half-finished side projects. Find projects that are actively looking for a new home. The signal vocabulary is specific: adopt-me, looking-for-maintainer, HANDOFF, ADOPTME, NEEDHELP, RFA (Request For Adoption).

Where to look

• The BreakPoint feed — every project here is dropped with a story, a "next steps" section, and an explicit intent to hand off. Median time from drop to first PR is 23 days, so check back regularly. Filter by language and project size.
• Adoptoposs — the 2019 directory that pioneered the space. Still actively maintained, smaller surface than BreakPoint, useful as a cross-check.
• GitHub topics: adopt-me, looking-for-maintainer, orphaned.
• pickhardt/maintainers-wanted — a curated GitHub list. Lower volume, higher signal.
• repostatus.com — projects that publish a Status: looking-for-maintainer badge. Many CPAN and RubyGems packages use this.
• npm "most depended upon" filtered by last-published date — useful for spotting silent rot in your own dependency tree.

Step 2 — Evaluate before you commit

Six things to check, in roughly this order. Skipping any of them is how you end up stuck with a 40,000-line unmaintained C++ project and a year of your life you can't get back.

1. The license

Is the project MIT, Apache 2.0, BSD, or GPL? You can adopt these freely. Is it a custom "All rights reserved" license, AGPL with restrictions, or a source-available license (BSL, SSPL, Elastic)? You may not be able to fork, rebrand, or distribute without legal review. Read the LICENSE file before anything else. If there's no LICENSE, the default in most jurisdictions is "all rights reserved" — the project is not open source in the OSI sense, regardless of what the README says.

2. The bus factor (today)

Run git shortlog -sn --all on the repo. If one person has 90%+ of the commits, the bus factor is 1 — that's the original maintainer you're inheriting from. If 3-5 people have meaningful commit history, you have a real community and your job is mostly coordination.

3. The commit cadence

A repo with 6 months of no commits might be "abandoned" or it might be "feature-complete and stable." Look at the last 20 issues and PRs: are they genuine feature requests, or stale automated Dependabot noise? Stable-but-quiet is a great project to adopt. Stale-and-frustrated is a trap.

4. The open issues

Sort by oldest. If the top 5 are 2+ years old with no response and the issue authors are still commenting in frustration, the project has a real backlog that's probably out of scope for one maintainer. If the top issues are documentation requests and small bugs, the project is healthy and you can ship a release in your first month.

5. The downstream users

For npm: npm dependents shows packages depending on this. For PyPI: pypistats.org. For Ruby: rubygems.org download stats. A project with 50+ direct dependents is a much bigger commitment than one with 5. Plan accordingly.

6. The maintainer's stated reason

"I started this in college, haven't had time in 3 years, please take it" is a different project from "I quit because the community was toxic." Read the original maintainer's drop story on BreakPoint, their last few issues, and their Twitter. If they sound relieved and grateful, you'll inherit a friendly community. If they sound bitter, the community is part of the problem you're inheriting.

Step 3 — Contact the original maintainer

This is the step most people skip. Always reach out before forking. Most maintainers will hand the project to you happily — they already wanted someone to take it. A fork-only approach is hostile, fragments the user base, and forfeits every star, every issue, and every existing user who already knows where the project lives.

The right first message

Open a GitHub issue titled Looking to take over maintenance on the original repo. Keep it short. Be specific about what you've already done:

Hi! I've been using [project] for [X months/years] for [specific use case].
I noticed your [last commit / "looking for a new maintainer" issue / BreakPoint
drop] and wanted to ask: would you be open to handing over the repo?

Specifically I'd like to:
- Triage and address the [N] oldest open issues
- Cut a [next version] release
- Add CI / update dependencies as needed
- [One concrete thing you'd add that the original maintainer never had time for]

If you're open to it, I can do a maintainer transfer via GitHub's settings
("Transfer ownership"). If you'd rather I just send PRs and stay a contributor,
that's also fine — happy to do whatever works for you.

No pressure, and thanks for building this.

If they don't respond

Wait at least 30 days. Try a second channel — Twitter/X DMs, LinkedIn, the email on their commit history, the BreakPoint conversation. If still no response, post a public statement of intent on the original repo (adopt-me-tagged issue) and on your own channels. Wait another 30 days. Then, and only then, fork.

Document the no-response timeline in your fork's README. Future adopters should be able to see the full handoff attempt without doing the same waiting again.

Step 4 — Adopt, don't just fork

If the original maintainer agrees (and most do, when asked politely), the GitHub Settings → Transfer ownership flow gives you the original URL, the full star history, the issue tracker, and every existing user. Forks start from zero on all of those.

For non-GitHub projects:

• PyPI: see PEP 541 for the official process when the maintainer is unreachable.
• RubyGems: gem ownership can be added via gem owner --add; full transfer is a manual request to RubyGems support.
• npm: use npm owner add <your-username> <package>; the npm support team can transfer full ownership for unreachable maintainers.
• CPAN: ADOPTME/HANDOFF pseudo-users are the established signal — co-maintainer requests go through the PAUSE admin.

Step 5 — Migrate users without losing them

A clean migration is the difference between "this project lives on" and "we now have 4 forks and no one knows which one to use." Five things to do, in order:

1. Banner on the original repo (if you have transfer rights): update the README with a clear "This project has moved to [new URL]" callout at the top.
2. GitHub's "Public archive" banner: under Settings → General, mark the original repo as archived. GitHub will show a banner automatically. Don't delete it.
3. Release notes on the new repo: publish a major version release that says "this is the maintained continuation of [old name]." Include the old name in the keywords, the README, and the description.
4. Cross-post to the project's normal channels: Discord, Slack, mailing list, subreddit. The users you don't tell are the users you lose.
5. Update package registries to point at the new version. The replaces / deprecated fields in composer.json (PHP), setup.py (Python), and package.json (npm) are the standard signals.

Step 6 — Don't become the next bus-factor-1

The reason the project was abandoned in the first place is that one person was carrying it alone. The single worst thing you can do is repeat the pattern. From day one:

• Add at least one co-maintainer in your first 3 months. The person who files the most thoughtful PR is your first candidate. Ask them.
• Document what you do. If you only have time to write one doc, write the contribution guide. Make it easy for a stranger to send a mergeable PR.
• Tell people when you need help. Post a "Looking for co-maintainers" issue in your second month. The signal vocabulary is out there — use it.
• Plan your own exit before you need it. If you adopt a project expecting to maintain it forever, you'll burn out in 18 months. Adopt it expecting to be the steward for the next 2-3 years, and to find your replacement before you stop.

Frequently asked questions

Related reading

Ready to adopt?

Browse the BreakPoint feed. Every project is dropped with a story, a "next steps" section, and an explicit intent to hand off. Find one that fits.