Funding an open source project when donations do not work

The open source funding conversation is dominated by a handful of maintainers with large followings and healthy sponsor pages, which makes the model look more available than it is. For most projects, donations convert at a fraction of a percent and correlate far more with the maintainer's public visibility than with how many people depend on the code.

If you maintain something widely used and quietly anonymous, the sponsor button is not going to fund it.

Here is the rest of the menu, with the constraint that actually governs it: a permissive licence means anyone can take what you give away. Every model below either works with that or quietly fights it.

Open core

Keep a core open, sell a proprietary layer around it — usually the things organisations need and individuals do not: single sign-on, audit logs, role management, support guarantees.

Works because the buyer is a company with a procurement process, and what they are buying is not features but someone to call.

The hazard is the line. Every feature decision now has a second question attached, and moving something from open to closed once is enough to lose the community's trust permanently. Draw the line at organisational needs, not at capability, and write it down publicly before you need it.

Dual licensing

Ship under a copyleft licence, sell a commercial licence to anyone who cannot comply with it.

Works for libraries that get embedded into proprietary products, where the copyleft obligation is genuinely inconvenient and paying is the cheaper path.

Requires that you own or have been assigned copyright on all of it, which means a contributor licence agreement, which reduces contributions. That is a real trade and not everyone should make it.

Hosted service

Sell the running of the thing rather than the thing.

Works whenever operating the software is meaningfully harder than using it — which is most infrastructure.

The hazard is that you are now an operations company. The skills, the on-call rota and the cost structure all differ from the ones that got the project here.

Support and training

Sell your time as the person who knows it best.

Works immediately, with no product work, which makes it the fastest thing to start. Does not scale. Revenue is linear in your hours and stops when you do.

Bandwidth sharing, for the projects that ship a binary

This one only applies if your project ships an application that end users install and run — a desktop tool, a media application, a utility — rather than a library other developers compile against.

Users opt in, and a capped share of the bandwidth their machine is not using gets relayed for public web data collection. It pays up to $0.50 per user per month, at per-country rates. A user counts for a day once their device has been sharing for 60 minutes in that day, each qualifying day is worth one day's share of the monthly rate, and the month is the sum of its days. Devices on hosting, datacenter or VPN IPs are not counted.

Three things make this awkward in open source specifically, and they are worth stating before the revenue.

Your users can read the code, and they will

This is the difference between shipping this in a proprietary app and shipping it in an open one. Every claim in the consent screen is checkable against the source, by an audience that is unusually motivated to check.

That is a genuine reason to be more careful, and also the reason it can work better here than anywhere else. A consent flow that survives being read by people who compile your project is a consent flow that will survive anything.

The build has to be honest about it

If your official binary includes something your source tree can be compiled without, say so loudly and in the README, not in a footnote. Distribution maintainers will find out either way, and finding out for themselves is the version that ends with your package being patched or dropped.

The workable arrangement is a build flag, off by default, documented, with the official builds stating clearly that it is on and why.

Some of your audience will object on principle

Not because it is harmful, but because a background network process in a free software project offends a real and defensible position. You will not argue anyone out of that, and trying is worse than accepting it.

The realistic framing: this funds the project, it is opt-in, it can be compiled out, and here is exactly what it does. Some people will still say no. That is a legitimate answer and the project survives it.

Which one to pick

Ask what your users cannot easily do themselves.

• If it is complying with a licence, dual licence.
• If it is running the thing, host it.
• If it is satisfying a compliance department, open core.
• If it is understanding the code, sell support.
• If your project is an application people install and none of the above fits, bandwidth sharing adds revenue without gating anything.

None of these is free. Every one of them changes something about how you work, and picking the one that changes the least about what your users receive is usually the right instinct.

The eight questions to ask any SDK vendor applies with extra force here, because your users will be asking them too. What each monetization model costs your users is the general version of the trade-off. Our ethics page is where we write down what we will not do.