What's the single most important abandonment signal?

Bus factor. A project with 1 active maintainer is a single point of failure. The day that maintainer gets sick, takes a new job, or just stops caring, the project stalls. Everything else (release cadence, issue response) follows from bus factor — a solo maintainer can't keep up with releases the way a team can. Run `git shortlog -sn --all` and look at the top contributor. If they own >80% of recent commits, the project is at risk.

How accurate is a 5-minute score?

It's a triage tool, not a final verdict. A 5-minute score catches the obvious cases (clearly abandoned, clearly healthy). For anything in the middle, run the full /audit for a multi-dimensional risk picture — dormancy prediction, sponsor health, security posture, and the bus factor at the dependency-vs-transitive-dependency level.

What if the project is healthy but the ecosystem is at risk?

You're asking the right question. A healthy-looking individual package can still be a risk if its transitive dependencies are abandoned. The colors.js incident in January 2022 wasn't about colors.js itself (it was maintained) — it was about the maintainer intentionally corrupting the package and every project that depended on it cascading. The full audit at /audit/r/ walks the transitive graph and shows which dependencies are pulling in abandoned code.

Should I avoid bus-factor-1 dependencies?

Not necessarily. A bus-factor-1 project with a healthy, responsive solo maintainer is fine for non-critical code. The risk is concentrated — when that one person burns out, you're stuck. The decision rule: bus-factor-1 is OK for tooling, internal libs, and dev dependencies. For production-critical paths (auth, payments, anything user-facing), require bus-factor-2 or a credible succession plan.

Blog · Risk

How to score an open source dependency's abandonment risk in 5 minutes

Four signals. Thirty seconds each. A risk score that catches the obvious cases before you ship a dependency to production.

Published July 17, 2026 · 5 min read

You found a library. It solves your problem. It's popular. Before you npm install, run these four checks. Total time: under five minutes. If a signal fails, escalate to the full audit for the multi-dimensional picture.

The 4-signal score

Signal 1: Bus factor (weight: 40%)

How many people would have to disappear before the project stalls?

How to check: git shortlog -sn --all | head -10. Look at the top contributor's share of the last 200 commits.

Score 0 (red): One person owns >80% of recent commits. Single point of failure.
Score 1 (yellow): One person owns 50–80%. Fragile but not broken.
Score 2 (green): At least two active co-maintainers in the last 6 months.

Signal 2: Last meaningful commit (weight: 20%)

When did the maintainer last touch the code in a way that matters?

How to check: Look at the commit history on the default branch. Filter out CI runs, dep bumps, and "bump version" commits. Find the last commit that changed behavior or fixed a real issue.

Score 0 (red): Last meaningful commit > 18 months ago. The maintainer is gone or checked out.
Score 1 (yellow): 6–18 months. Maintenance mode, possibly zombie.
Score 2 (green): Within 6 months. Active.

Signal 3: Release cadence (weight: 20%)

How often do tagged versions ship?

How to check: git tag --sort=-creatordate | head -10. Look at the gap between recent releases.

Score 0 (red): No release in 24+ months. Either done or dead.
Score 1 (yellow): Releases every 12–24 months. Slow but alive.
Score 2 (green): Releases within 12 months. Steady.

Signal 4: Issue response time (weight: 20%)

When someone files a bug, does anyone answer?

How to check: Open 5 random issues from the last 6 months. Read the maintainer's first reply (if any). Time from issue open to first response.

Score 0 (red): No responses on >50% of recent issues. Maintainer isn't watching.
Score 1 (yellow): Responses within 1–4 weeks. Slow but present.
Score 2 (green): Responses within 1 week. Engaged.

The scoring rubric

Add the four weighted scores:

0.0 – 0.4 (red): Walk away. This dependency is abandoned or about to be. Find an alternative or fork it before you adopt.
0.4 – 0.7 (yellow): Proceed with eyes open. Add a tracking issue to monitor bus factor and dormancy. Plan an exit.
0.7 – 1.0 (green): Healthy. Ship it.

The score is intentionally simple. It catches the obvious cases. The middle of the distribution — projects that are technically alive but showing one or two warning signs — needs a deeper look. That's what the full audit is for: transitive dependency analysis, dormancy prediction, and a bus factor at the org level.

What to do if the score is bad

Three options, in order of effort:

Replace. Find an actively maintained alternative. Most "abandoned" libraries have a successor — the maintainer just didn't do the handoff. The BreakPoint feed lists projects looking for new maintainers, many of which are healthy forks or successors.
Adopt. If the project is small enough and the license permits, take it over. The maintainer handoff guide walks through it. This is the right move for a critical dependency that has no good alternative.
Fork. Last resort. Fork the last good version, freeze on it, and plan to migrate when something better comes along. This works for code that's stable enough to not need updates.

Need the full picture?

A 5-minute triage catches the obvious cases. The full /audit walks your transitive dependency graph, scores dormancy risk, and gives you a one-page memo you can hand to your CTO. Free, no signup.

Run the full audit →

The 4-signal score

The scoring rubric

What to do if the score is bad

Need the full picture?

Related reading