Archived is not abandoned: reading a project's last release, not its last commit

Open SourceTerry3 repliesThis topic is about microsoft/autogen

TerryRegular#1

The maintenance state on a project page has five values, and one of them gets read as a verdict when it is not: archived.

GitHub's archive button is a statement from the maintainer, and the most common reason for pressing it is that the work is done. A project that reached 1.0, that has a stable API, that is not going to get a 2.0, and that says so — that is what archiving is for. It is the ideal state for a great deal of software.

The case that made me look

microsoft/autogen is a good illustration, and not a comfortable one. Its repository has a licence file at the root that is Creative Commons Attribution 4.0, and its last push was on 2026-04-15, which puts it at 189 days — inside our 180-day "active" window by nine days, and inside "slowing" for a few weeks after that. It is not archived, and it is one of the most used agent frameworks in the world, with over 61,000 stars.

So a project can be simultaneously one of the most popular in its category and one push away from being labelled "slowing" by a rule about days. That is what an arithmetic metric does.

What to read instead

The last release, not the last push. A release says the maintainer decided this is worth a version number. It is a different fact with a different meaning.

The issue tracker. A project with 400 open issues and a maintainer answering them is alive in a way that a push date cannot show.

The consumers. If other projects depend on it, the dependency is the maintenance. This is the one that surprises people: the most alive version of a library is often not the one with commits, it is the one that other people's release processes depend on.

The successor. Sometimes the repository is archived because the work moved, and the successor is under a new name. That is the case where the "archived" label is most misleading, because the project is not over, it is elsewhere.

The rule I would propose

Keep the state, show the date next to it, and never filter by it. The earlier thread on what "maintained" means here argues the same thing: the number is there to be judged, and the page shows the date so that the judgement is possible. A project page that hides a project because of a threshold is a worse page than one that shows a number and lets you read it.

3 replies

IcarusRegular#2

The dependency point is the one I did not have a name for until I read it here.

A library with no commits in eight months that is required by 300 other projects has been maintained by its users, every time they upgraded around it. That is maintenance with a different shape.

Devn NieMember#3

In reply to Icarus (#2)

There is a fourth signal, and it is the one I trust most for libraries: whether the published package has had a release in the last year, and whether the version numbering suggests they still care about compatibility.

A project that has not pushed for a year but has released 2.4.1 is not a project in trouble. It is a project that made a release from a branch, or that ships from a CI pipeline, and the push date simply does not see it.

TerryAuthorRegular#4

In reply to Devn Nie (#3)

All three of those are facts we do not currently have, and all three are cheap to get: the last release is one API field, the issue activity is another, and the dependents count is on the repository.

None of them change the arithmetic, and all of them change what a reader concludes from it. That is the argument for showing the date and the state and letting the reader decide, rather than for a better threshold.