Options for Monetizing Your Open Source Project
Open source is everywhere. It is almost unheard of for a developer to start a software project and not consider using open source components in it. In fact, 90% of software projects developed today rely on open source components for, well, pretty much anything. All developers use these incredible pieces of software, freely available online, but rarely think about the developers behind them. Open source developers spend countless hours of their spare time, coding, debugging and documenting, only to get paid exactly $0 for their talent and hard work.
Why Don’t All Developers Monetize Their Code?
Open source developers are obviously not in it for the money. There are easier ways making a living than giving away great code for free. They most likely started their project out of curiosity, interest or to address a problem or need that they encountered. Most open source developers don’t even consider monetizing their projects. That is usually because they don’t really know where to start, but also because of some common myths:
- Monetization is “anti-open source.”
- I have to “close” my code to monetize it.
- Monetization is complicated. I have to start a company, hire lawyers, handle billing, etc.
- Why should anyone pay me? My code’s already free on GitHub.
These misconceptions are as common as they are wrong.
The Monetization Spectrum
Monetization can be viewed as a bell curve with two extremes: Donations on one end, and full commercialization on the other. The Y-axis is the number of projects that can benefit from those monetization methods.
On one end, there are donations, or sponsorships. Developers ask the good people that use their project, to donate money as they see fit, usually via Open Collective or Github Sponsors, so that they can continue maintaining their project. While donations are a noble notion, only a handful of open source projects actually accumulate enough ongoing donations to be considered a significant source of revenue. These are usually very large projects that have got the attention of major companies, who decided to give back to the team behind the project. The average open source project just gets the occasional donation here and there, and the reason for that — is the value (or the lack thereof) provided to the person or company making the donation. There’s no value exchange, just an act of good faith.
On the other side of the monetization spectrum, is the full commercialization of a project. That usually means a project is large enough and mature enough to warrant setting up a company around it, that offers enterprise versions, professional services and paid support tiers. Many great companies started just like that. Think Red Hat, or Redis labs, who took open source projects and turned them into billion-dollar companies. Forming a company, hiring staff and raising capital are all major commitments most open source developers are not ready for. And rightfully so. Most open source projects are great, but will never be big enough to be a Fortune 500 company. That doesn’t mean they can’t make a lot of money, though, even while keeping their project in the same scope as it is today.
Value Is Always a Good Business Model
The two extremes of the curve work well for just a handful of projects (and developers). Like all bell curves, the “meat” is in the middle. The middle represents a different approach, that is not as loose as donations, but not as intense as full commercialization. Using a platform like xs:code, a developer can generate revenue with their project by providing real value, but they do not have to commit to incorporating as a company. With xs:code, the code that the creator offers is free (free of charge AND free as in freedom), but they offer another value proposition on top of that free code. That value proposition can be one or more of three models: services, premium code or dual licensing. By offering paid features and services with their free code, developers provide users the ability to enjoy the additional value that is not available for free. It also shows that the project has someone committed behind it, and that the project is actively maintained. A paid offering can be a subscription or a one-time purchase. It is totally up to the project creator to decide how and how much to charge for each offering. Since xs:code handles all billing/payments/payout/storefront etc., the creator enjoys the freedom of not worrying about the business side. They can focus on creating value for users, which leads to revenue that can be spent on making their project better.
Choosing a Monetization Model
Choosing to monetize an open source project is a challenging decision in itself. However, once that choice is made, there is still another hurdle to overcome: deciding what is the best approach to monetize the project. Different projects might benefit from different models, and not all models will work for all developers — but almost all open source projects can be monetized. It’s just a matter of selecting the right model.
Additional Services – Offer Time and Expertise to Users
Developers who use open source projects (namely, everyone) often find themselves in need of help. Sometimes it is a code issue that is wreaking havoc in production and needs to be solved fast. Sometimes it is getting open source code to play nice with a company’s codebase. Sometimes people just need to ask a few questions instead of spending hours looking for an answer on their own. In the end, the developer (or maintainer) behind an open source project is best equipped to help with all of the above — and more. By making themselves available for paid services, developers create a great way to help their user base, generate revenue AND show people that using their project is safe to use, since there is actually someone available to help if the need arises. On xs:code, the developer can offer ad-hoc services on an hourly basis, such as bug fixing, consulting or even writing custom features for clients who need them. The developer sets the price, the time and how they will provide the service (for example, only on weekdays, 6 p.m. – 9 p.m. GMT). Users should be asked to contact the developer or maintainer before they buy a service. The in-app chat inside xs:code will email them when someone has pinged them, and this enables you to have even more granular control over what jobs to take, for how much and when.
Licensing – Offer Another License to Paying Users
While open source licenses can sometimes seem intimidating, they are actually powerful tools that developers can use to regulate what users can and cannot do with their code. Using paid licensing is an extremely popular monetization option, and it is easier to use than one might think.
A monetization model called “dual licensing” allows developers to offer two identical copies of their code. Each copy has a different license. The free version has one license, and the paid version has a different license. By assigning a restrictive license (such as a GPL license) to the free version, and a permissive license (such as the MIT license) to the paid version, the developer can incentivize users who need to use the code in a commercial setting to pay for it.
Restrictive licenses place restrictions that commercial companies may not be able to afford. But they are great for community use and for keeping code open source. Companies that need to use a specific repository can purchase access to an MIT licensed version and can then use the code freely, without worrying about restrictions posed by the free, more restrictive license.
A good recommendation is offering dual licensing as a subscription. On xs:code, for example, a subscription gives users access to a git repository with a permissive license, that’s locked unless a subscription is active. A valid question we often get, is why would anyone pay if they are “giving away” their code with an MIT license, which can then be distributed freely. While that is true, it is only true for the CURRENT version of the code. A license is only valid for the version that the user downloaded. If users want to access the latest version and enjoy future updates, they will need to keep their subscription active. That should also incentivize developers to keep developing and maintaining their project, to keep their users happy and paying.
While the process of using dual-licensing will require developers to re-license their code and keep two separate repositories, xs:code has made it pretty easy to get started with a “dual-licensing wizard” that will get them through the process of setting up dual-licensing within a few minutes.
Premium Code – Offer a Paid Version of Your Code
Many software companies use a concept called “open-core” to monetize their open source software. The idea is simple — They offer a “basic” or “core” version of their project for free while offering additional features, functionality or more frequent updates to paying clients. This means they will keep two sets of code (free and paid), and grant access to the paid version as a subscription. On xs:code, this is done by keeping a paid version on a private repository, and granting access only to users who purchase a subscription.
It is up to the developer to decide what features to include in the paid version, but as long as the paid features provide value to users — people will pay. Keep in mind that the free version has to provide value on its own, as not all users will convert to paying customers. This is the part where some might say that this approach means that the paid subset of code is not truly open source. While that is somewhat true, as long as a free version is kept, the developer is entirely entitled to offer some paid features.
Comparing the Models
| Services | Licensing | Premium Code | |
| Why yes | Flexible
Easy to get started Only 1 repository is needed |
No availability needed
No need to keep two versions of code Code remains 100% open source |
No availability needed |
| Why not | Requires availability | Requires relicensing | Requires keeping two repositories
Paid repository is non-open source |
| Works best for | Anyone! | Components
(not stand-alone projects) |
Where extra features provide value |
| Scalability | Low – Get paid for work done only | High – Code once, sell many | High – Code once, sell many |
| Revenue Potential | Medium | Very high | High |
Let’s Go
Different options can be mixed-and-matched. For example, a premium version can be offered that includes support hours. Or multiple separate options, like a paid license or support hours. It is totally up to the developer and what they are willing to do to monetize. It is important to note that value is the best business model. As long as the project and services provide value to users — they will pay for it.
With the right monetization model and the right platform, anyone can monetize their project, while keeping it entirely open source and free.
Good luck!
Feature image via Pixabay.