The Maintainer Bus-Factor Score for a Dependency You Rely On

You are about to build on an open source project, or you already depend on one, and you need to know how exposed you are if its main maintainer walks away. This guide is for engineering managers, technical founders, developer-relations leads, and technical sourcers who have to make that call before it becomes an incident. It gives you a repeatable way to compute a bus factor from public git history, correct the identity error that makes the number look falsely reassuring, and turn the corrected score into a keep, mitigate, or replace decision with a named owner.

The bus factor - also called the truck factor - is the smallest number of people who could leave a project before the surviving contributors no longer cover enough of the code to keep it going. Most guides either study projects that have already stalled or debate the weight of a single contribution. Almost none give you a method to score how concentrated an actively-maintained dependency's knowledge is while it still looks healthy, and none correct for the author-aliasing trap that inflates the number. That gap is this guide.

Why the raw bus factor lies to you

The raw bus factor is an over-estimate by construction, because it counts distinct author identities and a single person routinely commits under several. Before you count anything, you merge identities, and merging can only hold the count steady or push it down.

This is the single most important fact in the discipline: the bus factor is monotone non-increasing along the de-aliasing ladder. Every correction is a correction in the same direction. When the World of Code project mapped author identities across the open source graph, it folded 106,826,059 raw author strings down into 62.7 million real identities, with the largest single person's cluster reaching 6,910 distinct strings. Once those merges land, "safe-looking" projects collapse.

A solo maintainer who commits from a work address, a personal address, and a GitHub noreply address will show a bus factor of three. Nothing about that number is a lie in the arithmetic; the lie is in the identities. This is why a tool run on a fresh clone, with no alias file, produces the most reassuring and least trustworthy number you can get. The correction is not optional polish. It is the difference between a defensible score and a dangerous one.

The thresholds that carry weight

The load-bearing convention is 50%: the bus factor is the smallest set of contributors whose cumulative share first reaches half of the project's commits, or half of its file ownership. That threshold appears in every serious source and you should treat it as the default.

Three definitions share this spine. Avelino and Valente's truck factor uses a Degree-of-Authorship model and greedily removes top authors until the survivors cover less than half of the current files - a system faces serious delays or is likely discontinued past that point. Daniel Gruno's Pony Factor at Apache is the commit-based analogue: the smallest number of contributors who committed 50% of the codebase in the trailing two years. The World of Code map uses the minimum number of developers whose cumulative share first reaches 50% of commits. A separate 80% Pareto threshold with a named primary source was not established in the literature I have, so I do not use one. Treat 50% as the line.

The critical marker at the bottom is a corrected bus factor of one, the single point of failure. It is not rare. A 2026 stability study found that in unstable repositories, 86% of activity concentrates among a few maintainers, with the top three contributors accounting for over half of commits across five years, and it reports an odds ratio of 24.57 between commit instability and that top-three concentration. Concentration, not volume, is what predicts fragility.

What correction does to the numbers

De-aliasing does not nudge the picture; it inverts it. Once World of Code merged identities, single-point-of-failure projects rose from 90.15% at the raw level to 96.48% at the final corrected level, and solo-owned projects rose from 63.71% to 83.97%.

Read the table below as a warning about your own tooling. If you stop at the raw row, you are reading a fiction. The corrected rows are the reality your dependency actually lives in.

The correction runs one way for a reason. But there is a second error waiting in the same step, and it runs the other way.

Project score versus file hotspots

A single project-level number flatters a repo whose core files each rest on one person. The real exposure lives at the file level, so you compute concentration on the critical paths, not just for the repo as a whole.

Even projects that look distributed hide single-owner files. In World of Code's corrected map, 90.58% of all (project, file) pairs are owned by one developer - roughly nine in ten files. A project with a bus factor of four can still have every hot file in its core resting on one person, which is exactly the situation that hurts you when that person leaves.

The practical move is Degree-of-Authorship at the file level: for each critical file, find who has edited the most lines, and name the single-owner hotspots. The truckfactor tool does this natively - it assigns each file to whoever edited the most lines, then removes low contributors while over half of files keep an owner. When you report exposure, report the hotspots, not just the headline.

Compute the score: the procedure

Here is the end-to-end method. It moves from a raw clone to a tiered decision, correcting the aliasing error in step two and cross-checking non-commit knowledge before you commit to a tier. Budget roughly two hours for a dependency you have not scored before.

For step three, pick a tool that suits the depth you need. truckfactor by HelgeCPH is pip-installable and fast for a single number. The ASERG/UFMG Truck-Factor is Avelino and Valente's reference implementation. JetBrains Research's bus-factor-explorer gives you a treemap and a turnover simulation, and Knowledge Islands visualizes per-file concentration. csDetector reported 0.97 truck-factor-smell accuracy against 0.84 for Avelino's algorithm on a supplemented dataset, so if you are automating the smell classification it is worth a look.

The channels a commit-based score misses

A commit-based score misses the people who carry a project without committing much: reviewers, test authors, documentation writers, tool maintainers, and release signers. You correct for this by cross-referencing the key-person list against those channels before you finalize the score.

