Bus Factor & Knowledge Risk
- What Is a Bus Factor?
- How DOA-Based Analysis Works
- Risk Level Interpretation
- What Actions to Take
- Limitations
What Is a Bus Factor?
The bus factor is the minimum number of contributors who would need to leave a project before it stalls due to knowledge loss. A bus factor of 1 means a single departure could critically impact a repository.
In M&A due diligence, bus factor analysis reveals hidden concentration risks that financial audits miss. A company may have strong revenue, but if critical systems depend on one or two developers, the acquirer faces significant post-deal risk.
How DOA-Based Analysis Works
ContributorIQ uses Degree of Authorship (DOA) analysis, based on the Fritz et al. research model, to determine who truly "owns" each file in a codebase.
Unlike simple commit counting, DOA considers three factors:
- First Authorship (FA): Did this contributor create the file? Creators typically have deeper understanding.
- Deliveries (DL): How many times has this contributor modified the file? More modifications indicate ongoing knowledge.
- Acceptances (AC): How many changes have others made since this contributor's last edit? Knowledge decays when others modify code you haven't touched.
The formula produces a normalized score (0-1) for each contributor on each file. Contributors with a DOA score above 0.75 are considered file "authors," meaning people with sufficient knowledge to maintain that file independently.
The bus factor is then calculated by finding the minimum set of authors needed to cover more than 50% of all files in the repository.
Risk Level Interpretation
| Bus Factor | Risk Level | Meaning |
|---|---|---|
| 1 | Critical | A single departure could stall the project |
| 2 | High | Very thin coverage; losing one person severely impacts the other |
| 3-4 | Medium | Reasonable coverage but room for improvement |
| 5+ | Low | Knowledge is well-distributed across the team |
What Actions to Take
Critical Risk (Bus Factor = 1)
- Identify the sole author immediately
- Prioritize pair programming or code review sessions to transfer knowledge
- Document critical system architecture and decision history
- Consider whether this person is a flight risk (check lifecycle stage)
High Risk (Bus Factor = 2)
- Ensure both key contributors are not in the same team/location
- Begin cross-training a third contributor on core areas
- Review succession plans if either contributor is "winding down"
Medium Risk (Bus Factor = 3-4)
- Monitor for changes, since medium can slip to high if contributors depart
- Focus on maintaining knowledge distribution rather than concentrating it
Low Risk (Bus Factor = 5+)
- Knowledge is healthy; maintain through good onboarding practices
- Periodically re-assess to catch emerging concentration
Limitations
- Shallow clones: If repositories were cloned with limited history depth, DOA calculations may undercount older contributions.
- Commit-based approximation: DOA measures code changes, not verbal knowledge transfer, documentation reading, or architectural understanding.
- File granularity: A contributor may understand a file conceptually without having committed to it recently.
- Merge contributors: If contributor identities haven't been properly merged, the analysis may overcount unique contributors.
Bus factor analysis is one signal among many. Use it alongside lifecycle analysis, knowledge distribution matrices, and organizational context.