To calculate a dependency's bus factor, count commits per contributor, sort from highest to lowest, and add them until you pass 50 percent of the total. The number of people it took is the factor. A result of 1 or 2 means a few people carry the project.
Definition
CHAOSS, a community that defines open source health metrics, now calls this the contributor absence factor, formerly bus factor. It asks how much risk a project faces if its most active contributors leave. Lower values mean a few people do most of the work. Higher values mean more resilience.
The metric can be applied to commits, issues, comments or documentation. Commits are the simplest place to start.
The calculation, step by step
- Collect a count of contributions per person for a fixed period.
- Sort the counts from highest to lowest.
- Work out 50 percent of the total.
- Add the top counts in order until the running sum passes that threshold.
- The number of people added is the factor.
CHAOSS gives a worked example with eight contributors:
| Contributor | Commits |
|---|---|
| A | 1000 |
| H | 433 |
| F | 343 |
| E | 332 |
| B | 202 |
| C | 90 |
| G | 42 |
| D | 33 |
The total is 2,475, so the 50 percent threshold is 1,237.5. The top two (1,000 and 433) add to 1,433, which passes it. The factor is 2.
Running it on a real repository
On a local clone, this command lists commit counts per author for the last year:
git shortlog -sn --no-merges --since="12 months ago"
Paste the counts into the steps above. Two cautions apply. The same person can appear under several emails, so merge them first. And bots can inflate one name, so exclude automated accounts before you sort.
Reading the result
A low number is not automatically a reason to reject a package. Many small, well made libraries have one or two authors. What matters is the combination:
- Factor of 1 plus no recent releases: a real continuity risk.
- Factor of 1 plus a security policy, recent releases and fast responses to reports: acceptable for many uses, with a monitoring plan.
- A growing factor over time is a good sign, and a shrinking one is an early warning.
CHAOSS notes that maintainers usually track the factor at regular intervals, so look at two time windows and compare. Projects with several repositories may need all of them counted together.
Pair the number with a plan: if the single maintainer disappeared, would you fork, vendor or replace? For that side, see measuring project health with bus factor and commit velocity.
Quick check
Is bus factor the same as the number of maintainers?
No. It counts how many people produce half of the contributions. A project can list ten maintainers while one person writes most of the code.
Should I avoid every package with a factor of 1?
Not automatically. Weigh it against release activity, security policy and how easy the package is to replace.
Safeguard's SBOM and dependency scanning gives you the inventory of packages this analysis needs, and you can start with the free scan.
Sources
Last reviewed: 19 October 2026.
