End-of-Life and Maintainer Activity Check¶
Maintenance-health diagnostic — instantiates Substrate Lineage Risk Audit
Assesses whether an inherited substrate is still alive — within its support window and actively maintained upstream — so a component everyone assumes is cared-for isn't quietly abandoned.
A dependency can be flawless today and still be dying — its support window closing, its maintainers gone quiet. End-of-Life and Maintainer Activity Check takes a point-in-time reading of a substrate's liveness: is it inside its published support window, and is anyone actually home upstream? It reads two signals nothing in the code reveals — the lifecycle signal (end-of-life dates, supported-version policy) and the maintainer-activity signal (release cadence, recent commits, issue responsiveness, how many hands are on it). Its defining move is that it evaluates human and lifecycle health rather than code contents, catching the one risk no scanner flags because nothing is broken yet: the slow expiry of support.
Example¶
A fintech service inherited a stack pinned to a language runtime approaching its vendor end-of-support date, and it leans on a niche open-source library for currency rounding. The check pulls the runtime's published end-of-life calendar and inspects the library's repository: last release roughly two years ago, open security issues unanswered, a single maintainer long inactive. It reports two support states — runtime "sunsetting in ≈7 months," library "effectively abandoned." Neither shows up in any test; the code runs fine today. But both are unowned upstream, and that reframes them from "working dependency" to "risk with a clock on it" — the kind of finding that has to arrive well before the clock runs out to be actionable.
How it works¶
- Read the support state. For each inherited substrate, pull published end-of-life / end-of-support dates and supported-version policy.
- Read the maintainer signal. Inspect release cadence, recent commit activity, issue and pull-request responsiveness, and the number of active maintainers.
- Classify liveness. Mark each substrate supported, nearing end-of-life, or abandoned.
- Flag the stewardship gap. Where no active maintainer exists upstream, raise it — an unmaintained substrate forces the question of who owns it now.
Tuning parameters¶
- Activity window — how far back "recently maintained" looks; short windows over-flag quiet-but-finished projects, long ones miss recent death.
- Support-source authority — vendor end-of-life calendars versus community heuristics; authoritative dates are crisp, inferred ones fuzzy.
- Abandonment threshold — how quiet a project must be before it's called abandoned; stricter catches decay early, looser reduces false alarms.
- Bus-factor sensitivity — whether a single-maintainer project is flagged on that basis alone, regardless of recent activity.
- Check cadence — a one-shot reading at intake versus a periodic re-check as the clocks advance.
When it helps, and when it misleads¶
Its strength is catching the risk no vulnerability scanner sees, because nothing has failed: a substrate whose support is quietly expiring or whose upstream has gone dark.
Its weakness is that liveness signals are noisy. A stable, "finished" library can look abandoned, while a busy repository can still be unresponsive on security specifically. And any point-in-time reading goes stale — today's supported runtime is next year's end-of-life.[n1] The classic misuses are treating a single recent commit as proof of health, and using a green check to defer a migration indefinitely. The discipline is to distinguish "quiet because finished" from "quiet because abandoned," and to re-run the check as the clock moves rather than trusting one snapshot forever.
How it implements the components¶
End-of-Life and Maintainer Activity Check fills the freshness-and-stewardship slice of the archetype — the part that reads whether the substrate is still alive and cared-for:
substrate_freshness_and_support_state— its core output: a supported / nearing-end-of-life / abandoned reading for each inherited substrate.substrate_stewardship_owner— it reads whether an active upstream steward exists and flags the gap when one doesn't, forcing the question of internal ownership.
It does not continuously watch for new advisories against these substrates — that live subscription is Upstream Advisory Monitor's job — and it does not enumerate the substrates to check in the first place; that inventory comes from Dependency Tree Static Analysis and Software Bill of Materials with Lineage.
Related¶
- Instantiates: Substrate Lineage Risk Audit — it reads the liveness dimension of inherited risk that contents-based checks miss.
- Consumes: Dependency Tree Static Analysis supplies the inventory of substrates whose support state to assess.
- Sibling mechanisms: Upstream Advisory Monitor · Dependency Tree Static Analysis · Software Bill of Materials with Lineage · Legacy Substrate Architecture Review
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: End-of-Life and Maintainer Activity Check operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it assesses whether an inherited substrate is still alive — within its support window and actively maintained upstream — so a component everyone assumes is cared-for isn't quietly abandoned.
Independent corroboration: The frozen evidence defines End-of-Life and Maintainer Activity Check as 'Assesses whether an inherited substrate is still alive — within its support window and actively maintained upstream — so a component everyone assumes is cared-for isn't quietly abandoned', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Software dependency and lifecycle management cohered support-window and maintainer-activity checks as indicators that an upstream component is becoming abandoned.
Related originating lineages:
- Organizational & Management Science — Vendor and lifecycle governance supplies support commitments, ownership continuity, and end-of-life planning.
Review resolution: The current reviewers agree that computer_science is primary. For the reported differences (alternate_origin_disagreement, encyclopedia_synthesis_disagreement), the evidence supports single_lineage, specialized, and organizational_management; these choices preserve materially formative origins without conflating later domain reach.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Freshness is a moving property, and this check is a snapshot of it — so it pairs naturally with Upstream Advisory Monitor for the continuous view. A one-time pass at intake silently expires: the substrate that was supported when you adopted it crosses its end-of-life date on a schedule the check has to be re-run to catch.
[n1] The "bus factor" is the number of key maintainers a project would have to lose before it stalls. A low bus factor — often a single maintainer — is a maintenance-risk signal independent of recent activity, which is why maintainer count, not just last-commit date, belongs in this check. ↩