Guide

How Companies Can Fund Open Source Sustainably

A practical guide for companies that want to fund the open source projects they depend on through sponsorships, collectives, maintainer programs, bounties, grants, and procurement.

Last reviewed: 2026-06-21 4 min read

Companies should fund open source the same way they manage other operational dependencies: identify what they depend on, decide what risk they want to reduce, and choose the funding route that matches the dependency. The best program usually combines direct sponsorship, project-level funding, procurement-friendly maintainer programs, and targeted work funding.

Start with your dependency map

A company cannot fund everything. Start by listing the open source projects that create the most value or risk.

Include:

Runtime dependencies.
Build and deployment tools.
Security-critical packages.
Developer productivity tools.
Infrastructure libraries.
Projects maintained by one person or a very small team.

Then ask which projects would create the most operational pain if they slowed down, broke, or became unmaintained.

Match the funding route to the problem

Company need	Funding route	Example platform type
Support a specific maintainer	Direct sponsorship	GitHub Sponsors
Support a project budget	Project-level funding	Open Collective
Reduce supply chain risk	Enterprise maintainer program	Tidelift, security initiatives
Fund a specific issue or feature	Bounty or contract	Algora, IssueHunt, direct contract
Improve ecosystem health	Foundation or grant support	OpenSSF, Sovereign Tech Agency, NLnet where relevant
Pay for support	Commercial support or consulting	Maintainer or vendor contract

Direct sponsorship

Direct sponsorship is the simplest option. Use it when your team depends on a maintainer and wants to support ongoing work without a procurement-heavy process.

Good sponsorship criteria:

The project is used in production.
The maintainer is active.
Your team has benefited from fixes, releases, or support.
The amount is meaningful but easy to approve.

A useful rule: if your company would pay more to replace the project than to sponsor it, sponsorship is reasonable.

Project-level funding

Use project-level funding when money should belong to the project rather than one person. Open Collective works well when a project needs transparent budgets, expense reimbursement, invoices, or fiscal hosting.

This is useful for projects with multiple maintainers, infrastructure costs, events, documentation, or contractor payments.

Procurement-friendly maintainer programs

Some companies cannot make donations easily. They can buy services more easily than they can sponsor individuals. In that case, look for procurement-friendly options such as Tidelift, paid support, security audits, consulting, or foundation programs.

This can be better for finance teams because the company receives a contract, invoice, and service description.

Funding specific work

Use bounties or direct contracts for specific work:

Fix this bug.
Complete this migration.
Improve Windows support.
Add documentation for an enterprise use case.
Run a security review.

Do not use bounties for vague maintenance. Continuous work needs continuous funding.

Internal policy template

Create a small open source funding policy:

We fund open source projects that are used in production, reduce engineering risk, or provide critical developer infrastructure.

Funding can take the form of direct sponsorship, project-level contributions, paid support, bounties, or foundation programs.

Teams may request funding by naming the dependency, business impact, maintainer activity, proposed amount, and preferred funding route.

Company funding mistakes

Treating open source funding as charity instead of dependency maintenance.
Waiting for a crisis before funding critical projects.
Sending small one-off donations without a repeatable policy.
Funding only visible projects and ignoring transitive dependencies.
Asking maintainers for enterprise support without paying for it.

FAQ

There is no universal amount. Start with the project’s importance, your dependency risk, and the cost of replacement. Small recurring sponsorships are better than no support, but critical dependencies deserve meaningful budget.

Should companies use GitHub Sponsors or Open Collective?

Use GitHub Sponsors for direct maintainer support. Use Open Collective when the project has shared finances, public budgets, or expenses.

Is open source funding a donation or procurement expense?

It can be either. If finance cannot approve donations, structure the spend as support, maintenance, security work, or a service contract where appropriate.

Should companies fund transitive dependencies?

Yes, when they are critical. Many supply chain risks sit below the obvious top-level dependency.

Need to match a dependency to a funding route? Try the Sustainability Finder.

Contents