Repository metrics

Maintainer resilience

How inspect.software measures bus factor, contributor concentration, and breadth — whether a project can survive losing its top maintainer. 7.2% of the index.

Methodology v1.13.0Updated 2026-07-21

Maintainer resilience asks the uncomfortable question: can this project survive losing its most important person? The pattern it measures — a single maintainer carrying essentially all of the work — is the most common structural failure mode in open source, and it is invisible in commit counts and stars.

  • Category: Sustainability & Governance (30% within category)
  • Weight in overall index: 7.2%
  • Metric key: maintainer_resilience
  • null when the contributor list is unavailable, or when every contributor turned out to be an automation account

How the value is computed

ComponentWeightCriteria
Bus factor54v0.9.0 bus-factor curve, scaled to 54 points
Commit distribution22.5(1 − top contributor's share of human commits) × 22.5
Contributor breadth13.5min(13.5, human contributors sampled × 1.35)
OpenSSF Scorecard: Contributors10Scorecard's 0–10 result, scaled to 10 points

The bus factor is the smallest number of contributors who together account for the majority of the work — the number of people whose departure would stall the project.

Every figure here counts people only. Automation accounts are removed before the bus factor, the distribution, or the breadth is derived, because a release robot cannot inherit a project. The removal is not cosmetic: in several widely used repositories, dependency bots rank second and third among all contributors by commit count, and counting them made the maintainer base look broader and less concentrated than it is. Only automation carrying a GitHub App identity is recognized, so a bot operating under an ordinary user account is still counted as a person.

The Scorecard component measures contributing organizations/companies, a useful complementary signal of institutional resilience. It also remains part of Security and is excluded here if unavailable or n/a.

Why the curve is shaped this way

The jump from a bus factor of 1 to 2 (10 → 28 points) is the largest single step in the methodology, because it is the largest real-world risk reduction: the difference between a project with a single point of failure and one without. Returns diminish beyond 4–5 — once several people genuinely share the work, adding more changes little.

Commit distribution complements the bus factor: a project can technically have five contributors while one person authors 95% of the changes. The distribution component makes that concentration visible.

Reading the result

  • A low value on a high-Vitality project is the classic solo-maintainer profile: productive today, fragile tomorrow.
  • Cross-read with stewardship — organization backing mitigates (but does not remove) the risk this metric measures.
  • Contributor data is sampled from the repository's public history. Automation accounts are reported — the count removed is echoed in the report alongside the other inputs — but they are excluded from every figure scored here.
  • For the displayed top ten contributors, authenticated scans also collect self-published GitHub profile name, location, company, and public organization memberships in one batched request. This enrichment is not used in the score and is withheld from public API and HTML reports; it supports internal identity-resolution research without changing the bus-factor calculation.

Improving the value

  • Grant review and merge rights to at least one more person — moving the bus factor from 1 to 2 is the single biggest gain available.
  • Actively distribute work: route reviews and releases across maintainers rather than through one person.
  • Convert recurring contributors into maintainers; breadth counts, and the pipeline starts with community health.

Related: stewardship · Sustainability & Governance