git-archaeologist is an open-source CLI that flags single-owner and high-churn files in any git repository. For this report we ran it across 26 of the most widely used open-source projects — 438,904 files, hundreds of thousands of commits — looking for modules where a single contributor dominates the change history.
Every repository analyzed had at least one module with highly concentrated ownership — a single contributor accounting for the majority of commit history — across every team size in this dataset. Projects with 6,483 contributors. Projects with 5,358. Still had them. (Small or stable files trend single-owner by nature; the signal is in the count and criticality of such modules, not their mere existence.)
Bus factor measures how many contributors a project can lose before a given module becomes unmaintainable. A bus factor of 1 means a single person leaving effectively orphans that code. Important: this tool measures maintenance activity concentration from commit history — not who holds knowledge of the code. These are related but not the same thing.
When a critical module is effectively owned by one person, new contributors can't ramp up without that person's involvement. Reviews bottleneck. Knowledge doesn't transfer.
When that contributor leaves — changes job, loses interest, or becomes unavailable — maintenance stops or shifts entirely to whoever is willing to learn it from scratch.
The assumption is that large, popular projects are safe from this. This dataset suggests otherwise. Thousands of contributors do not appear to prevent ownership concentration in individual modules within this dataset.
Four findings emerge directly from the dataset — none require extrapolation.
Every project — from Rails (6,483 contributors) to Remix (29) — had at least one module where a single author owns more than 50% of the change history. No clear relationship between contributor count and BF-1 module count was observed in this dataset.
25 bus factor 1 modules with only 140 authors. Spring Boot's architecture is highly modular — 22,528 files across dozens of sub-modules, many authored and maintained by a small number of contributors. Raw data →
236 authors, only 1 bus factor 1 module — the healthiest ratio in the dataset by a significant margin. This shows the pattern is not inevitable — deliberate code ownership practices appear to produce different outcomes.
VSCode (3,050 contributors → 15 BF-1 modules), Kubernetes (5,358 → 9), Rails (6,483 → 7). Larger teams do not consistently produce lower bus factor counts in this dataset.
All 26 repositories sorted by bus factor 1 count descending. BF-1 = single author owns >50% of recorded changes in the analyzed window.
Highest BF-1 count in the dataset. One BF-1 module per ~900 files, across a project with massive downstream enterprise Java usage.
The only large project that comes close to breaking the pattern. Shows the outcome is not structural — it appears to respond to deliberate ownership practices.
The most-changed file in the entire dataset. 98 authors have touched it, yet its change frequency, recency, and high author count combine for the highest curse score of any file analyzed.
The project with the most contributors in the dataset still has 7 BF-1 modules, including the routing mapper — one of the most business-critical files in any Rails app.
The curse score combines change frequency, recency, author count, age decay, and acceleration. Config, documentation, generated files, and vendored code are excluded — these are real source files. The two highest scores in the dataset are shown below with full author and change counts; per-repo top files for all 26 projects are in the data table. Full formula in the Methodology section.
| File | Project | Authors | Changes | Curse Score (relative) |
|---|---|---|---|---|
src/vs/workbench/api/common/extHost.protocol.ts |
VSCode | 98 | 1,762 | 108,065 |
pkg/kubelet/kubelet.go |
Kubernetes | 434 | 1,817 | 107,471 |
Click any column header to sort. BF-1 = modules where one author owns >50% of changes. BF-2 = modules requiring at most two authors. † = analyzed within tool's default commit window.
| Project ↕ | Commits ↕ | Files ↕ | Authors ↕ | BF-1 ↕ | BF-2 ↕ | Top Cursed File ↕ | Curse Score (rel.) ↕ |
|---|
† Commits and authors reflect the analysis window, not full repo lifetime. See Limitations.
Analysis was run with git-archaeologist (git-arch analyze <repo> --json) against local clones in June 2026; this report reflects the current release, v1.32.5. Commit SHAs at time of analysis are published in the research/ folder.
A module is BF-1 when a single contributor accounts for more than 50% of all non-merge commits touching that file. This measures historical maintenance activity concentration — not who understands the code, who has reviewed it, or who could maintain it if needed. A stable, rarely-changed module will appear concentrated even if it is widely understood. The metric is objective and reproducible; what it cannot capture is tacit knowledge.
Implemented in src/analyzers/curseScorer.ts:
Exponential decay means old chaos that has stabilized scores lower. Acceleration means recently worsening files rank higher than files with similar totals that have levelled off.
How to read a score: for VSCode's extHost.protocol.ts, the two largest inputs are its 1,762 changes and 98 authors (log₂(99) ≈ 6.6); these combine with the churn, age-decay, and acceleration terms to produce the dataset's highest score. The scores are relative ranking values, not absolute quantities — compare them to each other, not in isolation.
All non-merge commits. Merge commits are excluded to avoid double-counting changes from feature branches.
Yes. Commits from accounts matching bot patterns — dependabot, renovate, github-actions, and similar — are excluded from authorship calculations.
Via git log --follow. A file's full authorship history is preserved across renames throughout the repository's lifetime.
Generated files, config, docs, lock files, vendored code, and build scripts. Only source files are ranked. The filter is best-effort — edge cases may exist.
Correlation only. This data shows ownership concentration co-exists with large contributor bases. It does not explain why, nor predict failures.
Rust (168k files — exceeded memory limits during analysis). All 26 other repositories completed successfully.
Documenting limitations is not a hedge — it is the difference between a credible analysis and a marketing document.
This tool measures historical ownership concentration from git history. It does not directly measure who understands a codebase, who reviewed changes, or who could maintain a module today. Results should be interpreted as maintenance-risk signals rather than ground truth about organizational knowledge.
Several repos show round commit counts (1,000; 2,000) — these reflect the tool's analysis window, not full repository history. React has ~20,000 real commits; TensorFlow ~170,000. BF-1 findings are valid within the window. Full history re-runs are planned for v2.0.
This is the most important conceptual limitation. A module with one active committer may be widely understood across the team. A module with many committers may be understood by none of them. This metric identifies where maintenance activity is concentrated — not who holds knowledge. A stable, well-understood module that hasn't needed changes will appear concentrated even if dozens of engineers know it cold.
All 26 repos were analyzed at specific commit SHAs (published in the research/ folder). Results will differ after significant contributor activity. Concentration can improve — Vite proves this.
One person using two email addresses counts as two authors. Co-authored commits are attributed to the first listed author. Both factors could slightly undercount real unique contributors.
Generated, vendored, config, docs, and lock files are excluded from cursed file rankings and BF-1 counts where possible. The filter is best-effort — some edge cases may have slipped through.
BF-1 modules co-exist with large contributor bases across every project analyzed. This data does not explain why, nor predict failures. A BF-1 module is a risk indicator, not a guarantee of problems.
On round commit numbers: repos showing exactly 1,000 or 2,000 commits were analyzed within git-archaeologist's default window. The full repository has more history. Bus factor and curse score findings are valid within the analyzed window — but commits and authors figures reflect the window, not project lifetime. Rows marked † in the data table.
The tool emits per-repository JSON for each analysis (cursed files array, bus factor breakdown, file statistics, and the commit SHA at time of analysis). The summary results and the reproduction harness are published in the research/ folder; run the command below to regenerate the JSON for any repository.
Repository commit SHAs and the summary results are published in the research/ folder. Run the command below to regenerate per-repo JSON locally.
An open-source CLI for analyzing code ownership and complexity patterns in git repositories. This report benchmarks the tool against 26 major OSS projects.