Open Source Risk Assessment Checklist

1 List your top 20 critical open source dependencies

These are the packages that would block your engineering org if they disappeared tomorrow. Start with what's in your production lock files.

Identified the top 20 critical dependencies (use npm ls, pip list, cargo tree, etc.)

Ranked them by impact (not by usage count — by blast radius)

Documented the rank-1 dependencies in a shared doc (Notion, README, etc.)

Identified the bus factor for each (run git shortlog -sn on the package)

Flagged any with bus factor = 1

Step 2 — Score each dependency on 5 dimensions

2 Score each top-20 dep on 5 dimensions

Per dep, score 1 (low) / 2 (medium) / 3 (high risk) on each dimension. Sum the scores. Anything ≥10 is critical.

Dimension	1 (low)	2 (med)	3 (high)
Bus factor	3+	2	1
Dormancy (last commit)	< 30d	30-180d	> 180d
Sponsorship status	Funded	Solo, active	Solo, no income
Explicit signals	None flagged	Maintenance mode	Deprecated / archived
Institutional backing	Foundation	Company	Pure solo

Scored all 20 dependencies

Identified the top 5 highest-scoring (most at-risk) deps

Shared the score sheet with the team

Step 3 — Sponsor the bus-factor-1 maintainers

3 Sponsor the high-risk maintainers

$100/month changes the calculus. Tidelift's 2024 data: paid maintainers don't quit at the same rate as unpaid ones. Even one $100/mo sponsorship is a signal.

Identified the top 3 bus-factor-1 maintainers

Opened sponsorship pages (GitHub Sponsors, Open Collective)

Got the budget approved (or escalation in progress)

Sent the first sponsorship this quarter

Step 4 — Make contributing back a team policy

4 Make contributing back a team policy

One PR a quarter per critical dependency builds bus factor 2+ on the projects you depend on. Start small — typo fixes count.

Documented the contributing-back policy (in the team handbook)

Each engineer has at least 1 critical dep assigned to them

First-quarter PRs reviewed and merged (or in flight)

Track quarterly: PRs per critical dep, growing contributors

Step 5 — Track risk quarterly

5 Make open source risk a quarterly metric

Most engineering orgs track vendor risk. Open source is the same kind of dependency. Treat it the same way.

Added open source risk to the quarterly engineering review

Bus factor + sponsorship + dormancy on the dashboard

Each high-risk dep has a documented adoption plan (BreakPoint list URL, fork URL, or "monitored")

Q1 review complete — top 5 actions assigned

Summary scorecard

After completing the 5 steps, fill this in:

Step 1: Top 20 critical deps documented and shared

Step 2: Score sheet complete; top 5 at-risk identified

Step 3: First sponsorship sent to at least 1 critical maintainer

Step 4: Contributing-back policy in the team handbook

Step 5: Open source risk on the quarterly review dashboard

Want a free audit of your actual org?

Paste your GitHub org, get a real report with your top 20 deps scored.