Open source funding: five models, honestly compared

The open source sustainability problem is not that the models do not exist. It is that projects pick a model that does not fit their shape, and then conclude that funding open source is impossible.

Five models. Each works. Each works for a specific kind of project.

1. donations and sponsorship#

Works for: developer-facing tools with a large individual user base and an identifiable maintainer.

Does not work for: libraries deep in a dependency tree, infrastructure nobody knows they use, anything without a personality attached.

The honest arithmetic: donation income correlates with visibility, not with importance. A well-marketed CLI tool with a charismatic maintainer will out-earn a critical cryptography library by a large multiple.

The corporate sponsorship version works better than individual donations and requires the maintainer to do sales, which most maintainers are bad at and hate.

2. foundation governance#

Works for: infrastructure that multiple large companies depend on and that none of them wants a competitor to control.

Does not work for: small projects. The overhead — governance, legal, trademark, process — is substantial, and a foundation with one project and no funded staff is just more paperwork.

The real value of a foundation is not money. It is neutrality: it makes a project safe for competitors to invest in together, which unlocks contribution that would not otherwise happen.

3. dual licensing#

Works for: libraries embedded in other products, where the copyleft obligation is genuinely inconvenient for commercial users.

Ship under a strong copyleft license, sell a commercial license to companies that cannot comply.

Does not work for: anything permissively licensed already (no leverage), anything not embedded (the obligation does not bite), or anything with a permissive competitor of similar quality.

Effective when it fits, and it produces a genuine tension: the license that makes the business work is the one that limits adoption.

4. open core#

Works for: products where enterprise features are genuinely separable from the core — SSO, audit logs, RBAC, compliance reporting, multi-tenancy.

Does not work for: libraries. There is no enterprise tier of a date-parsing library.

The failure mode is well documented: the line between core and commercial moves toward commercial over time, under revenue pressure, and the community that built your adoption watches features they use get moved behind the paywall.

If you do this, write down the line publicly, early, and honor it. "Anything that a single developer needs is open; anything that exists because you have a compliance department is commercial" is a defensible line. Moving it later costs more trust than the revenue is worth.

5. hosted service#

Works for: anything that is annoying to operate. Databases, search, queues, observability, CI.

Give away the software, sell the operation of it. This is the strongest model when it fits, because the value you sell — not having to run it — is real and continuous, and it does not require withholding anything.

The risk: a hyperscaler offers a managed version of your software, at scale, without contributing back. This has happened repeatedly and it is why the source- available licenses exist.

Those licenses solve the problem and cost you the open source designation, which costs you contributors, ecosystem inclusion, and some corporate adoption. It is a real trade with real costs on both sides, and the projects that made it mostly survived, which is the empirical answer to whether it works.

what actually kills projects#

Not the absence of a model. Three other things:

Solo maintainer burnout. One person, unpaid, receiving an unbounded stream of issues, feature requests, and entitled demands. Funding helps and does not fix it — the fix is more maintainers, which is a governance problem.

Success without support. A project that becomes critical infrastructure while its maintainer count stays at one. This is the most dangerous state and it is extremely common.

Corporate abandonment. A company open-sources a project, staffs it with employees, then reorganizes. The external community was never built because it was never needed. Now nobody knows the code.

what companies should do#

If your business depends on open source — and it does — the highest-leverage actions, in order:

1. Pay maintainers of your critical dependencies. Directly. Small amounts to many projects beat large amounts to a few.
2. Assign employee time to upstream contribution. More valuable than money and much rarer.
3. Do not send compliance questionnaires to volunteers. They owe you nothing and the license says so.
4. When you fix a bug in a vendored dependency, upstream it. The number of companies carrying private patches for bugs everyone has is enormous.

None of that requires a strategy document. It requires someone with budget deciding it matters, which is the actual bottleneck.