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 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