What are the states of an open source project?

Per the CPAN security.metacpan.org lifecycle taxonomy (the most rigorous formal version) and Leaddev's 9-state model, the canonical states are: Active, NEEDHELP, HANDOFF, ADOPTME, and Archived. The first three describe a healthy project in transition. The last two describe a project that has lost its maintainer. Andrew Nesbitt's June 2026 article compresses this further into: chosen successor, open adoption, and deliberate ending.

Concept

The 5 states of an open source project

Q: What does the ADOPTME tag mean?

ADOPTME (also written ADOPT-ME or adopt-me) is a convention that started in the WordPress plugin ecosystem and has spread to the broader community. Adding ADOPTME to a project's metadata (repo topic, CPAN permissions file, or PyPI classifier) signals that the current maintainer is actively looking for a successor. The shields.io looking-for-maintainer badge serves the same purpose. CPAN encodes it as a pseudo-user in the permissions file: HANDOFF = maintainer is open, ADOPTME = the project is officially up for adoption, NEEDHELP = the project needs co-maintainers.

Q: What's the difference between NEEDHELP, HANDOFF, and ADOPTME?

NEEDHELP means the project still has a maintainer, but they need co-maintainers or active contributors to keep going. The project is not at risk of immediate abandonment; the maintainer is just asking for help. HANDOFF means the maintainer has decided to step down and is looking for a specific successor — usually an active contributor they trust. ADOPTME means the maintainer is unreachable or has formally stepped back, and the project is open to any qualified candidate who can prove themselves.

Q: What happens when a project is archived on GitHub?

When the owner marks a GitHub repository as archived, it becomes read-only: no commits, no issues, no PRs, no comments. The repo stays accessible (no code is deleted) but shows an 'archived' banner. Archiving is the formal end of life for a GitHub project. It's a legitimate destination for projects that have been completed, replaced, or are no longer maintainable. It is not abandonment — abandonment is when the project is left in a state where users still depend on it but no one is responding.

Q: How long do open source projects last?

Per a 2020 empirical study of npm and Maven projects, 16% of projects become unmaintained within one year of being active, and the median project lifetime is under 2 years. Per the 2025 Maven ecosystem study (arXiv 2502.00615), approximately 1 in 4 libraries fail to survive beyond their creation year. The typical OSS project has a short, intense life: a single developer, a few years of activity, then either a handoff or a fade-out.

Q: Can a project come back from ADOPTME?

Yes — and it's the model BreakPoint is built on. A 2019 arXiv study (1906.08058) tracked 1,985 projects over 5 years and found that 41% of abandoned projects survived because new core developers stepped up. The key signals that a project will come back: a clear maintainer-handoff document, the ADOPTME/looking-for-maintainer tag set, a recent issue or discussion activity (someone is paying attention), and a public surface for new maintainers to be found. BreakPoint is the platform built around that 41%.

Every open source project lives in one of five states: Active, NEEDHELP, HANDOFF, ADOPTME, or Archived. Knowing the difference is the difference between waiting for a fix that's coming and depending on software that quietly died.

Published July 13, 2026 · ~6 min read · synthesizes the CPAN security.metacpan.org taxonomy, Leaddev's 9-state model, and Andrew Nesbitt's June 2026 "How Open Source Projects Change Hands" article.

The state machine, in one picture

Different ecosystems have slightly different taxonomies — CPAN has the most rigorous formal version (8 states), Leaddev uses 9, Andrew Nesbitt's June 2026 article compresses it to 3. The canonical 5 below cover the cases that matter for adopters and maintainers:

State 1

Active

The project is maintained. There is at least one responsive maintainer who is reviewing PRs, triaging issues, and shipping releases on a regular cadence. Bus factor may be 1 (still healthy — just fragile). The default state for any project that someone is actively working on.

Signals: issues get responses within days, releases within months, recent commits across multiple areas of the codebase.

State 2

NEEDHELP

The project has a maintainer, but the maintainer is asking for help — usually explicitly, via a NEEDHELP tag, a "we need co-maintainers" issue, or a FUNDING.yml. The project is not at immediate risk of abandonment, but the bus factor is 1 and the maintainer's bandwidth is exhausted. Healthy projects often spend years in this state.

Signals: the maintainer is still responding, but slower than they used to. Open issues backlogged. Releases delayed. The "looking for co-maintainers" pin is set on the repo.

State 3

HANDOFF

The maintainer has decided to step down and is looking for a specific successor. The vocabulary comes from CPAN, where the HANDOFF pseudo-user in the permissions file is a machine-readable signal. In practice, the maintainer has identified a candidate (often an active contributor) and is negotiating the transfer. The project is in a transition window.

Signals: a "seeking new maintainer" issue is pinned, the maintainer is public about their timeline, the candidate is visible in the contributor list.

State 4

ADOPTME

The project is officially up for adoption. The maintainer is either unreachable, has formally stepped back, or has set the ADOPTME tag explicitly. The project is open to any qualified candidate. This is the state that BreakPoint tracks: every project in this state has a story, a "next steps" section, and an explicit intent to hand off.

