I run inspect.software, a public database tracking open-source repository health. It indexes over 60,000 repositories across npm, Go, PyPI, Packagist, crates.io, RubyGems, Maven, and others—totaling roughly 460 billion monthly downloads.
A few of the overall numbers surprised me.
Maintainer concentration
- 74% of repositories depend on a single maintainer for the majority of their commits.
- 3,279 of those have over a million monthly downloads.
- Distribution: 1 maintainer → 43,523 · 2 → 9,334 · 3–5 → 5,002 · 6+ → 913
- Organization-owned repos have a median score of 67; personal accounts sit at 53.
Security practices are where things drop off
Percentage of repositories that include:
- README 94% · License 91% · Automated tests 85% · CI 81%
- Linter config 41% · Docs directory 39% · Contributing guide 37%
- Security policy 19%
Average OpenSSF Scorecard metrics across the dataset (0–10 scale):
- CII-Best-Practices 0.1 · Fuzzing 0.6 · Branch-Protection 1.3
- SAST 1.5 · Pinned-Dependencies 1.7 · Token-Permissions 1.8 · Code-Review 2.2
- License 9.0 · Dangerous-Workflow 9.7
Concentration of usage
The top 1% of packages account for 71% of the total download volume. Median direct dependencies sit at 3, with a median resolved total of 27.
The result I did not expect
Median health score by download tier:
- under 10K/month → 59
- 10K–1M → 67
- 1M–100M → 75
- 100M+ → 54
The most-downloaded tier actually scores worse than the tier just below it. Looking at what's in that bucket explains why: ansi-regex (2.0B/month, score of 48), wrap-ansi (1.7B, 51), emoji-regex (1.8B, 51), and supports-color (2.0B, 57). These are tiny, stable, and essentially finished npm utilities that half the ecosystem relies on. They have no recent commits, no docs directory, and a single maintainer.
This feels like partly a real signal and partly a flaw in my scoring model. A utility that hasn't seen an update in three years because it's done looks identical to a project that's been abandoned. I don't have a clean fix for this yet, and I'd rather just admit that than pretend the data means something it doesn't.
Methodology and caveats
- The bus factor is pulled from GitHub's contributors API, which uses sampling (bots are excluded). Note that "majority of commits by one person" isn't exactly the same as "one maintainer"—a project can still have a healthy review process alongside one highly prolific committer.
- The methodology is versioned (currently 2.10.0) and published in full, including the weighting.
- The scoring code itself isn't open source yet. That's a valid criticism, and I'm currently working on it.
Data: inspect.software/insights — you can find per-ecosystem breakdowns there as well.
Happy to answer any questions about the approach, and I'm genuinely interested in hearing where you think my weights might be off.
