Frequently asked questions

Adoption is when a project changes hands: the original maintainer steps back, a new maintainer takes over, and the project continues. Adoption is not the same as forking — adoption preserves the original URL, the star history, the issue tracker, and the existing user base. The 2019 arXiv study found that 41% of abandoned projects survive because new core developers stepped up.

Adoption is a transfer of the original repository — the new maintainer gets the URL, the stars, the issues, the existing users. Forking creates a new copy — the original repo stays as a tombstone, the fork starts from zero. Adoption is what you want for handoffs. Forking is what you do when adoption isn't possible.

From drop to first PR on BreakPoint: 23 days median. From drop to release: 30-60 days for projects with clear next-steps documentation, longer for projects without.

Wait 30 days after a clear, polite outreach. Try a second channel (Twitter, LinkedIn, email on the commit history, the BreakPoint conversation). If still no response, post a public statement of intent on the original repo (an adopt-me-tagged issue), wait another 30 days, then fork as a last resort. Document the timeline so future adopters don't repeat the cycle.

adopt-me is a GitHub topic (and WordPress convention) that signals a project is looking for a new maintainer. Adding the topic to a repo's metadata makes it discoverable via GitHub search and across automation tools like Adoptoposs, pickhardt/maintainers-wanted, and BreakPoint.

Bus factor is the minimum number of contributors whose sudden departure would cause a project to stall. Bus factor 1 = one person away from dead. The median bus factor for the top 100 most-depended-upon OSS packages is 1, per a 2024 Harvard / Linux Foundation study. Packages with bus factor 1 have a 36% annual chance of losing their only contributor.

NEEDHELP = the project still has a maintainer, just needs co-maintainers. HANDOFF = the maintainer has decided to step down and is looking for a specific successor. ADOPTME = the maintainer is unreachable or has formally stepped back, and the project is open to any qualified candidate.

Archived is a formal end-of-life state — the GitHub repo becomes read-only, no commits, no issues, no PRs. Abandoned is an informal state — the project is left in a state where users still depend on it but no one is responding. Archived is a legitimate destination. Abandoned is a failure mode that should be fixed by adoption or by the original maintainer announcing the archive.

Run npm deprecate <package> "This package is no longer maintained. See <URL> for the successor." The message shows up on every npm install. Also set the deprecated field in package.json. The deprecation does NOT delete the package — it just warns.

PyPI has no built-in deprecation, but you can set the development_status classifier to 7 (Inactive) in your setup.py / pyproject.toml, and upload a final release with a deprecation note in the long description. For full transfer, file at pypa/pypi-support per PEP 541.

Add a [patch.crate-io] retract directive to your Cargo.toml and publish a final release. Set the unmaintained.tech label on the GitHub repo. Add the adopt-me GitHub topic.

Add a retract directive to your go.mod and publish a final release. Set the unmaintained.tech label on the GitHub repo. Add the adopt-me GitHub topic and looking-for-maintainer badge.

See the maintainer handoff guide for the 5-step playbook. The short version: set the adopt-me topic, the looking-for-maintainer badge, and a pinned Seeking new maintainer issue. Document the next steps. Drop the project on BreakPoint. Cross-post to Adoptoposs and pickhardt/maintainers-wanted. The median drop-to-first-PR on BreakPoint is 23 days.

See the responsible abandonment guide. The 6-step process: announce 6+ months before archive, update the README with a clear deprecation banner, cut a final release, deprecate in every package registry, write a MIGRATION.md, archive the repo. Archive is a pause button, not a delete button.

That's the most common outcome and it is OK. A project that nobody wants to adopt was probably never depended on by anyone. Archive it with a clear banner, link to any forks, write a final post, move on. The community owes you nothing, and you owe the community nothing beyond the grace to say 'this is done.'

The risk that a critical dependency your product depends on becomes unmaintained, compromised, or deprecated. Per the 2026 Reptile.haus analysis, packages with bus factor 1 have a 36% annual chance of losing their only contributor. The XZ Utils backdoor (CVE-2024-3094) proved the attack vector.

Inventory your top 20 critical dependencies, score each on bus factor, maintenance cadence, explicit status signals, sponsoring status, and institutional backing. See the State of Open Source Supply Chain Risk 2026 for the full 5-move playbook.

Five moves: sponsor the maintainers of bus-factor-1 dependencies, make contributing back a team policy, have a documented adoption plan, track open source risk in your quarterly review, add a cross-team open source inventory to your architecture review process.