Adoption Papers: The Legal and Social Mechanics of Taking Over an Orphaned Package

Every dependency tree in a modern American software shop contains at least one package living a strange half-life. It installs cleanly. It resolves on npm and PyPI without complaint. Its download counters tick upward by the tens of thousands each week. And yet nobody has committed to it in twenty-six months. The maintainer's last activity was a thumbs-up emoji on a stale issue. The package is not dead. It is something arguably worse: unattended.

At the Asterix Project, we spend a lot of time thinking about the health of the open-source supply chain, and orphaned packages deserve more attention than they get. The question isn't just how to spot them — it's what happens next. Can you take one over? Should you? And what does the process of adoption actually look like when the current owner has quietly drifted away?

The Spectrum of Abandonment

Before discussing adoption, it helps to be precise about the condition. Abandonment is not binary.

At one end sits the truly derelict: the maintainer has died, changed careers, or simply evaporated, and the package registry shows no activity of any kind. At the other end is what we'd call functional orphanhood — the maintainer still technically holds the keys, responds to a direct ping once a quarter, and has no intention of handing anything over but also no capacity to do the work. Between those poles live the majority of cases: maintainers who would gladly transfer ownership if anyone asked, but whom nobody has asked in years.

This distinction matters because the adoption path differs radically depending on where a package falls on the spectrum. A responsive-but-overwhelmed maintainer can hand over a repo in an afternoon. A truly absent one may require you to go through the registry itself.

The Registry's Role: npm vs. PyPI

The two dominant ecosystems handle ownership transfer in meaningfully different ways, and any team drafting an adoption plan should understand both.

npm ties package ownership to npm accounts. A transfer requires the current owner to run a single command — npm owner add <newuser> — which makes the happy path trivially easy if the owner is reachable. When they aren't, npm's support process for unresponsive maintainers is famously conservative. The registry will not seize a package merely because it's stale; it generally requires evidence of abandonment plus a compelling reason, and even then the process can take months. npm's caution is understandable: package names are squattable assets, and a liberal transfer policy would be a gift to typosquatters.

PyPI takes a different approach through its trusted-publisher and maintainer-role model, and the Python Software Foundation has historically been somewhat more willing to adjudicate disputes over abandoned projects — particularly when a package is widely depended upon and a security issue is burning. The PyPI admins have, in documented cases, granted ownership to new maintainers for packages like certifi and urllib3-adjacent tooling when the original authors stepped back. But "somewhat more willing" is not "willing." The bar remains high, and the process is fundamentally a judgment call by volunteers.

The practical takeaway: never assume the registry will rescue you. Design your dependency strategy as if adoption requires consent, because it usually does.

Forking Is Not Adoption

A common failure mode we see in postmortems: a team hits a wall with an unmaintained dependency, forks it, publishes under a new name, and declares the problem solved. Eighteen months later, they're maintaining a fork nobody else uses, missing security patches that landed in sibling forks, and wondering why their fork's issue tracker looks exactly like the original's did.

Forking solves your immediate compile error. Adoption — real adoption — solves the ecosystem's problem. The difference is legitimacy. A fork starts with zero trust and zero users. An adopted package inherits both, which is precisely why adoption is worth the administrative slog of contacting the original maintainer, negotiating a transfer, and preserving the project's history and issue tracker.

When a fork is unavoidable — say, the original author explicitly refuses transfer — the fork should be published under a new name that doesn't trade on the original's reputation, with a clear README explaining the divergence and a stated maintenance commitment. Anything less is squatting with extra steps.

What Due Diligence Looks Like

If you're considering adopting a package, run this checklist before you commit:

• License audit. Confirm the license permits redistribution and modification. Most permissive licenses do, but edge cases exist, especially in older packages with dual-licensing quirks.
• Contributor agreement review. If the project required a CLA, determine whether the new maintainership structure honors it or needs to renegotiate terms.
• Trademark and name rights. The package name on a registry is one thing; the project's trademark, logo, and domain are another. Adoption should include an explicit conversation about these assets.
• Provenance check. Who are the contributors with commit history? Are they reachable? A package with three contributors, one of whom is a bot account, deserves extra scrutiny before you build on it.
• Security posture. Pull the audit history. Orphaned packages are attractive targets precisely because nobody watches them — check for suspicious recent publishes before you take the keys.

The Social Contract of Adoption

The technical steps of adoption are the easy part. The harder work is social: announcing the transition publicly, setting expectations with downstream users, and honoring whatever implicit promises the original maintainer made. If the project's README promised stability through 2025, your adoption notice should address that promise directly — confirm it, amend it, or retract it.

The healthiest adoptions we've observed follow a pattern: a sixty-day transition window during which the outgoing and incoming maintainers both have publish rights, a pinned issue documenting the handoff, and a first release under new stewardship that changes almost nothing. That boring first release is a signal. It tells the ecosystem the package is alive again without forcing anyone to reevaluate their dependency on it.

What Teams Should Watch For

For engineering leads evaluating dependencies, the warning signs of functional orphanhood are legible in the public record: issue backlogs with no maintainer responses, release cadences that have stretched from weeks to years, CI pipelines failing silently, and README badges advertising services that no longer exist. None of these alone is disqualifying. Three or four together should trigger a conversation about whether your team is one security CVE away from becoming an unwilling maintainer.

The open-source supply chain runs on an unspoken contract: someone, somewhere, is home. When that stops being true, the responsible move isn't to look away — it's to pick up the adoption papers and do the work in the open, where everyone depending on that package can watch it happen.