How to Monetize Open-source Projects

Monetization of open-source projects is a critical issue. It is a conundrum waiting for a solution: On the one hand, open-source projects underpin many services and products we use in our daily lives, so we need them. On the other hand, the maintenance crews looking after those projects are severely understaffed and underfinanced. Something's gotta give—either open-source will play a smaller role in our lives (which is unlikely) in the future, or we'll find ways for open-source projects to sustain themselves. Working toward the latter makes more sense, considering how much we have tied up in open-source.

People have been looking for ways to make open-source projects more sustainable for decades. The methods used to achieve this end evolved over time, giving us a complete range from monetary donations to more advanced models that require legal and technical infrastructure. Let's take a look at the top five most popular monetization models for open-source projects:

Donations

Donations were the first step in the monetization of open-source projects. This model is the most straightforward and easy-to-implement way to provide financial support for an open-source project. It involves no cognitive load for the project team—just opening an account on Patreon, GitHub Sponsors, or Open Collective will do.

However, donations are unpredictable. An open-source project must be quite popular if it is to be sustained on donations. Even then, the most ardent users of open-source software may turn out to be reluctant to give back when it comes to donating money to a project. Therefore, donations can't be a sound basis for planning the future of a project.

With so much depending on the success of open-source projects nowadays, these projects cannot be beholden to the goodwill of the public. Companies will not pay for the value they can get for free. Therefore, the long-term survival of open-source projects rests on giving companies an incentive to support projects financially. That's why monetization efforts moved on from donations to other models that are better suited to generate a sustainable revenue stream.

Paid technical support

Users of open-source projects tend to have a lot of questions, ranging from simple "what should I do?" type questions to major compatibility issues. Already the most knowledgeable people on their respective projects, maintainers are the most suitable people to deal with such questions. Although not scalable if it is just a few coding enthusiasts maintaining a project, paid technical support can help sustain it.

Red Hat's success has illustrated how paid technical support for open-source projects can be a viable business model. The company was founded in the 1990s and went public in 1999. Red Hat Linux, the company's open-source Linux distribution, was split into two in 2003: Fedora Linux, the open-source, free-of-charge Linux distribution for non-enterprise users, and the subscription-based Red Hat Enterprise Linux for enterprise users. It is this latter product that has defined Red Hat's business model, providing a proven model for monetizing technical support in open-source projects. For a subscription fee, Red Hat provides enterprises with a pre-built version of Linux optimized for mission-critical installations and continuous support and updates. This Linux version affords Red Hat customers a more stable version with a robust support scheme that takes care of niggles and problems in a more professional way.

Red Hat surpassed $1 billion in revenue in 2012, becoming the first open-source technology company to do so, and it came to be relied on by more than 90 percent of Fortune 500 companies. The company was acquired by IBM in 2019 for $34 billion, which is a testament to the success of its business model.

Dual-licensing

This model involves offering the code under two licenses, one being open-source and the other commercial. The open-source license tends to be a copyleft license that comes with the obligation to publish any derivative work under the same license. Some companies using open-source software find this prohibitively restrictive for their respective businesses. The same code published under a permissive license appeals to such companies as it lets them use it in proprietary applications.

Qt, the cross-platform software for creating GUIs, offers its product under a dual license. The non-commercial version suitable for academic work, hobby projects, and projects without external distribution is available under GPL and GPL 3.0 licenses. Users planning to use the software to redistribute it on their own terms can buy the commercial license and gain access to technical support.

Is dual-licensing really open-source? There are criticisms that the commercial versions of dual licenses hurt the open-source ethos. Putting an open-source project under the monopoly of a profit-seeking company is unacceptable to some purists. However, some companies are forced to adopt dual-licensing as a result of the increasing competition from cloud service providers that enjoy an existing relationship with customers and access to open source. Thanks to these two factors, cloud service providers can offer impressive competing products. To counter that, dual-license vendors look for surgical ways to stop their code from being used by rivaling products while keeping a portion of the project strictly open-source to generate leads and attract customers. In the absence of a better alternative, this is a matter of choosing the lesser of two evils over the death of open-source.

Open-core

This model involves providing people with a "core" version of the code for free while keeping certain components, features, and functionality as closed-source, most of the time accessible through subscription. The add-ons offered in the paid version tend to generate high added value for industry professionals and enterprises and thus are worth the investment. As part of this strategy, contributors to a particular open-source project can talk to companies, understand their needs, and develop and ship on-demand features that will immediately plug holes for them.

PrimeFaces is one of those products that has leveraged the open-core model to create a viable business. While the PrimeFaces source code is hosted at GitHub and downloadable free of charge under an MIT license, users can buy templates to achieve significant productivity gains. Another example is Tailwind UI, which successfully applied the same formula, differentiating between the needs of enterprise and non-enterprise users. The company makes $2 million a year from selling add-ons to enterprises without completely abandoning its open-source character.

Open-core has been dubbed "not-so-open-source," just like dual-licensing was. Critics claim that cordoning part of a project off and making that portion only available to paid users practically goes against everything open-source stands for. It causes the fracturing of the open-source domain, they say. Additionally, it is claimed to erode all the standard benefits like the "community profit," i.e., the cumulative publicly-available knowledge created as a result of individual contributions that we expect to derive from open-source projects.

Open-source PaaS (Platform-as-a-Service)

The last iteration in the quest to monetize open-source projects is PaaS. PaaS is a cloud-based development and deployment environment in which customers get to use the resources offered by a cloud service provider on a subscription basis. This model provides users with an out-of-the-box solution that even SMBs and startups lacking the resources can take advantage of, relieving entrepreneurs of the need to invest in expensive hardware like on-premise servers. Thanks to the PaaS model, they can focus on their ideas or projects instead of worrying about infrastructure and maintenance.

Take Kafka, for example. You can download it from GitHub and pick the most suitable configuration for your use case from among the available options, which definitely would take some self-education. And all this for a message broker. The other option would be to subscribe to the PaaS solution, which would be optimized for you and save you the hassle of setting up and maintaining the system. PaaS is an outstanding value proposition for people looking to use network-based services and leverage sophisticated functions without getting their hands dirty. For the vendor, it sets the stage for a viable business as it creates recurring revenue and scalability.

In the PaaS model, the open-source portion of a project works as a lead-generating funnel. Once the project becomes a product, the non-PaaS version basically serves as the freemium model, helping acquaint users with the product. Users willing to access more advanced features and enjoy professional maintenance are incentivized to upgrade to the PaaS version.

The downside is that going back to the non-PaaS version may not always be possible—these extra features can result in lock-in, making a return to the non-PaaS version difficult once the project turns into a serious business. On the vendor side, the open-source code poses a risk as another company can build a rival PaaS product on top of it.

Final thoughts

The monetization of open-source projects requires much thought and advance planning, just like choosing the right open-source license does. However, there is no perfect solution in sight. Models in agreement with the open-source ideals can't offer reliable financial support. Those that can do so turn part of the project into proprietary code and are criticized for destroying the open-source ethos.

In a world that runs on open-source software, open-source projects must have the resources to cope with security challenges. A more strategic and forward-looking approach, one orchestrated by governments and open-source organizations, can reconcile conflicting purposes and ensure that open-source projects remain viable without having to sell their souls. Actually, it might be the only way out of this puzzle.