Read-Only Is Not Rest in Peace: Auditing the 30 Days After a Repo Archive

The GitHub archive button is deceptively quiet. A banner appears, the issue tracker locks, and the repository settles into a kind of digital amber. For the maintainer, the relief is immediate. For everyone else — the downstream packagers, the security researchers, the engineers whose production systems depend on the code — the archive is often the first they hear of it.

We spoke with maintainers who archived active projects over the past three years and asked a simple question: what happened next? Their answers describe a gap in open-source practice that release engineering has largely ignored. Births get announcements, versioned releases, and launch posts. Deaths get a checkbox.

Week One: The Stragglers Arrive

Every archived project has them — users who open issues against a read-only repository, then discover they cannot. The tracker locks, but the notifications keep flowing to the maintainer's inbox. One maintainer who retired a widely used Rust parsing library told us he received more email in the two weeks after archiving than in the two months before it.

The pattern is predictable. CI pipelines break first, because dependabot and similar tooling flag the frozen dependencies. Then come the security researchers, who file reports through channels that no longer have a responder. A CVE filed against an archived project has no patch path. The advisory simply hangs there, pointing at code nobody can change, and downstream scanners flag it forever.

This is the structural problem: archiving does not end a project's obligations, it just removes the infrastructure for meeting them.

The Forks That Never Happen

The open-source community has a folk belief that healthy projects never truly die — someone forks them. The data from our conversations suggests otherwise. Forking is easy; sustaining a fork is not. Without the maintainer's context, issue history, and community trust, most forks stall at the copy stage.

One maintainer of a deprecated JavaScript tooling project counted fourteen forks within a month of archiving. None shipped a release. "People fork to preserve, not to maintain," she said. "They're parking the code, not adopting it."

This matters because the standard advice — "just fork it" — shifts the moral burden of abandonment onto the community without providing anything material: no handoff documentation, no list of known landmines, no introduction to the contributors who understood the hairy parts.

What an Actual End-of-Life Process Looks Like

From these post-mortems, a rough protocol emerges. Projects that exited well tended to do most of the following:

• A final release, not a final commit. Ship one last version that bumps dependencies, closes known trivial bugs, and is explicitly labeled as terminal. Users can pin to it with confidence.
• A deprecation window. Announce the archive date 60 to 90 days out, in the README, the changelog, and — critically — in the package registry, where users actually look.
• A maintained-alternatives note. Name successor projects honestly, including where you have no relationship with them. Silence on this point strands users longer than any technical issue.
• A security escalation path. Archive the repo, but keep a contact route open for vulnerability reports, and state in the README that the project no longer receives patches. Scanners and procurement teams need that signal in writing.
• A handoff brief. A short document for potential fork maintainers: architecture notes, the three hardest subsystems, and the tests that are load-bearing but fragile.

None of this is glamorous. All of it is cheaper than the alternative — a slow bleed of confused users, orphaned CVEs, and trust spent on a project that stopped answering.

The Downstream Discovery Problem

The most damaging failure mode we documented was simple ignorance. Enterprises discovered archived dependencies during renewal-cycle audits or, worse, during incident response. A mid-sized logistics company in Ohio found a core internal service built on an archived library only when a regression report bounced off a locked issue tracker.

Package registries could help. Deprecated markers exist on npm and PyPI, but they are optional, inconsistently applied, and easy to miss in a lockfile audit. The industry standard for component retirement in hardware — a formal last-time-buy notice, a documented replacement, a support horizon — has no real equivalent in most software ecosystems.

Ending in the Open

Open source has always been better at beginnings than endings. But a project's final month is part of its release history, and it deserves the same rigor as a v1.0: a plan, a changelog, and communication that reaches the people who depend on the work.

Archiving is not failure. Silent archiving is. The maintainers who exited well shared one habit: they treated their last thirty days as a release — the final one — and engineered it accordingly.