For all the successes of open source, developers are painfully aware of where the model starts to break down. What happens when the de facto lead developer gets tired of doing all the work, or when different groups start to squabble and the project splinters? Say a bug appears but no one can be bothered to fix it. Maybe the core coders decide they just want to eat. The idea of open source transformed software development, making it cheaper, faster, more interactive, and often more secure and better engineered. But all these years later, it still doesn’t reliably pay the bills.

Money can’t fix all our problems, but it does solve some. What happens if we throw more cash at fixing what’s wrong with open source? If the open source model can get everyone working together to write beautiful code, why can’t it also organize us to raise money to fund more development?

Here are eight open source funding models being tried today. Some are rather new, others are updated versions of the models that sprung up with the first open source licenses. All try to do a better job of connecting creators with the funds they need to continue their work. None of these models is perfect, but if they can help at least a few developers fix a few bugs, then they’re a victory.

Crypto tokens

While cryptocurrencies like Bitcoin or Ethereum dominate the news, a number of others are using similar approaches and sometimes even the same open source software to create their own digital coin of the realm. One of the most popular schemes for these currencies is crypto tokens, a digital reimagining of the tokens used at amusement parks, arcades or laundry centers.

The BAT token, for example, is required to pay for advertising with the Brave browser. Filecoin (FIL) pays for backup storage in the Filecoin distributed file network. Gitcoin is used as part of a grants program with the Allo protocol, which supports many decentralized finance applications.

In some cases, the token is similar to a license for commercial software. You must purchase a token if you want the software to run. While a good coder might be able to rewrite the gatekeeping part of the open source code, the average user won’t have the time or the skill for that. It will just be easier to pay a small amount to purchase the internal token, and help keep the project going.

Some currency designers have grander plans for creating an entire ecosystem. The tokens just mediate the production and consumption of the software. Sandbox (SAND) and Decentraland (MANA) are two examples of tokens that manage resources like land or avatars in some corner of the expanding metaverse.

These tools are evolving alongside the burgeoning world of cryptocurrencies and NFTs, much of which is also built on open source code.

Drips

Imagine writing one check each month and having the amount magically shared between all the different software projects that you use. The Drips network follows in the footsteps of traditional systems like United Way which makes it easier for people to donate to a variety of charities in one step.

The network wants to do more than target the first and most visible level of open source projects. Each maintainer can specify that a fraction should be shared with the open source code that it used itself. This can be nested deeply. So if project A is built using B and C while C was built using D and E, any donations for A will flow through to the other four.

The developers decided to use the Ethereum blockchain for the transactions, a choice that brings transparency to the project. Anyone who chooses to start supporting a project can audit the currencies flowing through the public blockchain to see who gets how much. It’s flexible and as open as the code it supports.

Cloud-era licenses

Many of the original open source licenses were written for a world where everyone had a computer on their desk, or possibly in the server room down the hall. They encouraged sharing by forcing people to include the code when they were “distributing” the software.

That style of license stopped working so well when the cloud grew into dominance. As a lawyer at one of the big tech companies told me, “We don’t distribute the code so we don’t need to obey the GPL.” They built plenty of their own internal versions and never shared them.

The newest licenses, like the Affero General Public License for Cloud Services (AGPL-CS) or the Server Side Public License are designed to compel participation, even in the era of the cloud. Some companies like Elastic Search are designing their own licenses that do much the same thing.

In these examples, simply connecting the software up to a website counts as distribution. If a company uses the software, it should contribute in some way. These cloud-savvy licenses make it much harder for a person or company to make a fortune without sharing their code with the world.

The stronger licenses still serve the marketing needs. Developers can download and experiment as much as they want. They can contribute and feel a sense of shared ownership over the code. They don’t need to worry about the costs rising dramatically, features being cut, or any of the other hassles from vendor lock-in.

At the same time, they have an incentive to buy commercial licenses that can support continued development. The users that are getting real value from the product have an incentive to fund continued centralized development.

Not so open licenses

Richard Stallman famously said, “Free as in speech, not as in beer.” Now, some developers are creating licenses that don’t offer either senses of freedom—but they’re still delivering just enough of the kind of openness that satisfies their users’ curiosity.

One version is the “free tier” that offers enough access to test new ideas and maybe run a small, personal website while still charging for more substantial use. Developers encounter no impediment when they’re just experimenting, but if they want to start something serious, they need to pay.

Another example is the license that lets users read but not distribute. One developer told me that he routinely lets paying customers get full access to the code for audits or experimentation, but he does not release it into the open. The customers get to see what they want, but they can’t undercut the company or give away the software for free.

These licenses deliver some of what made open source popular without sacrificing the ability to compel payment.

Quadratic funding

Some developers prefer to support projects with a broad appeal. Quadratic funding is designed with a feedback loop that rewards many smaller gifts more than a few big ones. In other words, it rewards projects that are supported by the most number of people. The approach is often embraced by large donors who want to tap into the wisdom of crowdfunding to guide their gifts. Instead of using a strictly linear matching program, they use a quadratic function that is keyed to the number of donors. Some more extreme versions may choose even more extreme functions.

Code bounties

One of the original ideas of open source was for users to post their request and then announce a reward or a bounty for the first programming team to deliver the code. The process has since grown more organized. Now sites like huntr, buidlbox, and Bountysource are just a few examples of sites that make it easier for developers with spare time to find users who want to pay for new code. Some companies like Google also offer their own bounty programs directly.

Fellowships or jobs

The most common solution is for teams to hire open source developers and assign them to spend at least part of their time working on open source code. Developers get a steady income and the company gets the first-hand knowledge of the code and some ability to steer development.

This process has grown more formalized. Some companies are structuring the work as fellowships and making specific grants, sometimes with a fixed length of time and sometimes with an open-ended commitment. Some use this for projects that they desperately need to support and others make gifts just to support the community.

Give ’em cash

Grandparents have always known that a bit of cash slipped into the birthday card is the best gift of all. The open source world continues to find simple ways to make it easier to donate directly to the people doing the work. It’s not uncommon to see explicit notices and requests for support when installing or updating software. Many of the Linux distributions, for example, make a clear request when people download the binaries.

Some companies have programs that organize their support and donations. These programs are sometimes called “FOSS funds” or grants. Many of the larger tech corporations have realized it’s short-sighted to constantly take from the open source world without giving something back. Examples include programs by Google, Bloomberg, Microsoft, and the Linux Foundation.

Today, gifts like these are much easier for tech companies to understand. In the past, the bean counters were happy to do nothing and draft off the hard work of others. Now, software developers and their managers realize that it’s useful to be a supporting partner with the communities that are building the code. They realize that there’s no such thing as a free lunch, and a few good grants go a long way to sustaining the software that forms the foundation of their enterprise.