Why I Archive Repos Aggressively

I archive about one repo a month. The running total on my profile sits at 47. Most of them had stars when I archived. A few had open issues I will never fix. One had a pull request from a stranger that I never merged because the project had quietly stopped mattering to me six months earlier.

Archiving feels like admitting failure. Closer to admitting honesty. Every archived repo is a small acknowledgement that a thing that once had a pulse does not anymore, and pretending otherwise helps nobody.

What triggers an archive

I run a 60-day rule and three exceptions.

The 60-day rule. If the last meaningful commit happened more than 60 days ago and I cannot name what the next commit would be, the repo is a candidate. Not every candidate gets archived immediately, but the clock starts.

Exception one: dependency churn. If the repo still sees automated dep-bump PRs and I am willing to review them, the repo stays live. A library that gets a monthly Dependabot update and nothing else is not dead. The word for that state is dormant.

Exception two: silent usage. If npm downloads or PyPI installs are still moving, the repo has users I cannot see. I never archive something that has a user base bigger than the commit graph suggests. I find out by glancing at the registry stats before I pull the trigger.

Exception three: I plan to come back. Rare, and I am honest with myself about it. Most repos I "plan to come back to" never actually get another commit. But one or two a year genuinely do. For those I add a README note ("pausing development until Q3, follow X if you want updates") and leave the repo live.

Anything that clears 60 days and fails all three exceptions gets archived. The decision takes about thirty seconds once I have the habit.

What archiving actually does

GitHub archive is a small button with an outsized effect.

• The repo becomes read-only. No issues, no PRs, no commits.
• The repo keeps all its stars, all its forks, all its history.
• A banner appears at the top: "This repository has been archived by the owner. It is now read-only."
• Search engines and package registries continue to find it.
• Anyone can clone it and keep going if they want.

The last point is the one I keep coming back to. Archiving does not delete the work. Archiving says "I am done maintaining this, but the work still exists and anyone who wants to carry it forward is welcome to fork." That is a different statement from "this is broken" or "this was a mistake."

Why archiving is a gift to future users

I used to keep dead repos alive because I felt guilty. People had starred them. I did not want to let anyone down. The result: I left them with no README updates, no release notes, and slowly-rotting dependencies, and called that "supporting the community."

What I was actually doing was setting a trap. Every new visitor who landed on that repo thought they were finding an active project. They would try to install it, hit a deprecated dependency, file an issue, get no response, and leave with a slightly worse impression of OSS in general.

Archiving is the opposite of that trap. When someone lands on an archived repo, the banner immediately tells them the state. They can still use the code if it works for them. They can fork and continue if they care. But they do not waste an hour investigating a project that has no maintainer.

Honesty is kinder than the illusion of activity.

Why archiving is a gift to future-you

A list of twenty open repos you barely remember is a low-key psychological tax. Every time you glance at your GitHub profile, your eye catches them, and some background process in your brain adds them to the pile of things you should be doing.

Archiving clears that pile. Your profile starts reflecting what you are actually working on. The current-work set stays small enough to hold in your head, and the archive becomes a different thing: a record, not a to-do list.

The first twenty repos I archived felt like weight coming off. I did not notice how much the unfinished-pile had been pulling at me until I put it down.

The README note I leave

Every archived repo gets a one-sentence addition to the README before I archive. Something like:

Status: Archived 2026-02-28. The code still works for [specific use case]. If you want to carry this forward, fork and go.

That sentence does two things. It tells visitors the current state in plain words. It explicitly invites forks, which occasionally leads to someone picking up the project and running with it. Three of my archived projects have active forks now run by strangers. Better outcome than me dragging a dead repo behind me for another year.

The projects I should have archived sooner

My worst cases were the ones where I kept a repo live for 18 months past its useful life, added minor tweaks every quarter or so to keep the commit graph from flatlining, and called that maintenance. Not maintenance. Decoration.

Two projects come to mind:

• An early auth middleware I wrote that was obsoleted by Auth.js within three months of my release. I kept updating the dep list for a year.
• A CLI for converting image formats that became pointless the moment Sharp added the same functionality natively. I kept publishing minor versions every few months.

Both should have been archived within six weeks of being obviated. Both ate more than twenty hours of collective maintenance time across the year I kept them alive. That time, multiplied across the several cases where I made the same mistake, was a real cost.

The one case where I do not archive

A repo I am embarrassed by but which is still actively used stays live. Embarrassment is not a reason to archive. If users are hitting it and the code still works, my feelings about the code quality do not override their usage pattern.

In those cases I leave a candid note in the README ("this was written in 2022 and the code shows, but it still works for X use case") and keep accepting dep bumps. The emotional discomfort of having clumsy code on my profile is smaller than the cost of breaking working software.

The short version

• Every solo builder should archive more than they do.
• The 60-day-no-commit rule is a good default.
• Check npm/PyPI stats before archiving so you do not strand silent users.
• Archiving is not deleting; the work stays, the illusion of activity does not.
• Leave a one-sentence status note explaining the archive.
• Invite forks explicitly so the project can outlive your maintenance.

The GitHub archive button is one of the most underused tools in OSS. Use it more. Your profile, your calendar, and your future users will all thank you.