Risk Metrics

Risk measures how likely something is to go wrong with a repo in the long term. The model calculates four risk metrics (concentration, complexity, security, and workload), mostly over the last 5 years, and combines them into one score by geometric mean.

Inputs

Source	Data
Git	Commit log (no merges), authors after mailmap, active contributors, lines of code
GitHub	Commit for the end-of-year snapshot, issues opened and closed per year
GitLab	Commit for the end-of-year snapshot, issues opened and closed per year
scc	Algorithm to calculate lines of code and total cyclomatic complexity
lizard	Algorithm to calculate the highest cyclomatic and cognitive complexity
OpenSSF	Scorecard: overall score (0–10) and 18 checks
OSV	Known vulnerabilities (CVEs) per package
deps.dev	Fallback Scorecard, OpenSSF Best Practices badge
OSS-Fuzz	Fuzz-testing enrollment (context only)

Concentration

Concentration shows how much a project depends on a few people. The model counts commits per author over the last 5 years (no merges, bots removed, identities merged).

Bus factor (BF): the smallest number of authors whose commits together reach 50% of all commits. Sort authors by commits, count down from the top until half is covered. A low bus factor means higher risk.
HHI (Herfindahl-Hirschman index): how unequal the commit shares are: $HHI = \sum_{i} {(100 \cdot s_{i})}^{2}$ , where sᵢ is author i’s share of commits. It runs from near 0 (many equal authors) to 10,000 (one author). A high HHI means higher risk.

The score is $Concentration = \sqrt{\frac{HHI}{BF}}$ . A one-person project (BF = 1, HHI = 10,000) gets the highest risk, 100, and any spread of commits across more people reduces it.

Complexity

Complexity shows how large and hard to review the code is, at a fixed end-of-year snapshot.

Lines of code: the size of the code (via scc).
Cyclomatic complexity: the number of paths through the most complex function (via lizard).

Each metric is turned into a percentile rank R (0–100) across all core projects. The score is $Complexity = \sqrt{R_{LOC} \cdot R_{cyclomatic}}$ , so big and complex code ranks worse than either one alone.

Security

Security shows how exposed a project is.

OpenSSF Scorecard: security practices of the repository. A low score means higher risk.
Known vulnerabilities: CVEs in the last 5 years. A project with no known CVEs gets a neutral middle value (50), because “none known” is not proof of safety.

The score is $Security = max (100 - R_{Scorecard}, S_{CVE})$ . R is the Scorecard percentile rank, inverted so a low score means high risk. S_CVE is the CVE score. The worse of the two counts, so either one alone can flag a project.

Workload

Workload shows the work that falls on each active contributor (people with a commit in the last 5 years).

Lines of code per active contributor
CVEs per active contributor
Net new issues per active contributor: issues opened minus issues closed

Each ratio is turned into a percentile rank R (0–100) across all core projects. The score is $Workload = \sqrt[3]{R_{LOC} \cdot R_{CVE} \cdot R_{issues}}$ . A project with no active contributors is scored as if it had one, and flagged as dormant.

Output

Each of the four dimensions gives a score from 0 to 100, where higher is riskier. risk_score is their geometric mean, so a project needs all four to get a score: $risk_score = \sqrt[4]{Concentration \cdot Complexity \cdot Security \cdot Workload}$ .

The result of this stage is risk_score (0–100) for each class A repo. Together with value_score, it sets the final score that ranks grant candidates: $score = \sqrt{value_score \cdot risk_score}$ .