Scoring Maintainer Concentration Risk Before You Depend on a Repo

You are about to add a dependency, and one question decides whether that is safe: does this project die if one or two people walk away? This guide is for engineering managers, technical founders, and technical diligence readers who need to turn that question into a repeatable score from public commit history, review activity, and release cadence. It delivers a scoring model that ends in one of three verdicts - safe to depend on, depend with a named mitigation, or avoid - each backed by the number that justifies it.

The dependency adoption standard already tells you when a library is fit to add, and the repository reference already defines what each signal proves. Neither turns the human question into a score. This guide is the one dimension both skip.

What maintainer concentration risk is, and why last-commit-date misses it

Maintainer concentration risk is the chance that a project stops being maintained because too few people carry it. The measure of that risk is the bus factor, now formally the CHAOSS Contributor Absence Factor: the smallest number of contributors responsible for 50% of total contributions. A factor of 1 means one person's departure orphans the project.

Generic "is this dead?" checklists stop at the last commit date. That proxy has broken. Auto-merged bot pull requests keep a departed maintainer showing as the merge author, so a cadence check now reports "alive" for a project no human is steering. The metric reports the same number for one engaged maintainer and one departed maintainer whose token still works. Concentration risk is a different axis from liveness, and you need both.

The uncomfortable baseline is how normal concentration is. In the foundational study of 133 popular GitHub applications, 65% have a truck factor of two or less, and within that corpus 46% sit at exactly 1 and 28% at exactly 2. A later validation oracle of 35 well-known systems found 57.1% at a factor of 1 and 14.3% at 2, with only two systems above 10: saltstack/salt at 11 and symfony/symfony at 15. A recomputation over the top-starred repositories reached the same 65%.

The lesson is that a low factor cannot by itself be disqualifying. An "avoid everything with bus factor 2" rule rejects most of the ecosystem. The score must weight replaceability and cadence, not the raw number alone.

The concentration distribution: what "normal" actually looks like

Before you score a single repo, calibrate against what the literature found, so a factor of 1 or 2 reads as common rather than alarming. The table below aligns three independent studies on the same measure. Read it as your reference distribution.

Three studies, three corpora, one shape: most projects are carried by one or two people, and the high-factor tail is thin. When your own number lands at 1 or 2, you are in the majority, not the outlier. That is why the danger threshold of 1 or 2 is a trigger to investigate, never an automatic verdict. CHAOSS puts the mechanism plainly: with an absence factor of 1, burnout or other factors could mean the sole contributor stops maintaining the project.

The signals to compute, and what each proves

There is no single number. You compute a small family and reconcile them, because each catches a failure the others miss. Here is what each proves and what it looks like when it lies.

• Contributor Absence Factor (pony factor). Counts the smallest set of contributors covering more than 50% of contributions, all time. Proves how concentrated the workload is. It lies when bots inflate contribution counts, making a departed maintainer look present.
• File-ownership truck factor (degree of authorship). For each file, finds the single contributor who wrote the most lines, then simulates removing owners in order until 50% of files are orphaned. Proves who holds the code knowledge. It lies less than commit counts, which is why you run it as the cross-check.
• Elephant factor. Applies the same 50%-share calculation over employer affiliations. Proves organizational concentration. It lies when five contributors all work for one vendor and the individual factor reads 5 while the real risk is 1.
• Scorecard Maintained check. Highest score requires at least one commit per week over the previous 90 days; archived scores lowest. Proves liveness. It lies when bot commits carry the cadence.

The reconciliation step is where most reads go wrong. Someone with many trivial commits looks like a co-maintainer but owns no files. The commit-count lens counts them; the file-ownership lens does not. When the two numbers split, the file-ownership number is usually closer to the truth about who the project cannot survive losing.

How to score a repository, step by step

Score in a fixed order so two analysts reach the same verdict. The academic literature leads with authorship concentration; activity-first checklists lead with cadence. This procedure leads with concentration and treats cadence as the liveness gate, because concentration is the durable property and cadence is the one bots can fake.

Steps 1 through 5 are analyst work, roughly two hours. Steps 6 through 8 pull in the engineering manager or founder who owns the adoption decision, because replaceability and verdict are judgement calls about your own team and budget, not properties of the repo.

Attributing the humans: who are the fifty-percent contributors

The score is a number; the mitigation is people. Once you have the concentration factor, you have to name the individuals it points to and find out where they are. Step 6 is where a filed metric becomes a decision you can act on, and it is the step most desks skip.

You need three things about each 50%-share contributor: who they are, who employs them, and whether they are active elsewhere but absent here. The employer question feeds the elephant factor directly - if the top contributors all draw a paycheck from one vendor, your real exposure is that vendor's roadmap, not the count of names. The elsewhere-but-absent question is your early warning: a maintainer still shipping on other projects while going quiet on yours is drifting, and the drift precedes abandonment.

