Project Health & Bus Factor: Measure and Reduce Key-Person Risk

Decision: If your project’s bus factor is 1, treat it as a P0 risk. Measure it today with truckfactor (pip-installable CLI) or git-truck (visual, npx -y git-truck). Track CHAOSS Contributor Absence Factor over time. Target ≥ 3 for any production-critical system. The 2024 XZ Utils attack was bus factor 1 in practice — one burned-out maintainer plus one patient attacker came within a hair of compromising SSH on every major Linux distribution [15].

What is Bus Factor?

Bus factor — also called truck factor, lottery factor, or circus factor — is the minimum number of team members who must suddenly disappear before a project stalls due to knowledge loss [1]. The concept dates to 1994 discussions about Python’s sole dependence on Guido van Rossum [12]. Crucially, it counts only irreplaceable personnel — losing a replaceable member doesn’t move the number.

The Industry Numbers

Empirical data is sobering. A 2015 study of 133 popular GitHub projects found [1]:

• 65% had bus factor ≤ 2
• Less than 10% had bus factor > 10

Longitudinal follow-up is worse: in 16% of real projects all key engineers eventually departed, and only 41% of those continued meaningful development afterwards — recovery typically took up to 6 person-months, and some subsystems required complete rewrites [18].

OpenSSF Scorecard ⭐ 5.5k (Jun 2026) requires bus factor ≥ 2 for its best practices badge [8].

How to Measure

Degree of Authorship (DOA) — the standard algorithm

Introduced in a 2015 IEEE study [14], DOA scores each developer per file by weighting three factors:

1. Did they originally create the file?
2. How frequently have they modified it (last 90 days)?
3. What fraction of the file’s total changes do they own?

A developer is an author when their DOA score exceeds 0.75 of the maximum DOA for that file [2]. Bus factor = the smallest set of authors who together cover 50%+ of all files.

Simpler proxy (good enough for most teams)

Rank contributors by lines changed. The minimum number of people whose combined contributions exceed 50% of all changed lines is a reasonable proxy [11].

Key caveat: project-level bus factor often masks higher concentration in critical subsystems. Analyse auth/, CI/, data-layer/ separately [17].

Tools

Recommended starting point: truckfactor for a quick number; git-truck to explore which files are concentration points and decide where to focus cross-training.

Project Health Frameworks

CHAOSS Starter Model

CHAOSS [19] is a Linux Foundation project defining shared metrics for open source community health. Its Starter Project Health model [3] defines four foundational metrics:

VMware’s internal guideline targets responses within two business days; declining closure ratios signal maintainer overload — an early-warning sign for bus factor collapse [3].

CHAOSS OSS Viability Signals [4]

CHAOSS’s viability model adds committer trends (90% drop in 3 months = dying project), forks, and libyears (dependency freshness as a shared-maintenance proxy).

OpenSSF Scorecard [9]

Scorecard automates 18 checks scored 0–10, compiling into a weighted aggregate. Relevant to bus factor: the Contributors check flags projects where fewer than 2 distinct companies have committed recently; Code-Review flags whether all recent changes were reviewed by someone other than the author [9].

The XZ Utils Warning Shot

In March 2024, CVE-2024-3094 (CVSS 10.0) was discovered in XZ Utils, a compression library present in virtually every Linux distribution [15]. An attacker spent two years building trust, then exploited the burned-out single maintainer — exhausted and feeling unsupported — to gain co-maintainer access and insert a backdoor into OpenSSH authentication paths.

CISA’s response: “The burden of security shouldn’t fall on an individual open source maintainer — companies consuming open source software must contribute back, either financially or through developer time, to ensure healthy and diverse maintainer communities resilient to burnout.” [16]

A newer risk vector: “bus factor 0” — LLM-generated code that no human has read or understood — creates knowledge ownership vacuums that look like working software but carry hidden fragility [20].

How to Improve

Key principle: documentation captures what, but only pair programming and rotation build the tacit knowledge that actually raises bus factor [2] [10]. For open source dependencies, Knowledge Islands [13] can surface which upstream subsystems carry concentrated risk before you adopt them.

Making It a Repeatable Practice

1. Run monthly: truckfactor <repo> and record the output in your team’s metrics dashboard.
2. Drill per-directory: a project at bus factor 4 can still have auth/ at bus factor 1 [17].
3. Set a floor: OpenSSF recommends ≥ 2 [8]; target ≥ 3 for production-critical systems.
4. Treat maintainer burnout as a leading indicator: contributor mood and response-time trends signal bus factor collapse before commit counts do [4].
5. Audit dependencies: before adopting a new library, run its repo through Scorecard [9] or check its CHAOSS Contributor Absence Factor [3] — don’t inherit someone else’s bus factor 1.