Value Metrics

Inputs

Source	Data
npm	Annual downloads per package, total ecosystem downloads per year, runtime dependencies of the latest version, package-to-repository links
PyPI	Annual downloads per package (mirror tools excluded), requires_dist runtime dependencies, project URLs
crates.io	Downloads per version, dependency edges between crates, repository links
Debian	Install counts (C/C++ download proxy), Depends and Pre-Depends edges, homepages
Homebrew	Install counts (C/C++ download proxy), runtime dependencies of each formula, homepages
GitHub	Repository validation (upstream reachable), canonical name and ID, mirror metadata
GitLab	Repository validation (project exists), project ID
Repology	Links Debian and Homebrew names to one C/C++ project
OpenSSF	Criticality Score: project age, recent activity, contributor and organization counts, commit and release cadence, issue activity, a dependents proxy
ecosyste.ms	Critical-infrastructure flag per package, package-to-repository links

Downloads

Value starts from registry downloads, which show how much a package is used. The model takes average annual downloads over the last 5 years and keeps the top packages that make up 95% of all downloads in each ecosystem.

C/C++ has no single package manager, so the model combines Debian and Homebrew, linked by Repology. It counts each project once (its most-installed variant) and merges Debian and Homebrew as a weighted sum of their average installs: 1.39 × Debian + 1 × Homebrew. A project is a top package when it is in the top 95% of either.

Downloads also weight the PageRank: a package that is downloaded more starts with more rank.

Dependencies

The model finds dependencies iteratively. It fetches the runtime dependencies of every top package, then the dependencies of those packages, and repeats until no new packages appear. All packages in that tree go into the PageRank graph, so a little-known library under a popular package can still rank high.

Then the model ranks every package with a download-weighted PageRank (α = 0.85). A package ranks high when many important packages depend on it. Having many dependencies of its own does not help.

Criticality

Criticality ranks projects inside the core but does not decide who is in the core. It uses two outside signals:

• OpenSSF Criticality Score (0–100): how critical a project is, from its age, recent activity, contributor and organization counts, commit and release cadence, issue activity, and dependents. GitHub only.
• ecosyste.ms critical flag: 100 if the package is on the ecosyste.ms critical-infrastructure list, 0 if not. It also covers GitLab, where the OpenSSF score is not available.

Output

Packages with their downloads and PageRank are grouped by their source repository.

The model checks that each repository is valid: GitHub and GitLab repositories through their APIs, other hosts with git ls-remote. Only GitHub and GitLab repositories go on to the next stages.

Packages are sorted by PageRank in each ecosystem. Their cumulative share sets the class:

Class	Cumulative PageRank	Meaning
A	0–75%	The core: critical infrastructure
B	75–95%	Important, widely depended on
C	95–100%	Long tail

Inside the core, value_score (0–100) sets the order. It is a weighted blend of four parts. A missing part does not lower the score; the other parts are weighted up.

Part	Weight	What it measures
openssf_crit	60%	OpenSSF Criticality Score (GitHub only)
eco_crit	20%	ecosyste.ms critical-infrastructure flag
top_eco_pct	10%	PageRank position in the repository’s strongest ecosystem
pr_score	10%	Dependency mass across ecosystems

The result is the list of class A repos, ranked by value_score. Only these go on to Risk and Eligibility.