For many Red Hat is the symbol of paid open source code support. Being a pioneer and the first one to create a real market for it, they still enjoy a dominating standing among Open Source (OS) users in need of more stable OS options. Today the value derived from the subscriptions they are selling also includes guaranteed updates and patches, as well as certifications. But support still remains a substantial part of the total offering. Nowdays larger organizational level OS projects also offer paid support options to their users, primarily through consultancy partners. At the same time, smaller OS projects are usually still ignoring the support part, primarily due to lack of resources or suited tools to actually offer it. But it shouldn't have to be that way. They don’t have to fully outsource or ignore this funding potential.
Today's revenue models
In a blogpost by Karl Hughes, he is listing six ways to generate revenue as an OS project, where support is one of the categories.
Donations
Hosted version of the product
Paid support or courses
Open Core - Paid extra features
Dual Licensing
Selling other products
The revenue models listed are not exhaustive, and do also come with several nuances and creative modifications individually. We won’t discuss all these in this text. Looking closer at these revenue streams however, the lowest hanging fruits when it comes to monetizing your project are probably donations and paid support. The reason: With the right tool, you can basically start offering both within 30 minutes of setup. The rest of the revenue options require a bit more preparation, maintenance and work. And what’s nice, none of them mutually excludes each other.
The Open Source contribution to the world
A 2024 Harvard study titled “The Value of Open Source Software”, estimates that the total demand-side value (replacement value for each company that uses open source software) is nothing less than 8,8 trillion USD annually. Or in more relative terms, if all software only was commercially available, companies would have needed to spend approximately 3,5 times more on software than they currently do. Despite these numbers, still only 14% of contributors see any form of payment for their contributions, significantly fewer a payment they can actually live off. The number is higher for maintainers, standing at 40%. But for contributors as a whole, the stats are disappointing.
Red Hat led the way
From its early days, Red Hat was built around the concept of providing paid support for open source software, primarily Linux. In the 90s, OS software and especially Linux, lacked the formal support, testing and assurance that in particular large enterprises were looking for. Red Hat’s innovation was to realize that the value was in the services around the free software. In addition to packaging the freely available Linux kernel and other open source tools into a stable distribution (Red Hat Linux), they also sold subscriptions for support, documentation, bug fixes and security patches. Today support is one feature of the complete product they are delivering, where Red Hat Enterprise Linux (RHEL) is the core of their subscription-based model. Now many larger open source projects are adopting “the Red Hat revenue model” for their own software, such as MongoDB, Elastic or HashiCorp, building enterprise friendly packages of the free open sourced core within these same organizations.
Still, the 30 billion+ professional open source services market is dominated by large actors still controlling more than 70% of the revenue generated. The number is from 2023, so AI may have affected the share in one or the other direction, but the 16,5% expected annual growth in the coming years, shows that businesses are heavily reliant on paid expertise to adopt and manage complex open source solutions, with or without AI in the mix.
Why don’t most open source projects offer paid support?
Surely not every OS project should provide, or want to provide, support for their codebase. Projects are different, and their motivation to give support may depend on size, type of codebase, funding situation, number of contributors, user types, and so on. However, we believe there are some explanations that are worthy of highlighting, on why paid support isn’t more widespread.
The culture
Despite a more liberal and less stringent OS culture today, then we had a few years back, the notion and expectation of open source always being free, still lingers. And not only that, there are a great share of people who remain believers in the fact that all aspects of open source should be free, ranging from the obvious license to the less obvious support. This expectation is a misunderstanding of the definition and what open source was created to be, but somehow keep a foothold in the community.
Lack of need and motivation
Another part of the answer on why projects don’t offer paid support, would simply be that many maintainers don’t have to. They have well paid day jobs, and see their project or contributions solely as a hobby where the motivation is found within learning and doing good for others. This is a privileged position enjoyed by a few, whereas others put in countless hours, and are scrambling to make ends meet. The less fortunate ones, economic wise, may also be motivated by the same things as those well off, but could benefit hugely from some extra funding to cover basic living expenses.
The capacity and focus gap
Most large community-driven OS projects are developed by volunteers who want, and may also be paid by third-parties, to write code. Not to offer 24/7 technical support to users. Writing, reviewing and maintaining the code are usually more than enough to keep their hands full, leaving support outsourced or deprioritized. This may feel logical, as free support is not a part of any open source license. The result is a huge commercial ecosystem built around outsourced support, actors - small and large ones - that specializes in offering support, consulting, migration services, and health checks for a vast range of open source software. Sometimes these actors are more suited in providing help, but oftentimes the contributors would have been a better match.
Few suited tools
We also believe some of the answer resides within the fact that there are few to none support tools created purely for open source, and with payments in mind. This is not so strange when you think about it. The largest consumers of support and the areas with the highest willingness to pay, reside within: 1. Online stores, and 2. Commercial software, and preferably enterprise level commercial software. Both with various levels of AI. The former group is customer service without code support, with inquiries about product information, product returns, or shipments. The latter group is support solutions where the purpose is to support existing customers who need help with software or code bases they have purchased access to. This type of support is normally always free, as a transaction has already taken place, and is handled by in-house employees. Hence, lacking features that would suit an OS project.
Building a tool that serves OS
We don’t think we can magically change people’s motivation or willingness to provide support to their users, but we think we can lower the barrier and make it easier to engage people in their community for this task.
With a wish to contribute in making open source more sustainable, we created Githelp. Githelp isn’t a golden answer to solve OS projects’ funding problems, but it is a risk-free way of adding an extra source of potential funding to the mix, in the form of paid support to your users. With Githelp you can easily engage your community and validate helpers, while seamlessly introduce paid support to your users.
We believe that by lowering the barrier to offer paid support, more projects will regard it as an option, either with the purpose of making it easier for potential users to choose your project, or as an additional source of funding for your project and your contributors.
If you are curious and want to learn more, feel free to reach out to us or sign up for free.
Share Article