Monetizing Open Source [Pt 1]
This is a five-part guide on creating a sustainable business model for open-source projects. It will provide actionable frameworks and insights into how open source can be monetized.
Open-source software has long been the bedrock of innovation and collaboration, powering some of the most transformative technologies of our time.
According to the Boston Consulting Group,
99% of Fortune 500 companies currently use open-source software
80% of IT departments will increase their use of open-source software
35% of all enterprise software is based on open-source code
Generating revenue and establishing a sustainable business model for open-source projects continue to be significant challenges, as these projects have typically faced funding difficulties. The issues faced by OpenSSL serve as a prime example. OpenSSL is an essential security software used in various applications, including web transactions. Despite its importance, it has historically received a mere $2,000 in funding. In 2014, the Heartbleed vulnerability brought attention to the crucial nature of OpenSSL, resulting in a funding increase of $11,000. However, this sum remains insufficient considering its critical role.
But there are success stories as well.
Innovating on monetization models – Red Hat to Databricks
Red Hat blazed the trail in monetizing open source when they started providing support and services for Linux. They were later acquired by IBM for $34 billion. More recent successes have been Databricks, valued at $34 billion in a private valuation in 2021, and HashiCorp, valued at $14 billion at IPO.
According to Bessemer Venture Partners, companies based on open-source projects are founded approximately 3.5 years after project creation.
Image credit – Bessemer Venture Partners link
Many readers might be astonished to find HashiCorp and Databricks categorized as open-source companies. In a sense, this highlights their success. These companies have achieved the commercial success that their target market does not anticipate receiving free offerings from them. They have effectively honed their market strategies and sales approaches.
Monetization Mistakes
The contrasting trajectories of SourceForge and GitHub serve as a compelling cautionary narrative. SourceForge, a web-based service established in 1999, provided developers with source code repositories, bug tracking, and an array of tools for open-source projects. SourceForge’s code was released as open-source software in 2000 under the GPL license.
For a decade, spanning from the early 2000s to 2010, SourceForge was the veritable epicenter for hosting source code repositories. Their revenue grew from $26 million in 2006 to US$ 92 million in 2009. They monetized their open-source project as a media site and made money through banner advertising.
In 2013, they attempted to expand monetization in a series of efforts that ultimately killed them.
1.    Bundling adware with installers: SourceForge began bundling adware with the binary installers of some open-source projects hosted on its platform. This practice was widely criticized as it undermined user trust, potentially exposed users to unwanted software, and went against the open-source philosophy of providing clean and transparent software.
2.    Taking over abandoned projects: SourceForge started taking control of seemingly abandoned or inactive projects and continued distributing them with adware included in their installers. This further tarnished the platform's reputation and resulted in pushback from the community.
GitHub was profitable right from the start. They generated $1000 on their first day.
In the early days of GitHub, the founders—Chris Wanstrath, Tom Preston-Werner, and PJ Hyett—adopted a bootstrap strategy to launch their venture. Established in 2008, GitHub emerged as a platform for developers to host, share, and collaborate on code using Git, a distributed version control system created by Linus Torvalds.
Despite facing competition from established platforms like SourceForge, GitHub prioritized simplicity, user experience, and social coding, thereby distinguishing itself from its rivals. The platform's freemium business model allowed users to create public repositories for free while charging for private repositories, thus ensuring profitability from the outset.
GitHub did a few things right and SourceForge did some things wrong when it comes to monetization. What lessons can we learn from the five companies, and can we distill the learnings?
That is exactly what we will cover in this guide over the next five weeks.Â
Open source is the software development model. What is missing is a business model.
Technology, product, business
If you are considering monetizing your open-source project, it's important to understand that you haven't yet established a business based on it. At this stage, you possess either a product or the underlying technology, both of which hold the potential to evolve into a fully-fledged product and business.
When it comes to revenue and monetization
Business > Product > Technology
What is the difference and why does it matter?
Raw technology refers to the various tools, methods, and frameworks employed in the development and maintenance of software products. A repository that requires extensive code customization is raw technology and not a product, as it does not directly address specific use cases. However, with the necessary customization, it can be tailored to solve those use cases.
A product enables users to utilize technology while offering convenience and refinement. The key distinction is that technology supplies the fundamental building blocks, which must be tailored by the intended user. In contrast, a product can be used without any customization by the end user. In the context of open-source projects, many repositories considered products are designed for developers, who are the end users in this case.
The Linux kernel is a technology, not a product.
Although the Linux kernel is a fundamental part of numerous Linux distributions, it often needs significant customization and configuration before being used in a specific product or environment. Developers and system integrators must tailor the kernel to their specific hardware, performance requirements, and desired features, which often involves modifying the kernel's source code, selecting appropriate modules, and configuring various settings.
The distribution is the product, while the kernel is the technology.
Whether a project is for the front-end, middleware, or back-end does not determine if it is a technology or product. Backend or even networking libraries can be considered products.
Socket.io is a networking library that qualifies as a product. The target users for socket.io are other developers that are building their products. But the critical insight is that these developers can use socket.io without any customization of socket.io’s source code. It is a complete product that solves use cases for these developers. Another example of a product, even though it sits deep inside code is TensorFlow, an open-source machine learning library developed by Google. TensorFlow provides a flexible platform for building and deploying machine learning models, but it is a complete product for its intended users.
However, it is important to note that a product by itself does not generate revenue. You need to build a business around a product. Regular, recurring, and repeat monetization of any human activity is classified as a business.
You need to know which state is your open-source project in before you can start to think about monetizing it. If your project can already be considered a product, then it will be easier to monetize it. There are also more ways to monetize a product compared to raw technology.Â
Monetization is going to be tough but for reasons you don’t want to think about
Monetizing your open-source project is hard but for reasons that you might not expect. It is hard because of the reasons that made your open-source project successful in the first place.
Technical people are often introverts and find it a challenge to talk to strangers. Writing code requires a high degree of concentration and focus, which can be disrupted by social interactions. Technical people often prefer to work independently or in small groups with individuals who share their interests and expertise.
Once you start the process of monetizing your work, you can no longer focus on just the technical parts, or only work with other contributors to your open-source project. You are going to have to transition to the role of the founder and CEO of the business that you are trying to build. In the early days and for a long time, you are not going to be able to outsource this work to a product manager or VP of Sales.
This part is so crucial to your success in monetizing that we will repeat it. As you start monetizing your work you will have to push the boundaries of your comfort zone and take on the role of a founder AND the VP of sales.
In part III, which comes out on April 21, we’ll cover a detailed and step-by-step guide on how to select which customers to talk to, how to structure the conversation, and how to digest that feedback. This step-by-step process will make sure you have a detailed and actionable plan for each part of the process.
The other hard parts about monetizing open-source projects
Betraying ideals
Most open-source projects begin as passion projects, driven by a desire to solve a problem, pursue a passion, or contribute to the community. As they gain traction, these projects often attract a following and grow into large, vibrant communities.
Many founders and maintainers are reluctant to pursue financial gain, as it may conflict with the altruistic and collaborative ideals that underpin the open-source movement. This reluctance can make it difficult to find sustainable revenue streams and create a viable business model.
Despite these challenges, it is possible to monetize an open-source project without sacrificing its founding ideals. By taking an innovative and flexible approach, We’ll talk about the guard rails you can deploy to protect your open-source project and its community while you pursue monetization.
Sustainable moat
Even when companies find a good business model, like Red Hat, they struggle to innovate and grow.
A while back Peter Levine had written,
There are many reasons why the Red Hat model doesn’t work, but its key point of failure is that the business model simply does not enable adequate funding of ongoing investments. The consequence of the model is minimal product differentiation resulting in limited pricing power and a corresponding lack of revenue. As shown below, the open-source support model generates a fraction of the revenue of other licensing models. For that reason, it’s nearly impossible to properly invest in product development, support, or sales the way that companies like Microsoft or Oracle, or Amazon can.
We’ll discuss ways, in this article, to keep the balance between the founding ideals and the requirements of a business.
Different types of Open-source projects
There is one final piece of mental scaffolding that we need to build before we can start thinking about the economics of open source (in part II, which comes out next Friday).Â
We have already discussed categorizing projects as raw technology, product, or business. Another dimension of categorizing software projects (open source or not) is to determine if the project is a finished application, library, framework, or standard.Â
1.    Applications: Applications are software programs that have a specific purpose and can be used directly by end-users to perform tasks or solve problems. These applications are typically standalone and can range from productivity tools, such as word processors and spreadsheets, to entertainment and communication platforms, such as video players and messaging apps. Microsoft's Visual Studio Code is an end-user application for developers.Â
2.    Libraries: Libraries are collections of pre-written code, functions, or routines that can be easily integrated into other software projects. An application can and usually does, use multiple libraries for different things. These libraries save developers time by providing reusable components and utilities that address common problems or perform specific tasks. Examples include programming libraries for handling graphics, audio, and network communication. Lodash is a library of utility functions for JavaScript developers.Â
3.    Frameworks: Frameworks are structured collections of code and tools that provide a foundation upon which developers can build applications or systems. These frameworks often establish a standard structure, methodology, or set of conventions that streamline the development process and enable developers to create applications more efficiently. Examples of open-source frameworks include web application frameworks, such as Django or Ruby on Rails, and game development frameworks, such as Unity or Unreal Engine. It is not uncommon for an application to use multiple frameworks. For example, it might use NextJS for front-end development, NestJS for backend development, and TensorFlow for machine learning.Â
4.    Standards: Open-source standards are specifications, protocols, or guidelines that help ensure consistency, interoperability, and compatibility among different software systems and platforms. These standards are typically developed and maintained by industry groups, organizations, or consortiums and are often implemented in open-source software to facilitate widespread adoption. Examples of open-source standards include data formats, such as XML or JSON, and communication protocols, such as HTTP or MQTT. Language specifications like ECMAScript 2024 or the Python language reference are also standards.Â
Each item mentioned previously is considered a product, rather than a technology. Standards, such as language specifications, also qualify as products since they can be utilized by their target users without modifications or customization. In the context of a standard language specification, the intended users are developers who create compilers and interpreters for that language, making the language specification a comprehensive product.
The monetization strategy we choose will depend on whether the project that we are attempting to monetize is an application, library, framework, or standard.Â
Homework
In preparation for next week, look at these 10 projects and decide if they are.
-Â Â Â Â Â Â A technology, product, or business
-Â Â Â Â Â Â An application, library, framework or standard
1.    https://jaykmody.com/blog/gpt-from-scratch/
2.    https://github.com/numpy/numpy
3.    https://docs.oracle.com/javase/specs/
4.    https://github.com/expressjs/express
5.    https://github.com/microsoft/JARVIS
6.    https://github.com/Torantulino/Auto-GPT
7.    https://github.com/ethereum/go-ethereum
8.    https://github.com/grafana/grafana
9.    https://github.com/signalwire/freeswitch
10. https://www.unrealengine.com/en-US/ue-on-github
Comment below on what each of these projects are.
What we won’t cover
Our focus will be on monetizing your open-source project, but we will not cover any guidelines on raising capital for your company, branding or marketing or hiring. There are excellent guides on all these topics, and we’ll give you a link to all of those, but we won’t cover those ourselves here.
What’s Next
This guide is designed for authors and maintainers of open-source projects, as well as business owners and product managers in companies investing in or acquiring open-source businesses. It will provide a solid understanding of core business principles, practical insights, checklists, and case studies featuring both successful companies and those with room for improvement.
Each Friday, over the next four weeks, you’ll receive one part of this guide.Â
Part II covers the economics of open source. Why does open source exist and what value does it contribute? We’ll also talk about how to determine what value your specific open-source project delivers to your intended customers. Notice that the word here is customers and not users. Customers pay, and users don’t have to.Â
On April 21, we’ll cover a detailed plan on how to get feedback from customers. This will include deciding which kinds of customers to talk to, what kinds of questions to ask, and how to collate all that information to write down specific use cases, benefits, and friction points for customers. This part will include a worksheet that you will be able to fill in. This work is going to be critical to the next step.Â
We will use the information that you filled in the worksheet to decide monetization scheme and actual pricing on April 28.Â
We’ll cover creating long-term value and building a sustainable business on May 5.
Finally, as a bonus, we’ll cover Artificial Intelligence and Open Source on May 12.Â
See you next Friday.