“I'll have this sandwich. Is it okay that I pay with some of my 10 k Github stars?”. Credit: Midjourney
Throughout the last decade, it has emerged a sense of depressive mutual understanding, that making open source software (OSS) means struggling to make ends meet. The reason for this may not be strange. Many OSS projects are started out of passion by a solo-developer, where puzzling out a business model and capitalisation-focused master vision, naturally doesn't reside at the top of the person’s mind. But as success grows, the lack of a minimal attention to business models in the early days, often comes to haunt them.
On Reddit, HackerNews, StackOverflow and various blogs, one can read about how open source founders with “overnight” success are desperately trying to scramble together a source of income, while their hobby-project’s required attention to maintenance, support and feature requests, almost turns into a burden. Setting up “Buy me a coffee” or similar donation services may for many be a good place to start, but primarily basing your life existence on the goodness of your users, has for most successful projects and active contributors turned out to be less viable in the long run. The result is slower growth and deprioritized projects, letting the world miss out on great code.
Screenshot from Reddit-thread.
In light of interest for the topic, and a project me and my partner are working on, we have over the last year been talking to a long list of OSS founders and gotten the worrying funding frustrations from forum threads confirmed. Some of the developers we have been speaking to, are actually thinking about closing down community-loved projects with tens of thousands of users, due to lack of apparent monetization options. And to be clear, they are not trying to get rich. They just need to pay their bills, have food on the table, and a place to live. With 99% of new software relying on open source components, many are building the “atoms” of commercial code, laying the foundation for profitable and successful closed source actors, whereas themselves are left empty-handed. As many know, this has been going on for quite a while, and is definitely not creating a healthy climate for open source.
OSS makes the rich richer
In the seminal essay by Eric Raymond — The cathedral and the bazaar — it is argued that software should be developed as a bazaar, where everyone can see, modify, and enhance the code transparently. This bottom-up approach suggests that the more widely available the source code is for public testing, scrutiny, and experimentation, the more rapidly all forms of bugs will be discovered. The reasoning is logical and widely applied, however, the bazaar model is in its nature inherently in conflict with the business model aspects by being open, letting commercial actors take advantage of the philosophy.
The Cathedral and The Bazaar. Credit: Midjourney.
In an ideal world, where commercial actors get the code for free, they can maintain margins at a lower cost level, while delivering their proprietary solutions to the people at a discounted price point, or as the copyleft approach says, at the same price point as open source; zero. Albeit the idea is beautiful, the reality is that most commercial actors are primarily trying to maximize their profit as long as they can, leaving the OSS projects as the naive good-hearted subsidizer of commercial companies and their shareholders, hence further increasing their valuations and power, relative to the open source community. Most multi-billion dollar technology companies such as Amazon and Microsoft, free-ride on the OSS community’s R&D-efforts, to various extents. Letting them hire less developers and use free code repackaged in their own proprietary products, like Mapbox in Azure, or Amazon and Elastic. This culture naturally forces OSS projects to change their licensing guidelines and start taking paid for certain elements associated with their services.
In the current climate, all prospects indicate that open source will continue to be a favorite building block within closed source software in the coming years. 65% of businesses that use OSS say they expect to increase their usage in the next year, while the largest tech companies also continue to rely heavily on OS code, resulting in an increased willingness to contribute with commits, sponsoring of primary contributors, or in some cases just straight out hire them. Hooray for that! However, in basic economic theory this suggests one thing; Where there is strong demand, there is usually room for raising prices. Larger enterprises will still benefit tremendously from open source, despite slightly raising the bar in terms of payments, and maybe also creating additional value for them along the way.
How to move some of the profit from commercial actors back to the OSS projects
While there are numerous examples of commercial actors of all sizes relying on OSS products, open source teams ranging from solo- to foundation level in size struggle to match their support, maintenance and development needs with available resources. Even contributors on large widely popular projects such as Rust alarmingly share how they are experiencing a burnout problem among their members. Reality is that 99% of projects don’t have a FAANG-type of financier pouring money into whatever they are doing, or a team happily devoting most of their awake time in exchange of happy-face emojis and thumbs-ups, meaning they have to finance the project through other sources.
Screenshot from Hacker News-thread.
So how do they find a business model that suits their project? Well, first of all, open source is by its very nature not a business model. Yes, some speculate in starting out as open source, in order to reap marketing benefits and speed up growth, but as the growth materializes, the need for support, maintenance, issue-solving and development also increases. One would expect that products loved by its users would have no problem in finding sources of income. However, monetizing and building business models around OSS can be really hard.
In a blogpost by Karl L Hughes, he is listing six ways to generate revenue as an OSS project.
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. What kind of revenue models to go for further depends on a range of factors such as type of project, available resources, administrative capacity, size, and user-/customer groups. And for all those projects relying fully on donations, Hughes continues to make a good point: If you've ever asked your boss if you can start paying for some of the free, open source software you use at work, you know how tough this can be to sell. As most of the users of OS software are not the same as those who benefit from it (the employer), donations become increasingly hard to orchestrate in a logical way.
“So CFO, I was thinking. Wouldn't it be nice of us to donate some money to the OSS projects we are using”. Credit: Midjourney.
In the following I will propose some elements it may be valuable to think about, mainly with regards to the six mentioned business models and how one potentially can get creative with them.
Make it easy to get started and use the code
Content rich and well structured documentation is usually a great foundation to have in any project, but it doesn't necessarily generate any revenue unless you put a price tag on it. Support, maintenance and courses on the other hand, cover many of the same purposes as documentation, but are in most cases easier to charge your users for with regards to acceptance. In that case, projects should consider to find structures which easily facilitate for support, maintenance and courses, so they can benefit from the continued usage of their software. Support and maintenance make up a great share of the revenue for many commercial software companies, where probably the majority would agree that charging users for support is not in conflict with the open source philosophy. Many OSS vendors already make most of their revenue from support and service, including help setting things up, configuring the code for their customers' specific needs, and troubleshooting any problems.
The commercial companies’ perceived value of this business model is probably a more challenging aspect to address for a sole project, and something the community as a whole should educate on. Commercial users must learn and understand that it can be beneficial and good for business to rely on support and development of certain work packages or issues from the projects themselves. Especially in the early days of a company’s life. It should also be more available and convenient to do so for the companies, not fully leaning on Discord help channels or extensive consultancy contracts. Besides, it can be a viable way for OSS projects to bridge the gap towards something more widely applied. There are numerous examples of projects trying to do this, with one being Ghost.org, a complete open source project that offers managed hosting and support at a reasonable price. A simple way to separate the DIYers from anyone who wants the convenience, peace of mind or just wants to support the project itself.
Be pragmatic about the receiver of funds
Credit: Midjourney
Funding the project or funding the contributors of the project, are for most small projects two sides of the same coin, as long as it is distributed fairly. Through support, payments could be directly transferred to qualified and validated contributors, which help them have some income, in order to devote more time to development and other maintenance tasks on the project. In reality it all boils down to whether a contributor can find time, and ideally live off their contributions. In this context support is great, as it offers a fair distribution of income, as those who actually contributed are those who also will be compensated. By nature, a convenient way to compensate and engage your community, as opposed to only receiving donations at a project level. There are also pitfalls here, as you don't want to shift all efforts toward paid activities. One way to tackle this could be to link support tickets to the person's commits and development contributions. The more you commit, the more paid support you are qualified for taking on. Of course, making it completely fair is challenging, as it may be hard to measure the extent of a commit in an efficient way.
Sort out the charity culture
Without having an incentive to provide support, the willingness and ability to find time and motivation becomes limited on the supply side. This again, can affect the adoption rate of OSS code, as users who get stuck may migrate to other options if available. Or just skip or modify features in their own products, if it requires code that is not easily applied.
Time among team members appears to be an issue in most projects. An article, On the abandonment and survival of open source projects: An empirical investigation, listed “lack of time” as the main barrier (26%) faced by new developers joining an OSS project. And at the other end, friendly and active owners/members were listed as the main characteristic (41%) that helped new developers when joining a project. Here it is pertinent to assume that it is easier to be welcoming towards new contributors if you actually have time. Interestingly enough the same study shows that larger projects are those who usually die out, probably due to the fact that they are not posing an interesting enough challenge for people offering their time for free, being feature-complete and requiring more mundane maintenance tasks. This indicates the importance of compensating contributors to a larger extent, when the tasks grow more routine-based and bug-focused. Especially the most routine-based tasks, which in many contexts would be user support.
Few works for free doing routine-based manufacturing. Credit: Midjourney.
On the demand side people have come to believe that open source is a charity, not only when it comes to using the code, but also when it comes to receiving support on how to use the code. The lack of willingness to pay for even support, among many users, results in less software being released as open source, and instead distributed as cloud-based commercial SaaS. If there were monetary incentives to give support, our research (not surprisingly) shows more people would be interested in giving support, which again free up time for the core-team to focus on new features rather than support. Jan Kammerath says it well in his essay:
The vast majority of private individuals, small and medium-size businesses that use Open Source never donate a single penny while producing cost and consuming time of Open Source projects. People posting issues in the bug trackers demanding swift responses, downloading gigabytes of Open Source software without ever giving back and complain whenever projects don’t go in their favour. I have yet to come across a single popular Open Source project that thrives while being funded by private individuals, small and medium size companies.
Make contributions transparent and potentially rewarded
Publicly paying tribute to the contributors, is a way of implicitly outing those who consume, but not contribute. As maintaining a repository in a sustainable way is what most projects really want to achieve, generating income and securing contributions oftentimes are two sides of the same coin. Here offloading costs by sourcing the development and issue-solving among the largest commercial users can be of great value. Directly requesting them to contribute can be efficient, suggesting that if they are short on human resources, donations or as proposed by Tim White, hiring freelancers to submit enhancements on their behalf are ways to go about it. More generally social outing or praising on platforms such as Open Source Index is surely of great value to the industry as a whole. To a large user, it is also fair to bluntly express that “We expect someone on your team to make some commits to the code”. There is however a positive trend where larger corporations to a greater degree contribute to OSS projects. That said, in the end they still get a pretty sweet return on their investments.
Screenshot from Open Source Contributor Index (08.26.25). Last month with data is July.
In a HackerNews-thread from mid 2023, a user named Buttons830, suggests an interesting model: Make it possible for commercial actors to “pay” with contributions as well as money. If their contributions are deemed significant enough, they are permitted to distribute the code within their own projects under certain terms and conditions. In such a case, the payment model will clearly differentiate itself from closed source software, as well as focusing on the contribution philosophy as opposed to monetary transactions. To make the linking even more transparent one could attach various subscription tiers to specific issues in the backlog, disclosing the reward upfront to those who want to contribute and have commercial interest in the code.
Request payment for development of — or access to — certain features
Another action OSS projects could take, is putting a price tag on the development of certain requested features or for jumping the line and getting certain issues prioritised. This business model could easily be justified, especially for features that generate value for a narrow group of users. It would still be free to use the actual code, only requiring payments for certain types of development. Here one could apply a revenue-sharing model for the paid feature between the developer who takes on the development and the project itself, in order to incentivize the community to pick up tickets that could generate revenue for the project.
Some have been suggesting to introduce “pay to compile”. In other words, open source your code to the world, but if you want to download an .exe you need to pay an upfront cost. However, the issue with this approach is that it is almost impossible to enforce in practice, as it is in most scenarios too easy to circumvent. Others are suggesting paid documentation, where basic docs are available for free, while in-depth docs come at a cost. This is easier to enforce, but could create dissatisfaction in the community if not communicated cleverly. A more established and well tested approach is hosting. Many users don't want the hassle of running the code themselves, and are gladly paying for a hosted version of the software. WordPress, MongoDB, ElasticSearch, and many other tools offer this option.
Don’t rely fully on licensing — Get creative
Despite a license being a legal instrument in theory governing the use and redistribution of software, the practical value is normally only as good as the conscience of those who use the software. As Karl Hughes puts it;
Let’s not be naive. Once software is out in the public domain, some people will steal it, and they’ll likely get away with it. So, most open source companies choose not to use a license as their primary means of monetizing their software.
Even among open source licensing models, the number of conditions associated with them range from none to numerous. Among the larger more established licenses, the MIT license is often regarded as one of the most permissive, while the GNU GPLv3 (GPL), initially written by the legendary Richard Stallmann, as one of the more restrictive. An interesting aspect of GPL is that it comes with a “copyleft” liability. Copyleft means that the license allows for free distribution, use, and modification of copyrighted material (in this case software), with the stipulation that those same rights extend to all derivative works; that means that any project built using GPL code must itself have a GPL license.
Richard Stallmann. Photo courtesy: Michael Debets/Pacific Press/Lightrocket/Getty Images.
That works well for non-commercial actors, but is less viable for the commercial software companies. Therefore many OSS projects offer a dual licensing model, giving corporations the option to pay in order to keep their own code undisclosed. This means that dual licensing is only relevant for the more restrictive licensing models, such as GPL. Dual-licensing also comes in other formats, such as offering two versions of the same software; one closed source version and one open source version. The closed source version would usually come with additional support and functionality, in exchange for a fee. This closely resembles the “open core” approach, where the developer offers a “core” or feature-limited version of the software, while also offering commercial versions as proprietary software. Not too far off, from how commercial software companies usually operate, having a free version of their software with various paid tiers on top of it.
As the licensing model is so hard to enforce, some projects are making their code closed source for a limited period of time. One example is the license of Dragonfly. They have a time-limited licensing period with certain restrictions, but after five years switch to Apache 2.0 (a permissive license). This could be a convenient way to secure funding, at least for a certain period, and maybe plan for other revenue sources as the restrictive license terminates. One might worry this could affect the willingness from the community to contribute in the early days, but if one gives the contributors an irrevocable legal promise that their contributions will be made available to all at a specific time, it may still be regarded as good enough (Buttons840). However, the risk is that it could make the software irrelevant at the time it is actually open-sourced, as alternatives may pop-up during the period, the project closes down, or the development moves in directions where the software becomes too specific to the initial contributors.
In the aforementioned scenario one would move from a restrictive to a permissive model. More commonly one sees projects move the other way. Starting out permissive, and in time getting more restrictive. Some will argue moving from open source to paid licensing is being dishonest. However, one could hypothetically have a licensing model, where everyone who onboarded while the service was free, indefinitely will get it for free, while only new users being onboarded pay. It is not totally unfair, as early adopters and supporters will then be rewarded for putting their faith in the project while it still hadn’t proven itself. Alternatively one could also have something like a linear pricing increase model, where the price gradually rises for every new user that onboards, rewarding those being early in supporting and adopting a project.
Illustration: Linear price increase model. Source: Own model.
No matter how you look at licensing, you should keep in mind that licensing is hard to enforce, meaning you should really reflect on what you want to achieve with the licensing model you go with. In most cases you should search for other income sources as well. Don't settle with just a licensing model. It is simple and convenient, but not necessarily the most viable longterm approach.
Let's skip the race to the bottom
Letting large commercial actors use a project can definitely have marketing value, and encourage development of other plugins and dependencies derived from the core. But OSS should stand up for the value it creates. Don’t let it turn into a race to the bottom, the same way Amazon is shopping for tax cuts and subsidies in various US states for their warehouses and fullfillment centers. It should be regarded as a collective responsibility within the OSS community to raise the bar together, for those who commercially benefit from the free code. OSS would still be open to the smaller projects who drive innovation, create new tech and don’t really generate any big money. But for the largest most profitable actors, it should come at a cost. So if you are starting an OSS project, don't skip the business model part. Paying attention to potential revenue sources may be your safest way to making OSS a viable full-time devotion in the long run, and at the same time benefit the community as a whole.
The text in this article was initially written in April 2024.
Share Article