Signals: the ADOPTME/adopt-me tag is set, the looking-for-maintainer badge is in the README, the latest release is months old, no recent maintainer activity on issues.

State 5

Archived

The project is read-only. The owner has explicitly marked it as end of life. On GitHub, this means the repo is frozen — no commits, no issues, no PRs, no comments. The code is still available for reading or forking, but no one is maintaining it. This is a legitimate destination for completed or replaced projects. It is not the same as abandonment.

Signals: the GitHub "archived" banner, the PyPI development status 7 (Inactive), the npm "deprecated" field, the RubyGems "is outdated" warning.

The signals that tell you which state a project is in

You don't have to ask the maintainer — the project itself tells you, if you know where to look. A 6-signal checklist, in increasing order of severity:

Issue response time. Median time from issue open to first maintainer comment. <7 days = Active. 7-30 days = NEEDHELP. >30 days or never = HANDOFF or ADOPTME.
Release cadence. Time since the last release. A feature-complete project may go 12+ months between releases and still be Active. A library that depended on a release 6 months ago and got nothing is probably NEEDHELP.
Commit cadence. Run git shortlog -sn --all --since="12 months ago". If the same person is 90%+ of the last 12 months of commits, the bus factor is 1. The project may still be Active, but it's fragile.
Bus factor. See the bus factor explainer for the calculation. Bus factor 1 is fine for a solo project. Bus factor 1 + 12 months no commits + unanswered issues = ADOPTME.
Tag presence. Is the ADOPTME/adopt-me GitHub topic set? Is the looking-for-maintainer badge in the README? Is HANDOFF in the CPAN permissions? These are the explicit signals the maintainer is using to say "I want to hand this off."
Registry status. PyPI development_status = 7 (Inactive). npm "deprecated" field set. Packagist "abandoned" flag with a "use X instead" replacement. RubyGems "is_outdated" warning. These are the ecosystem-level signals that the maintainer has formally declared end of life.

How projects move between states

The state machine isn't linear. A project can:

Go Active → NEEDHELP → HANDOFF → ADOPTME → Archived in a graceful planned sunset. This is the model everyone wants.
Go Active → NEEDHELP → silent for 6 months → ADOPTME without the maintainer noticing. This is the most common path. The "I'll get to it this weekend" trap.
Go Active → HANDOFF → back to Active when a new maintainer takes over and the original stays on as a co-maintainer. This is what the BreakPoint Hall of Fame celebrates.
Go Active → NEEDHELP → ADOPTME → Active again via an external adoption. This is the BreakPoint model: drop the project, someone finds it, the project lives again. Median time from drop to first PR on BreakPoint: 23 days.
Go Active → Archived with no warning. This is the worst case — users depending on a project that the maintainer has just stopped maintaining, without telling anyone.

The good news: 41% of abandoned projects come back

A 2019 study of 1,985 open source projects (arXiv 1906.08058) found that 16% of projects became abandoned over a 5-year observation window, and 41% of those abandoned projects survived because new core developers stepped up. The factors that predicted revival: a clear maintainer-handoff document, the ADOPTME/looking-for-maintainer tag set, and a public surface where new maintainers could be found.

That 41% is the entire reason BreakPoint exists. The handoff is not theoretical. The work is real, the next maintainer is out there, and the platform is the connection. If you're looking at an ADOPTME-state project and wondering whether to take it on, the answer is: yes, the data says someone will, and it might as well be you.

Frequently asked questions

What does the ADOPTME tag mean?

A convention started in WordPress, now used across CPAN, PyPI, and GitHub. ADOPTME signals the current maintainer is actively looking for a successor. The equivalent CPAN signal is the ADOPTME pseudo-user in the permissions file. The equivalent badge is the shields.io looking-for-maintainer badge.

What's the difference between NEEDHELP, HANDOFF, and ADOPTME?

NEEDHELP = still has a maintainer, just needs co-maintainers. HANDOFF = maintainer has decided to step down, looking for a specific successor. ADOPTME = maintainer is unreachable or has stepped back, project is open to any qualified candidate.

What happens when a project is archived on GitHub?

The repo becomes read-only: no commits, no issues, no PRs, no comments. The code stays accessible but no one can change it. Archiving is a legitimate end-of-life signal, not the same as abandonment.

How long do open source projects last?

Per a 2020 empirical study, 16% of projects become unmaintained within one year. The 2025 Maven ecosystem study found ~25% of libraries fail to survive beyond their creation year. The median project lifetime is under 2 years.

Can a project come back from ADOPTME?

Yes. A 2019 arXiv study found 41% of abandoned projects survived because new core developers stepped up. The factors that predict revival: a clear handoff document, the ADOPTME tag, a public surface for new maintainers. See the BreakPoint Hall of Fame for examples.

The state machine, in one picture

The signals that tell you which state a project is in

How projects move between states

The good news: 41% of abandoned projects come back

Frequently asked questions

Related reading