Survey work behind the truck-factor line found developers named as key despite few commits, who contributed through social interactions, code reviews, test writing, documentation, and tool support. There is a deeper warning too: the author field on a commit is a claim, not an attestation. A name in a commit can be fabricated. The xz utils backdoor is the canonical case - a co-maintainer persona was cultivated over a roughly 2.6-year social-engineering campaign, and the damage was done with only about 8 malicious commits, on a project with a bus factor of one. The person who took over managed releases and trust, not just code, which is exactly what a commit count fails to capture.

A name in a commit is a claim, not an attestation, and release trust is where the costliest failures actually enter.

So your key-person list should reflect who reviews the pull requests, who signs the releases, and who holds the governance keys. If those roles concentrate on the same person your commit count flagged, the risk is worse than the number says. If they spread across people the commit log ignored, your bus factor was too pessimistic and you can say so with evidence.

Once you have a corrected score and a named key person, the next question is whether you could actually replace them. That is a sourcing question, and it is where I use Refolk.

The bench decides keep versus replace

The score tells you the exposure; the replacement bench tells you the cost of that exposure. A bus factor of one on a common stack is recoverable because you can hire or contract a successor. On a rare stack it may not be, and the same number becomes a much larger risk.

This is where the decision stops being purely about git history. In Refolk's index, 134,160 US profiles list Kubernetes against 3,381 that list Rust - a 39.7x deeper replacement bench for the cloud-native skill. Narrow the market and it gets thinner still: 967 profiles list Rust in Germany. So a Rust dependency maintained by one person in a small European market is a fundamentally different exposure from a Kubernetes tool with the same bus factor of one, even though the two scores are identical.

Read the table as recovery capacity. The rarer the skill and the smaller the market, the fewer people can step in, so the more weight the score should carry in your decision. Sizing that pool by hand across GitHub and LinkedIn is slow; asking Refolk in plain English for maintainers of a specific ecosystem in a specific market returns the bench directly, which is what makes the keep-versus-replace call defensible rather than a guess.

From score to tier: keep, mitigate, replace

Map the corrected project score, the file hotspots, and the bench depth onto three tiers. Keep means the risk is acceptable and monitored. Mitigate means you accept the dependency but buy down the risk. Replace means the exposure is too high to hold.

Use the recent-window score to break ties. If the lifetime bus factor is three but the trailing 12-month score is one, treat the dependency as bus factor one, because history does not maintain the release you ship tomorrow. And remember the mid-pyramid trap: the costliest failures are not the dependencies you chose directly but the transitive ones. xz was reached via libsystemd - low visibility, high reach, bus factor one. Score your critical transitive dependencies, not only your direct manifest.

How this goes wrong

Most bad bus-factor calls come from a small set of repeatable errors. Each has a false direction and a specific check. This is the part of the method to internalize, because a confident wrong score is worse than no score.

• Alias inflation (false negative). A solo maintainer on three emails shows a bus factor of three. Check: de-alias first. World of Code's single-point-of-failure rate jumps from 90.15% to 96.48% once identities merge.
• Over-merge (false positive). Merging on shared strings like root or a noreply address welds strangers into a fake super-developer and understates the score. Check: never merge on generic or placeholder identities.
• Lifetime-versus-recent blind spot. A project with 20 historic contributors can be one active person now. Check: recompute over the trailing 12 to 24 months and treat the gap as the signal.
• Project number hides file hotspots. A project bus factor of four can sit on files that are 90.58% solo-owned. Check: compute file-level Degree-of-Authorship on the core paths.
• Commit-only tunnel vision. Reviewers, docs writers, and release signers carry knowledge the log misses; the xz key person managed releases and trust. Check: cross-reference issue and PR reviewers and release managers.
• Volume mistaken for health. High throughput is not stability - the stability study found a 40k-commit-a-year project unstable at all granularities. Check: measure concentration and rhythm, not activity count.
• Author field trusted as identity. A name is a claim, not an attestation, and a co-maintainer persona can be fabricated, as with xz's "Jia Tan". Check: look at signing and provenance and the pace of trust escalation.
• Thin external bench ignored. A bus factor of two is small comfort if the skill is rare; Rust in Germany shows 967 profiles against 134,160 for Kubernetes in the US. Check: size the replacement pool before you choose "keep".

The stakes on the last two are not hypothetical. An OSSRA analysis of over 900 risk-assessed applications found 49% contained open source components with no new development in two years - a fleet of quiet single-maintainer dependencies waiting for the maintainer to walk. Nearly two-thirds of popular GitHub projects were found to have just one or two maintainers, and in one snapshot four developers made over 70% of Fastlane commits and nearly half of pandas commits. Concentration is the norm, not the exception.

Before you call it done

Run this checklist against every dependency you tier. It catches the errors above and forces you to record a decision someone else can audit.

Keeping the score current

A bus factor is a snapshot, and maintainers leave. Re-score on a fixed cadence and on trigger events, because the number that was safe last quarter can be a single point of failure today.

Recompute the trailing-window score whenever a dependency ships a major release, whenever a named key person's activity drops, and on a standing quarterly cycle for anything in the mitigate or keep-with-a-watch tiers. The recent-window score is your early warning: a lifetime bus factor holds steady for years while the active bus factor quietly falls to one. When it does, move the dependency up a tier and act on the matching action. If the tier is replace or mitigate, the successor search is a sourcing job - name the skill, the market, and the seniority you need, and pull the bench before the maintainer is already gone rather than after.