The bus factor — the minimum number of key developers whose departure would leave a software project unable to proceed — is estimated from version-control history by algorithms whose thresholds and cutoffs were chosen without published justification and have never been calibrated or validated at scale. Lisan and Norris (2024) studied two such algorithms on five high-performance-computing GitHub projects: the CST algorithm of Cosentino et al., which scores developer knowledge from commit-based metrics and counts the union of primary and secondary developers above knowledge thresholds, and the blame-based RIG algorithm of Rigby et al., which simulates developer departures until most files are abandoned. They found that replacing commit counts with lines-of-code-change (LOCC) and cosine-difference (change-size-cos) metrics improves accuracy against maintainer judgments, while blame-based analysis fails to terminate on larger repositories and the algorithms' thresholds are unexplained. The open problem, posed in substance by that study's future work and elaborated here across metrics and project contexts: quantify how CST and RIG bus-factor estimates vary with their thresholds and cutoffs and recommend calibrated values; and validate bus-factor estimation in a data-driven way against large labeled corpora of maintainer-identified key developers, establishing whether it reflects actual maintenance capacity.

Background

A widely studied risk for open-source software (OSS) projects — most of whose contributors are volunteers — is the concentration of knowledge about the codebase in a few people. The bus factor (also called truck factor) is the minimum number of key developers whose sudden departure would leave a project unable or seriously impeded to proceed; a low value signals concentrated, fragile knowledge. Because interviewing teams does not scale, researchers in empirical software engineering and mining software repositories have proposed algorithms that estimate the bus factor automatically from version-control data such as Git commit histories.

