You are inheriting an abandoned package's publishing rights. What do you owe its existing users?

A dependency's identity is not just its name and its version. It is also **who is allowed to publish the next version under that name**. A lockfile pins the first two and says nothing about the third. So when an abandoned package changes hands, every consumer's trust assumption changes silently, and the person taking over is the only party in a position to make it visible. ## What actually transfers Three separable things, and confusing them is the usual mistake: - **The namespace** - the right to publish the next version under that name. This is what the transfer grants and it is the security-relevant part. - **The source repository** - which may or may not come with it, and which consumers may be reading in order to decide whether to trust you. - **The reputation** - download counts, dependent counts, the "widely used" impression. This does not transfer so much as get *inherited without being re-earned*, which is precisely why the handover deserves a control. ## What the registry should demand of you Registries run name-retention processes for exactly this situation - PyPI's PEP 541 is the written-down example, and other registries operate comparable dispute or transfer procedures. A defensible process asks for: - **evidence of abandonment**: no releases and no maintainer response over a stated period, plus documented attempts to make contact through more than one channel; - **identity of the requester**, and a plausible case that they will steward the project; - **a public record of the decision**, so the change is discoverable afterwards rather than visible only to whoever happened to be watching that week; - ideally **a durable marker** on the package listing that ownership changed, and when. If a registry hands a widely depended-on name over on a quiet ticket, the process itself is a supply-chain weakness, and saying so is a legitimate answer. ## What you owe the existing consumers 1. **Make the change of hands loud.** State it in the repository, in the release notes and in the registry description: who publishes now, from where, under what process. Consumers who care can then make a decision; consumers who do not at least cannot say they were never told. 2. **Do not change behaviour in the first release.** Your first published version should be boring - the existing code built under your process, with no new dependencies, no new install-time scripts, no new network or filesystem behaviour. Anything else is indistinguishable from a takeover to anyone reading the diff. 3. **Preserve or explain the verification path.** If releases carried signatures or provenance, keep producing them, and state plainly what changed about the publishing identity - because anyone whose verification pinned the old identity is now failing, and they deserve to know why rather than having to guess. 4. **Give people an exit.** Document what the package now is and what a consumer who does not want to follow you should move to. ## The judgment call: inherit or fork Continuity is a real benefit. Thousands of dependents keep receiving fixes without a migration, and a dead name does not sit unclaimed waiting for someone worse. But it is bought with an ambiguity: every existing installation now trusts a party it never chose. Take the name when abandonment is genuinely established, the handover can be made public and attributable, and the user base gains more from continuity than it loses in trust clarity. Publish under **your own** namespace with a deprecation pointer on the old one when abandonment is uncertain, when the previous owner may return, or when the package is depended on widely enough that a silent change of publishing identity is a bigger risk than fragmentation. The fork costs adoption; it buys an explicit trust boundary that nobody has to be told about, because nothing was silently reassigned. ## Why the lockfile argument is wrong Candidates often deflect with "consumers are pinned, so it does not matter". A lockfile pins a version together with an integrity hash of a specific artifact, so already-resolved installations are safe and nothing changes retroactively. But every dependent that widens a range, regenerates a lockfile, or takes an automated update after the handover resolves to an artifact published by the new owner. The consumers most likely to upgrade quickly are the ones with the best update hygiene, which is a grim inversion. The pin protects the past; it says nothing about the next install.