A New Funding Model for Open Source
Open source has a funding problem, but the solution does not have to be closing the code.
I've been thinking a lot about how to build software that can both respect user freedom and sustain the people building it. This is especially relevant for web3 software because if we take the term seriously, the whole point is not tokens, speculation, or financial games. The point is freedom software. Users should be able to inspect what the software does, run it themselves, modify it, fork it, keep their data, and continue using the system even if the original creator disappear.
This is why copyleft licenses, like GPL, are so important. They protect the user from the software slowly turning into someone else's property. If you receive the code, you can study it, modify it, and redistribute it. This is an extremely strong guarantee, and it is exactly the kind of guarantee we should want for software that claims to be web3.
However, there is an obvious problem. The stronger the user's freedom is, the harder it becomes to capture value in the traditional software business sense. If the code is available to everyone, and anyone can fork it, how is the creator supposed to fund continued development? The usual answers are consulting, donations, grants, hosted SaaS, venture capital, or eventually closing some critical part of the system. None of these are fully satisfying. Consulting does not really scale. Donations are unreliable. Grants are temporary. SaaS often recreates the same centralized dependency the open source project was meant to escape. Venture capital introduces embedded growth obligations, which tend to slowly corrupt the original mission of the project.
So the question is: can we create an open source business model that keeps the software free as in freedom, while still making it rational for users to fund the project? I think the answer is yes.
Free software, paid coordination
A key distinction we can make is between the code and the official path. The code can be GPLv3. Anyone can run it, modify it, and redistribute it under the terms of the GPL. Nothing about that needs to change. But the official path around the code can still be paid. This includes things like hosted infrastructure, official client behavior, update channels, support, indexing services, servers, documentation, and whatever other public infrastructure makes the project useful in practice. Note that this is not a contradiction. GPL protects software freedom. It does not require maintainers to operate infrastructure for free.
The way to make this precise is with an entitlement. An entitlement is not the legal license to use the software. The GPL already gives you that. Instead, an entitlement is a record that says you are part of the official service path. For example, an entitlement could give you access to:
- the official hosted backend
- official client builds
- official server builds
- support
- updates
- service quotas
- an accepted membership set used by third-party services
In a normal SaaS product this would just be a row in a private database. In a web3 product it can be an onchain record. Maybe that record is technically an NFT, but it should not be thought of as a collectible or speculative asset. It is more like a subscription receipt.
Ideally normal users should not even need to know this is happening. They should be able to pay with a credit card or invoice (if they want to), and the entitlement can be handled in the background. The onchain part matters because it makes the entitlement set public, verifiable, and usable by independent software.
The obvious objection
You might object: the software is GPL, anyone can remove the entitlement check.
Yes, exactly!
If the entire business model depends on users not being able to remove one if statement, then the business model is not compatible with free software. We should not try to pretend otherwise. The interesting question is not whether a fork can remove the check. Of course it can. The interesting question is whether removing the check gives users a better equilibrium.
This is where game theory becomes useful. The official project is not only distributing code. It is coordinating an ecosystem around the code. Users pay because the official path is easier, more trustworthy, better maintained, and more useful than the fork path. At a high level the condition is something like:
value of official path > value of fork path
Or more concretely:
official clients + hosted services + updates + support + legitimacy
>
patched fork + self-maintenance + weaker distribution + lower trust
A fork can copy the code. It cannot automatically copy the service network, brand, update channel, app-store distribution, documentation, community trust, or accepted entitlement set. This means the entitlement check is not really DRM. DRM tries to make exit impossible. This model makes exit legal and possible, but tries to make the official path the best place to be.
The entitlement set
The most important object in this model is not the individual entitlement token (e.g. subscription). It is the set of all active entitlements. Once a project has a meaningful number of paying users, this set becomes a coordination point. Services can decide to accept users in the official entitlement set. Clients can use it as the default funding boundary. Operators can use it to decide who gets access to scarce resources. In privacy preserving systems, users can even prove they are in the set without revealing which exact entitlement they control.
The statement becomes something like:
I am a currently paying member of the accepted set,
but I do not need to reveal which member.
This is useful for spam prevention, quota enforcement, and funding public infrastructure without turning every interaction into a normal account-based SaaS login.
It also changes the forking dynamic. A fork can remove the payment check, but then it has to answer some hard questions. Does it accept everyone for free? Then how does it handle spam, abuse, and infrastructure cost? Does it create its own paid set? Then it has recreated the same model and now has to convince users that its set is more legitimate than the original one.
The fork can also accept both sets:
official entitlement set OR fork entitlement set
This is probably the most realistic strategy for a serious fork. But even then, the fork has not escaped the need for governance, funding, and legitimacy. It has only created a competing institution. This is the core asymmetry:
forking code is easy, forking coordination is hard.
Self-hosting and free riding
There is another norm in open source that I think needs to be revisited. We often assume that hosted users should pay, but self-hosters should not. This made sense when the main cost was server load. If someone self-hosted, they were no longer using your server, so why should they pay?
But modern applications are not just servers. They are clients, browser builds, sync protocols, indexers, gateway lists, package repositories, documentation, compatibility work, and security updates. Self-hosters benefit from all of this. In many cases they are among the most serious users of the software.
So a better norm might be:
serious users fund the project, whether hosted or self-hosted
This does not mean self-hosting should be made hostile. Quite the opposite. The official project should support self-hosting as a first-class use case. Maybe even give a discount to self-hosting users. The difference is that the official self-hosted path can still participate in the entitlement system.
If someone really wants to remove the check, the GPL gives them that freedom. But they should understand that they are leaving the official path. They may lose automatic updates, compatibility guarantees, support, service acceptance, and membership in the main entitlement set. That seems like a fair bargain.
Why put this onchain?
A reasonable person might ask why any of this needs a blockchain. If the entitlement is just a subscription, why not store it in Stripe or Postgres? For a normal SaaS product, that is probably fine. But for freedom software, the point is that the coordination layer should not be fully trapped inside one company's database.
An onchain entitlement set can be read by anyone. Independent services can verify it. Forks can choose to accept it. Clients can check it without trusting a proprietary API. Users can see the rules of the system. Other operators can build infrastructure around the same set. This is similar to why ENS names, token ownership, and onchain registries are useful in the first place. They create a shared state layer that independent software can coordinate around.
Of course, this does not mean every part of the application should be onchain. That would be terrible. The onchain part should be minimal. The entitlement set is one of the few things that actually benefits from being public and verifiable.
How this fails
There are many ways to ruin this model.
The first is to describe the entitlement as a license to use the GPL software. That is wrong. The license is GPL. The entitlement is for the official path.
A second is to make the entitlement speculative. If users feel like they are buying into a token game, the whole thing becomes corrupted. This type of behavior has already caused immense harm in the cryptocurrency ecosystem. The entitlement should be boring. It should expire. It should look like a subscription, not an investment.
A third is to make payment feel like rent extraction. If the price is too high, or the maintainers are not transparent about what is being funded, users will coordinate around a fork. This is good. The possibility of exit is what keeps the official project honest.
A fourth is to attack lawful GPL modification. Users are allowed to fork the code. That is not a bug in the model. It is the foundation of the model.
A fifth is to make the official path annoying. If wallet UX, token management, or payment friction leaks into the normal user experience, people will reasonably hate it. The crypto should mostly disappear into the infrastructure.
The correct posture is something like:
- keep the price low enough that bypassing it feels petty
- make the official path much easier than the fork path
- make self-hosting work well
- be honest about GPL rights
- avoid token speculation
- make the funding purpose obvious
- keep the entitlement set as the main coordination point
Simple Page as an example
I've built a concrete example around this model. Simple Page is a tool for publishing websites on ENS and IPFS. The code is GPLv3, and the whole architecture is meant to give the user strong exit rights. The website is controlled by the user's ENS name, the content is addressed by cryptographic hashes, and the project is designed so that the user's site can keep existing even if the original app and infrastructure disappear.
This is exactly the kind of software that should be free as in freedom. Users should not lose control of their website because one company changes direction, shuts down, or starts acting maliciously. At the same time, Simple Page still has real costs. Someone needs to run servers, index Ethereum, seed IPFS content, maintain the editor, ship updates, handle abuse, and keep the hosted service reliable. The fact that the code is GPL does not make these costs disappear. So the subscription should not be understood as a license to use the software. The license is GPLv3. The subscription is an entitlement to the official Simple Page service path.
Someone could fork Simple Page and remove any entitlement checks. That is allowed. But then they need to run their own node, maintain their own editor build, create a tool for users to migrate to the forked editor, keep up with upstream changes, help users when publishing fails, and convince people that their hosted service is trustworthy. They can do that, and they should be allowed to, but that is a much harder problem than deleting a payment check.
This is the model in miniature: free code, credible exit, paid official coordination.
Open source for profit
There is a bad version of open source for profit where a company uses openness as a growth strategy, waits until enough users depend on the software, and then closes the important parts. We have seen this pattern many times. It is understandable, but it is also depressing.
The better version is to admit that the code itself should not be the scarce thing. The scarce thing is coordination. The scarce thing is reliable infrastructure. The scarce thing is trust that someone will keep maintaining the software. The scarce thing is the accepted set that services build around.
GPL is useful here because it prevents the project from relying on coercion. Users always have the walkaway option. They can take the code and leave. The project has to keep earning its position as the official path. This creates a much healthier game than either unpaid maintainer martyrdom or fake-open SaaS.
The bargain is simple:
You are free to leave.
If you want the official commons to keep existing, help fund it.
This is not free as in "free beer". It is free as in freedom, with a funding institution attached.
That might be exactly what open source has been missing.