Two algorithms anchor the source study. The CST algorithm of Cosentino, Cánovas Izquierdo, and Cabot scores each developer's knowledge of each file using commit-based metrics (for example, dividing the developer's commits on a file by the file's total commits), aggregates these scores to directory or project level, and defines the bus factor as the size of the union of primary developers (knowledge at least a threshold XX, set to 1/N1/N where NN is the number of developers who ever changed the artifact) and secondary developers (knowledge at least Y=X/2Y = X/2). The RIG algorithm of Rigby, Zhu, Donadelli, and Mockus, adapted from financial risk management, instead uses git blame — the version-control operation that attributes every line of a file to the developer who last changed it — to measure code ownership at line granularity; it repeatedly simulates the random departure of groups of gg developers and returns the smallest gg whose removal abandons at least 50% of files, where a file counts as abandoned when at least 90% of its lines belong to departed developers. A related line of algorithms, initiated by Avelino, Passos, Hora, and Valente, scores each developer's Degree of Authorship (DOA, a weighted count of file-level commits that grows with own commits and shrinks with others' commits) and removes top authors until fewer than half the files remain covered.

Lisan and Norris (2024) implemented CST and RIG and applied them to five long-lived high-performance-computing (HPC) projects on GitHub (PETSc, Spack, Hypre, Lammps, NWChem), replacing commit counts with two finer contribution metrics: LOCC (the lines of code a developer added or deleted per file) and change-size-cos (a cosine-similarity score of the textual difference of changed lines, which discounts renames and formatting churn). Validating against responses from the projects' principal developers (four of five projects answered), they found CST driven by LOCC and change-size-cos more accurate than commit-based CST and RIG. They also hit hard practical walls: their blame-based RIG implementation failed to terminate within 24 hours on all but the smallest project, and the original CST tool ran more than 48 hours without output on the two largest projects.

The surrounding literature has treated the resulting gaps in ways that leave the source study's questions unanswered. Ferreira, Valente, and Ferreira validated three truck-factor algorithms against a survey oracle of 35 OSS project teams, and their journal extension (Ferreira, Mombach, Valente, and Ferreira) confirmed that agreement between algorithms and team-elicited ground truth is imperfect; Hannebauer and Gruhn proved that exhaustive set-cover-style truck-factor formulations are NP-hard. Jabrayilzade, Evtikhiev, Tüzün, and Kovalenko built a multimodal estimator (commits, code reviews, and meeting attendance with a forgetting-curve decay) validated against internal surveys at one company. More recently, Piccolo, De Meo, Terracina, and Greco reformulated the bus factor as combinatorial optimization on bipartite people-task graphs, proved NP-hardness for redundancy, criticality, and robustness formulations, and proposed a normalized, threshold-free robustness measure with linear-time approximations; Piccolo additionally gave peeling-based approximation heuristics scaling to millions of graph nodes — but evaluated on synthetic power-law graphs, remarking only in passing that CST's thresholds XX and YY "can be sensitive" without quantifying this. Meanwhile, Cury and Avelino showed that DOA-based expertise models are measurably perturbed by generative-AI-produced code, and Wheeler has argued positionally that AI code generation invalidates authorship-based knowledge metrics as a class — sharpening the need to know how much these measurements actually reflect human understanding.

No prior work provides a systematic empirical account of how CST and RIG outputs depend on their algorithmic thresholds and cutoffs on real repositories, recommended threshold values per project context, or a large labeled corpus of maintainer-identified key developers against which these estimators — and the claimed advantage of LOCC and change-size-cos over commit counts — can be validated in a data-driven way.

Problem Statement

Determine whether bus-factor estimation from version-control data — specifically the CST algorithm (primary-developer knowledge threshold X=1/NX = 1/N, secondary threshold Y=X/2Y = X/2, over commit, LOCC, and change-size-cos metrics) and the blame-based RIG algorithm (line-abandonment threshold of 90%, file-abandonment threshold of 50%, Monte-Carlo sampling of departing developer groups) — can be made reliable and validated, by answering:

  1. Threshold sensitivity and calibration. How do the bus-factor values and the identified key-developer sets produced by CST and RIG vary with their threshold and cutoff choices, across the three data metrics and across project characteristics such as size, age, team size, and application domain? Which threshold values should be recommended for which project contexts, with explicit reasoning grounded in that sensitivity evidence?

  2. Data-driven validation. Can the correctness of bus-factor estimates be established at scale by data-driven means against large labeled corpora of maintainer-identified key developers, in place of the small maintainer-survey validations used so far? A resolution requires either constructing and evaluating such a data-driven validation at scale, or a rigorous argument that it cannot be done.

These components jointly serve one objective: establishing bus-factor analysis as a calibrated and validated measurement that reflects actual maintenance capacity and can support effort-allocation and knowledge-transfer decisions in open-source projects. Component 1 supplies the calibrated instruments, and component 2 tests the resulting measurements against maintainer reality.

References

  1. Aliza Lisan and Boyana Norris. Guiding Effort Allocation in Open-Source Software Projects Using Bus Factor Analysis. arXiv:2401.03303, 2024. DOI: 10.48550/arXiv.2401.03303. https://arxiv.org/abs/2401.03303
  2. Valerio Cosentino, Javier Luis Canovas Izquierdo, and Jordi Cabot. Assessing the bus factor of Git repositories. In 2015 IEEE 22nd International Conference on Software Analysis, Evolution, and Reengineering (SANER), 2015. DOI: 10.1109/SANER.2015.7081864. https://doi.org/10.1109/SANER.2015.7081864
  3. Peter C. Rigby, Yue Cai Zhu, Samuel M. Donadelli, and Audris Mockus. Quantifying and mitigating turnover-induced knowledge loss: Case studies of Chrome and a project at Avaya. In Proceedings of the 38th International Conference on Software Engineering (ICSE), 2016. DOI: 10.1145/2884781.2884851. https://doi.org/10.1145/2884781.2884851
  4. Guilherme Avelino, Leonardo Passos, Andre Hora, and Marco Tulio Valente. A novel approach for estimating Truck Factors. In 2016 IEEE 24th International Conference on Program Comprehension (ICPC), 2016. DOI: 10.1109/ICPC.2016.7503718. https://doi.org/10.1109/ICPC.2016.7503718
  5. Mivian Ferreira, Marco Tulio Valente, and Kecia Ferreira. A Comparison of Three Algorithms for Computing Truck Factors. In 2017 IEEE/ACM 25th International Conference on Program Comprehension (ICPC), 2017. DOI: 10.1109/ICPC.2017.35. https://doi.org/10.1109/ICPC.2017.35
  6. Mívian Ferreira, Thaís Mombach, Marco Tulio Valente, and Kecia Ferreira. Algorithms for estimating truck factors: a comparative study. Software Quality Journal, 2019. DOI: 10.1007/s11219-019-09457-2. https://doi.org/10.1007/s11219-019-09457-2
  7. Christoph Hannebauer and Volker Gruhn. Algorithmic Complexity of the Truck Factor Calculation. In Product-Focused Software Process Improvement (PROFES), LNCS, 2014. DOI: 10.1007/978-3-319-13835-0_9. https://doi.org/10.1007/978-3-319-13835-0_9
  8. Elgun Jabrayilzade, Mikhail Evtikhiev, Eray Tüzün, and Vladimir Kovalenko. Bus factor in practice. In Proceedings of the 44th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 2022. DOI: 10.1145/3510457.3513082. arXiv:2202.01523. https://arxiv.org/abs/2202.01523
  9. Sebastiano Antonio Piccolo. Fast and Accurate Heuristics for Bus-Factor Estimation. arXiv:2508.09828, 2025. DOI: 10.48550/arXiv.2508.09828. https://arxiv.org/abs/2508.09828
  10. Sebastiano A. Piccolo, Pasquale De Meo, Giorgio Terracina, and Gianluigi Greco. The theory and practice of computing the bus factor. Information Sciences, 2026. DOI: 10.1016/j.ins.2026.123353. arXiv:2603.07845. https://arxiv.org/abs/2603.07845
  11. Ahmed El Cheikh Ammar, Sukru Eraslan, and Yeliz Yesilada. Predicting the truck factor in a software repository using machine learning. Information and Software Technology, 2025. DOI: 10.1016/j.infsof.2025.107765. https://doi.org/10.1016/j.infsof.2025.107765
  12. Alexis Butler, Dan O'Keeffe, and Santanu Kumar Dash. Measuring Software Resilience Using Socially Aware Truck Factor Estimation. In 2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE), 2025. DOI: 10.1109/ASE63991.2025.00318. https://doi.org/10.1109/ASE63991.2025.00318
  13. Arghya Bhattacharya, Samba Narayana Duggirala, Aditya Ramdas, and Muthukumaran K. A Novel Framework to Estimate Truck Factor in Software Repositories Using Dynamic Knowledge Decay Model. In New Trends in Intelligent Software Methodologies, Tools and Techniques (SoMeT), Frontiers in Artificial Intelligence and Applications, 2025. DOI: 10.3233/FAIA250505. https://doi.org/10.3233/FAIA250505
  14. Olivier Nourry, Masanari Kondo, Shinobu Saito, Yukako Iimura, Naoyasu Ubayashi, and Yasutaka Kamei. Myth: The loss of core developers is a critical issue for OSS communities. arXiv:2412.00313, 2024. DOI: 10.48550/arXiv.2412.00313. https://arxiv.org/abs/2412.00313
  15. Otávio Cury and Guilherme Avelino. The Impact of Generative AI on Code Expertise Models: An Exploratory Study. arXiv:2507.08160, 2025. DOI: 10.48550/arXiv.2507.08160. https://arxiv.org/abs/2507.08160
  16. Brett Wheeler. The Substrate Collapse: AI Code Generation Invalidates Authorship-Based Knowledge Metrics. arXiv:2606.20882, 2026. DOI: 10.48550/arXiv.2606.20882. https://arxiv.org/abs/2606.20882