# Unmaintained-Scanner Pressure

Most automated supply-chain scanners (Snyk, Dependabot's freshness signals, npm-audit-style tools, internal-corporate equivalents) flag dependencies that haven't cut a release in some threshold period — commonly 12 months — as **unmaintained**. The intent is sensible: a project nobody is updating is a project nobody is patching, and dependents should know.

The failure mode is that *correctly-maintained mature infrastructure libraries often release in bursts.* fsnotify is the canonical example: cross-platform filesystem notifications is a finite, well-understood problem; the library is in correct, stable, working condition; there is genuinely nothing to release for long stretches. The scanner's binary "stale = bad" heuristic generates pressure regardless.

## The pressure cascade

1. Library has nothing to release for 12 months because it works correctly.
2. Scanner flags it as unmaintained.
3. Downstream users file issues asking for a release.
4. A new contributor steps forward to cut one.
5. Access changes happen. From outside, the access changes look like the early stages of a takeover.
6. Downstream goes into [[maintainer-governance-ambiguity|verification mode]].

The April 2026 fsnotify issue (#735) is step 2-3 of this cascade made explicit: *"Automatic code scanners consider this project as unmaintained if no new release is available within the last 12 months. This project crossed that threshold on April 4th 2026."* That issue is part of what motivated [[mattn]] to step in and resume maintenance, which is what set off the dispute documented in [[fsnotify-maintainer-dispute]].

The scanner did the right thing on its own metric. The result was that a stable project was pressured into churn that, several steps downstream, produced a near-supply-chain-incident.

## Better signals

The structural fix is to replace single-threshold heuristics with signals that distinguish "abandoned" from "stable":

- **Open issue / PR responsiveness** — does the project answer security reports within reasonable time, even without releasing? This is the relevant question for downstream risk, not release cadence.
- **Bug-fix-merge cadence** — even if no version is cut, merges to `main` track whether anyone is actually paying attention.
- **CI green on latest commit** — does the project still build and pass tests against current language versions?
- **Maintainer presence in adjacent ecosystem activity** — public commits elsewhere, conference talks, mailing list activity. Doesn't require any project-internal data.

None of these are perfect. The combination of two or three is much better than "did they cut a release this year."

## What downstream tooling owners can do today

If you control a scanner config:

- Raise the threshold to 24 months for low-churn infrastructure libraries (file watching, time parsing, terminal capability detection — the stable layer).
- Pair the staleness flag with one of the better signals above so the alert reads as "stale *and* unresponsive," not just "stale."
- Suppress the alert if the maintainer is known to be a long-running, healthy OSS contributor with activity elsewhere (cheap heuristic: GitHub public-event timeline non-empty in last 6 months).

If you control a scanner product:

- Document, in marketing copy, that staleness alone is not a vulnerability — and that pressuring projects into release-for-the-sake-of-release worsens rather than improves dependent security.

## Cross-references

- [[supply-chain-security]]
- [[maintainer-governance-ambiguity]] — the downstream effect when the cascade plays out
- [[fsnotify-maintainer-dispute]] — the worked example