Bus factor in open source

What bus factor means

"Bus factor" (also called "truck factor") is the minimum number of people on a project whose sudden departure would cause the project to stall. The phrase comes from the morbid thought experiment: "if this person got hit by a bus tomorrow, could the project continue?" Bus factor 1 means no. Bus factor 5 means yes, at least until four more people also get hit by buses.

The original framing was for corporate teams, but the term is now used most often in open source. In OSS, bus factor 1 is the default state, not the exception. A 2024 study by Harvard and the Linux Foundation analyzed the top 500 most-depended-upon open source packages and found a median bus factor of exactly 1 for the top 100.

The reason is structural: 60% of OSS maintainers are unpaid (Tidelift 2024), 44% report burnout (Sonar 2024), and most projects are started by a single person who keeps them going as long as they have time and energy. When that runs out, the project doesn't get a graceful handoff — it gets a frozen repository with a build-up of unanswered issues.

The 2026 data, in one table

The most useful 2026 numbers, in one place. All measurements use the CHAOSS definition (50%+ of commits in the last 12 months covered by N contributors):

Sources: JetBrains Bus Factor Explorer (March 2026), Harvard / Linux Foundation study of the top 500 OSS packages (2024). Numbers can change month-to-month as contributor patterns shift — treat these as a recent snapshot, not a permanent ranking.

Why bus factor 1 is a supply-chain risk

A bus factor of 1 isn't a maintainability problem — it's a supply-chain problem. The XZ Utils backdoor (CVE-2024-3094) was discovered in March 2024: a single burnt-out maintainer had been socially engineered over two years into accepting a co-maintainer who slipped a backdoor into a release used by every major Linux distribution. The malicious code was caught only because a Microsoft engineer noticed a 500ms latency anomaly. The fix was a multi-week scramble across Debian, Red Hat, and Arch maintainers. A bus-factor-1 project nearly became a global supply-chain compromise.

The 2026 Reptile.haus sustainability analysis puts a number on the risk: packages with a bus factor of 1 have a 36% annual chance of losing their only contributor. Not because of market conditions or restructuring, but because humans break under sustained, unpaid labour. Multiply that 36% across the 800+ transitive dependencies of a typical modern web app and you have an actuarial problem hiding in your lock file.

The 2025 ICSE paper Understanding the Response to Open-Source Abandonment found that 15% of widely-used npm packages became abandoned within a six-year observation window, and that the abandonment response rate (the share of abandoned packages that get a new maintainer) is low and getting lower. Once a bus-factor-1 project goes silent, the probability of revival is small.

How to calculate bus factor

Three approaches, in order of effort:

1. The 30-second check

git clone <repo> && cd <repo> && git shortlog -sn --all | head -10

If the top contributor has 90%+ of the commits, the bus factor is 1. If 3-5 people have meaningful commit history, the bus factor is 3-5. The shortlog is a quick proxy — it overstates bus factor (because a casual contributor can spike it) but is good enough for a triage check.

2. The CHAOSS-compliant calculation

The CHAOSS working group's definition: the minimum number of contributors whose combined commits in the last 12 months cover 50%+ of all commits. This normalizes for project size and activity. Tools that implement this:

• JetBrains Bus Factor Explorer — web app with treemap visualisation and turnover simulation
• yamikuronue/BusFactor — CLI tool, naive algorithm but fast
• SOM-Research/busfactor — academic-grade, IEEE SANER publication

3. The 2025 academic heuristics

A 2025 arXiv paper (2508.09828) introduced two new heuristics — Minimum Coverage and Maximum Coverage — that are 2-10× more accurate than the degree-based baseline on power-law graphs. The implementations are open source. The practical implication: if you're tracking bus factor for a portfolio of dependencies, the academic methods are worth the setup time.

What to do about it (two angles)

If you depend on a bus-factor-1 project

1. Sponsor the maintainer. Even $100/month changes the calculus. GitHub Sponsors, Open Collective, Polar, and Tidelift all route to the maintainer directly. Paid maintainers don't quit at the same rate.
2. Get your company to contribute back. One PR a quarter from your team builds bus factor 2+ on the projects you depend on. It's a 4-hour-per-quarter investment that pays back the first time the maintainer gets sick.
3. Adopt or co-maintain if the project is critical. Read the adopter guide for the playbook. Don't wait for it to break first.

If you maintain a bus-factor-1 project

1. Add at least one co-maintainer in your first 3 months. The person who files the most thoughtful PR is your first candidate. Ask them.
2. Document everything. Release process, security disclosures, incident response, domain/hosting, where the keys are. The handover doc is the artefact that prevents the project from dying when you do.
3. Treat "find my replacement" as a standing task. If you adopted the project expecting to maintain it forever, you'll burn out in 18 months. Adopt it expecting to steward it for 2-3 years and find your replacement before you stop. See the maintainer handoff guide.

Frequently asked questions

Related reading