Fund the dependencies your product cannot easily lose and whose maintainers cannot easily carry them alone. Rank your inventory by how critical each component is, how thin its maintainer base is, and how hard it is to replace. Then pay the top tier first, in cash, with no strings attached.
Start from facts, not favorites
Most funding decisions go to whatever project people have heard of. A better start is your own dependency inventory, which lists what you actually ship. See how to count the open source your company actually uses. Without it you will fund visible projects and miss the small library under your login flow.
Three questions per component
| Question | Why it matters | Where to look |
|---|---|---|
| How critical is it to us? | Failure or abandonment hurts revenue or security | Your architecture, reachability, how many services use it |
| How thin is the maintainer base? | One tired maintainer is a continuity risk | Contributor history, commit activity, bus factor |
| How hard is it to replace? | High replacement cost means more reason to keep it healthy | Engineering estimate of migration effort |
For the second question see how to calculate bus factor for an open source dependency.
A three tier method
- Tier 1: critical and fragile. Used in many services or in a sensitive path, few maintainers, costly to replace. These get regular payments and, if you can, engineering time.
- Tier 2: important but resilient. Used widely, healthy maintainer base or foundation backing. Fund through a foundation or a smaller recurring amount.
- Tier 3: commodity. Easy to swap, plenty of alternatives. No funding, just monitoring.
Review the tiers once a year. Components move up when a maintainer steps back and down when a foundation adopts the project.
What counts as funding
The Open Source Pledge, a group of companies that commit to paying maintainers, is specific about form. It focuses on cash payments to maintainers or foundations, with no strings attached, and says hiring developers or giving cloud credits are important but do not count toward its membership. It also excludes projects your company controls, projects that exclusively benefit your own ecosystem, and payments that bring the company more than minimal benefit such as a bit of logo placement. You do not have to join the Pledge, but its criteria are a useful test of whether a payment is a gift or a purchase.
Payment platforms vary, and the Pledge says only payments that fit its criteria are in scope regardless of platform. For the mechanics of one platform, see GitHub Sponsors for companies.
Money is not the only lever
- Send fixes upstream. See what upstream first means.
- Give maintainers a security contact inside your company.
- Fund a security audit if the project cannot afford one. See spending open source sponsorship money on security.
- Say thank you in public. It costs nothing and matters.
Who decides
Name an owner for the funding list, and set a budget line that is reviewed with the same cadence as other vendor spend. Without an owner, the list becomes a one-time gesture.
Where Safeguard fits
Safeguard's SBOM and dependency scanning gives you the inventory to rank, and reachability analysis shows which components your code actually exercises. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which components appear in many places, since those are your tier 1 candidates.
Quick check
Should we fund every dependency?
No. Fund by criticality and fragility, and monitor the rest.
Do cloud credits count as funding?
They can help a project, but the Open Source Pledge says only cash payments count toward its membership.
Sources
Last reviewed: 19 October 2026.