This is contributor sourcing, and it is slow by hand: cross-referencing commit emails against public profiles, checking current employers, and confirming who is still active. Refolk collapses that into one query. Instead of manually reconstructing a maintainer's current footprint, you ask in plain English and get the person, their employer, and their recent activity across the public GitHub graph, LinkedIn, and the open web.

The output of step 6 is a named list with current activity. That list is the raw material for step 7, because you cannot cost a mitigation you cannot name.

Replaceability decides the verdict, and it is geographic

A low factor is only fatal if you cannot replace the person. Replaceability is the load-bearing variable, and the sobering statistic is the recovery rate: only 41% of projects fully recovered their maintenance activity after losing their truck-factor developers. "It's open source, someone will fork it" is wrong more than half the time. The mechanism is that forking requires re-accumulating the file-level knowledge that the file-ownership metric already told you was concentrated in the person who left.

So replaceability is not a hope; it is a costed plan. It has three forms, ranked by cost: fork and staff it yourself, fund the existing maintainer, or hire a replacement from the open market. Whether the last one is real depends on the talent pool for that skill, and the pool is lopsided.

In Refolk's index, the United States returns 1,412 profiles whose title includes maintainer or core-maintainer variants, against 47 in Germany - a 30x gap. The same fork-and-hire mitigation that is credible in the Bay Area is far thinner in Berlin, where that German pool concentrates. Top US employers for that pool include Akuity, Okta, and Svix, which tells you where the hire-able people actually work. The practical consequence: for a US-centric skill you can plausibly cost a hire; for a niche or non-US ecosystem, forking and staffing internally may be your only real option, and you should say so in the verdict.

How this goes wrong: the failure modes

Most bad scores come from trusting one signal that lied. These are the seven ways the read fails, each with the check that catches it. Treat this section as the one you reread before you sign off.

• Bot-inflated cadence. A repo scores maintained because Dependabot commits weekly. The metric reports the same number for an engaged maintainer and a departed one whose token still works. Check: filter bot and auto-merge authors before counting.
• Commit-count versus file-ownership disagreement. Many trivial commits make someone look like a co-maintainer who owns no files. Check: compute the file-ownership truck factor alongside the pony factor and reconcile them.
• Feature-complete false positive. A stable utility gets an "avoid" for low activity. A library that determines if an integer is even does not normally need maintenance. Check: apply the feature-complete override and test issue and security responsiveness before penalizing.
• Elephant-factor blind spot. Five contributors all work for one vendor; the factor looks like 5, the real risk is 1. Check: cluster contributors by employer.
• Fork illusion. High fork count is read as community resilience, but most forks are dead clones. Check: confirm forks have divergent, recent commits, not just clones.
• Recovery optimism. Assuming a popular abandoned project attracts a rescuer, when only 41% recover. Check: require a named, costed mitigation, not "someone will fork it."
• Social-engineering inversion. A new co-maintainer relieving a burned-out solo owner reads as an improved bus factor but was the exact XZ attack vector. Check: verify the identity, tenure, and review history of newly added maintainers.

The XZ case is worth holding in view because it inverts the whole model. The threat actor began contributing almost two years before the payload, slowly building credibility until they were handed maintainer responsibility. The first backdoor commit landed on 22 January 2024, version 5.6.0 shipped on 24 February, and Andres Freund disclosed it on 29 March. Distributions reverted within 24 hours. The metric said the project got safer at the moment it got fatally compromised.

A rising bus factor is a signal to verify a new maintainer, not a reason to relax.

The other landmark, Heartbleed, is the resourcing failure the model is meant to catch upstream. OpenSSL ran on roughly two-thirds of SSL sites while receiving about $2,000 a year in donations. After disclosure the foundation took in nearly $9,000, and the Core Infrastructure Initiative then funded two full-time developers and a security audit. The concentration was structural and visible in advance; nobody was scoring for it.

Both incidents share a root cause the concentration score is built to surface: a load-bearing dependency carried by too few, too tired, too unfunded people.

The sign-off checklist and keeping the score current

A verdict is done when every item below is true. Run this before you record safe, depend-with-mitigation, or avoid.

The score decays, so treat it as a living record, not a one-time gate. Two things move: cadence and people. Re-run the Scorecard Maintained check on your own schedule - it is only valid for projects older than 90 days and measures the trailing 90-day window, so a quarterly recheck matches its native resolution. Re-attribute the humans whenever a release slips or an issue thread goes unanswered, because a maintainer active elsewhere but silent here is your earliest drift signal. When a new co-maintainer appears, do not update the factor upward until you have verified them; the XZ pattern is that the addition looks like good news the moment before it becomes the incident.

Keep one artifact per dependency: the factor, the named contributors, the mitigation, and the date you last checked. That record is what turns a one-off read into a standard your team can rely on, and it is what lets you answer the only question that matters when a maintainer walks away - "do we already have a plan?" - with a yes.