We encourage people who redistribute free software to charge as much as they wish or can.

https://www.gnu.org/philosophy/selling.en.html

In Chapter 1 we talked about one of the core challenges around FOSS monetization: open source licenses allow anyone to freely distribute copies of it. If a person starts charging money for it, without any additional benefit (e.g. enterprise support), somebody else will come along and redistribute it for free.

This is why selling enterprise support has been a successful model for many companies (e.g. RedHat). I want to emphasize there’s nothing wrong with selling enterprise support. But consider this:

1. Large companies that buy such offerings tend to buy from market leaders. If you’re just starting out, chances are, you’re not a market leader. So it might take years before you appear on large companies’ radar.
2. Enterprise support does not scale well. You will need to hire more people as the demand for the software increases.
3. For some, dealing with large companies might just be boring.

What about releasing some parts or modules of your project as proprietary? This open core model is employed by several successful companies (e.g. Redis Labs). It works. But we’re not talking about open source anymore (or any chance to build an open community).

How about offering different licenses? For example, use the code under AGPL for free, or pay for a less strict Apache2 license (e.g. The QT Company). It works. But again, this will appeal mostly to large companies and it might take years to get there. Also, good luck receiving contributions and make everyone sign Contributor License Agreements.

You could find a sponsor such as government entities, universities or companies. There are ample opportunities for grants in this area. The issue is, you might now be at the mercy of your sponsor and your features priority list will be affected (and not always for the best).

Donations / crowdfunding are very difficult to setup correctly, require a vast user base, conversion rates (the number of people that donate relative to the number of downloads) are low, and can struggle to sustain a project’s budget in full (or to the maximum of its potential).

It should be clear, there’s compromises with each strategy above and most of these work successfully only after a project has reached widespread adoption. It’s a common chicken-and-egg problem for open source. How can a project succeed in establishing itself, if funding opportunities to establish itself are provided only after a project is established?

The way out of this cycle is primarily achieved via:

1. A large sponsor jump-starting the project
2. Contributors providing labor for free until the project matures

It’s an unfortunate state of affairs. #1 is extremely limiting, and #2 is simply… unfair?

But #2 can be improved. And the recipe for doing that is extremely simple.

Let’s acknowledge a few facts:

1. You can and should charge for Free and Open Source Software. People scoff at this sometimes because it deviates from the mainstream. Yet, the mainstream has led us here, a world where open source sustainability is still a problem to be solved. So let’s keep an open mind toward this thought, as absurd or “heretical” as it might sound
2. Free software licenses allow people to copy, edit and redistribute the software
3. Most such licenses do not provide the freedom to infringe on trademarks

It follows that if I sell a copy of my FOSS called ABC, and some person comes along and decides to redistribute the software for free, they are free to do so, so long as they are not infringing on my ABC trademark. They can call it XYZ, and it might be the same code as ABC, but it’s not the original ABC. Brands have intrinsic value and are a reason alone somebody will pay for a genuine, original copy, rather than a copycat. In the U.S. filing a trademark is exceptionally cheap and fairly easy (just read all the instructions carefully). You don’t have to worry about forks, because you can own the brand behind the original software.

So there you have it, a simple way to raise funds for your project today: sell the compiled binaries to end users. This respects the philosophy of FOSS and generates a steady income stream.

1. Create a store with FastSpring or Paddle. They will handle tax compliance, software delivery, payments and a bunch of other tasks you probably do not want to handle yourself.
2. Create a product that includes your project’s binaries.
3. Create an action to send an e-mail with a link to download the binaries when a purchase is made.
4. No need for license checks. Let people copy and install your software wherever they want. Just don’t let them redistribute it openly over the internet under your trademark. Make that policy clear

How much should you charge? That’s up to you. Charge $1 if you’re worried about affordability. But charge something. Your users will thank you for the opportunity to contribute financially to the project and they will think more highly of it. Make it clear that you are not selling dedicated/enterprise support.

Admittedly, this strategy might work better for a subset of FOSS projects, such as frontend applications (the top of the software stack) aimed at end users. Libraries or software packages lower on the stack might need to get creative.

In the next chapter, titled “Trickle Down Sustainability”, I explain how a future in which most frontend FOSS projects decide to monetize by selling binaries could lead to a wonderful and sustainable funding stream for all FOSS projects alike, and solve the infrastructure problem:

I will publish the next chapter once I receive at least 3 e-mails about this first one. Tell me about your FOSS project, whether you liked or disliked this chapter, or anything.