4 business strategies for open source maintainers

Learn different ways to monetize an open source project with these sustainable business models.

Open source has already lost two big open source projects in the database world in 2024.

First came Redis, an in-memory cache database, with a loud announcement in March that they had replaced their open source license with the Service Side Public license. Then, in May, Broadcom quietly notified their users that all new versions of Greenplum, a popular analytical database based on PostgreSQL, will be closed source. Given recent news, it’s easy to assume open source and business are at odds. If large corporations struggle to support open source, what hope do small companies and individuals have?

At the same time, there’s a well-known issue that every maintainer of successful open source projects comes across. When your project is small, you’re full of enthusiasm to improve and develop it. It’s like your baby, and your heart melts when the first users leave positive feedback, ask questions and request new features. However, as your product becomes more and more popular, it becomes a nightmare. The number of use cases and feature requests starts to snowball. You need to add so many new things so fast that you can’t test them properly. When new users bombard you with questions, you have no time, no personal life, no hope.

There are two ways to solve this problem: Stop working on the project and maybe abandon it, or start making money and convert the project into your own company. Does that mean that you have to say adios to open source like the big companies have? Absolutely not. Moreover, your community will help drive the business faster, invest less resources and make the product stronger. You just need to choose the right business model.

Before you start

There are hundreds of different business models and thousands of combinations. Making the right choice is not as easy as it seems. For simplicity, let’s assume you’re maintaining an open source project with a community and looking to make it profitable. The evaluation criteria can be following:

• Investment: how much money is required to run and support the business.
• Community support: how you can keep your community happy.
• Customers: how hard it will be to acquire users.
• Competitors: how crowded the market is.

Using these four criteria, let’s review five different business models and their strengths and weaknesses.

Paid support or “How can I help you?”

The first and most obvious way to earn money from the open source project is by providing support. Moreover, this is a real-time-tested approach. Red Hat has been doing this with their subscription model that includes support for over two decades. Let’s see if this model is a good fit for your business.

Investment

You already provide free support for your open source product. The next logical step is to make it official, publicize the price for different tiers, and start accepting payments. You have everything that you need. It’s not a low investment, it’s no investment.

Community support

Here’s where the trouble starts. It can be tricky to find enough time to support both the community and the paid users. You can lack motivation to freely provide something that, as you know, you can sell. At the same time, your community immediately feels that you are not interested in their questions and after which they’ll return the ‘favor’ by leaving unsatisfactory and disgruntled reviews. Finding a balance between growing your community and building partnerships with customers is not trivial.

Customers

This part depends on your product or service. If you have a tiny library or simple product, working with it isn’t a big deal, since most users won’t have any questions and, therefore, they won’t need support. On the other hand, technical support is a main requirement for software used in enterprises. They literally cannot start using applications without support. These companies are waiting for your official proposal. Only you know who your users are and if they need your help or not.

Competitors

It’s easy to think that if you are a product creator you don’t have competitors who provide support. Don’t be naive. As soon as your product becomes popular enough, people offering to consult your users automatically appear. The funny thing? Often, they can provide better support because you have a lot to do, like product development or community maintenance, when your competitors can fully concentrate on consulting. It’s not a blocker, especially for small projects, but it’s better to keep it in mind.

GPL: Not for commercial use

The next model doesn’t even look like a business model. We’re talking about a GPL license – a license that restricts commercial use. Some people believe that this is the only real open source license. A bright example of a successful product with this license is the MySQL database. More than half of all websites rely on this database. Acquired by Oracle in 2010, a testament to the project’s success, it remains open source. The obvious question is: Where’s the money? The answer lies in additional services. While you can’t sell the core product, you can create value by offering specialized tools for enterprise integration. You can sell packages with developer tools, drivers, and even resources to run the product, for example, like cloud providers do. You can sell services all together or one by one. ​​On their own, these services may not be interesting, but together with the open source product, they are very valuable.

Investment

From the product perspective, there’s no investment, you just publish the product with the right license. However, you’ll need to develop all third-party services that you’ll sell. Even if they’re tiny, it takes time to work on them and support them.

Community support

Your community is your driving force. You keep developing the main project as usual, ensuring everyone benefits from new features. This keeps your users happy and eager to recommend your product. Your additional services are optional extras that don’t directly impact the core community. This way, you maintain your open source credibility.

Customers

Customers are also happy. They benefit from your substantial services (your open source product) for free and need to pay for the tiny part – your additional tools. If your open source product’s value is significant, your customers will easily spend money on the add-ons, if they need them.

Competitors

The great news is that no one will sell your product. The bad news: this includes you. You can develop additional tools and, most likely, you’ll do this better than anyone else. But the largest bulk of your work will be closed for selling. Will you get enough income to support the development of both the open source product and integration tools over the long term?

Commercial features: Secret sauce

The next business opportunity is also very common. Instead of inventing integration tools, maintainers add commercial features to the product itself and create a special product version. Now, they have two products: open source and commercial. A good example from the database world is ClickHouse with its open source ClickHouse version and ClickHouse Cloud. Easy to do, easy to understand and the whole effort you put into the product works for sales. What are the pitfalls?

Investment

First, now you have two products instead of one. This means more sophisticated infrastructure, more complicated processes and more resources that are required for maintenance and support. Of course, they’re not completely different products: you re-use a big part of the open source product in the commercial one. You have to be ready for additional expenses.

Community support

With sufficient resources to support both projects, your community can be a powerful ally, providing invaluable feedback and helping spread the word about your products. You’ll get things for free that regular businesses spend a lot of money on. But be careful with community expectations. If you decline a pull request with an important feature from a contributor, but then implement the same feature in the commercial product only, – the wrath of the community will fall on you. In the best case, you will be called Open Core instead of open source.

Customers

It can be easy to find your first customers. Your community members will buy the product to support you and your project. You can develop custom versions of the product for the particular buyer if this approach looks attractive to you. You can also develop additional features that are available for every paid user. You can decide which features are for the community and which are for the commercial version. You have usage statistics from the open source product, so it’s possible to analyze trends and develop functionality that brings the biggest value. All of the above make this model very popular.

Competitors

The thing that you will realize very quickly is that your main competitor is your own open source project. The average conversion from community to paid users for most open source projects is around 0.01%. Very popular products can boast about conversion rates of 0.05% or even 0.1%. (This is ballparked from my experience with a number of small, medium and larger open source projects.) People don’t like sharing these numbers — they’re frustrating. Those numbers aren’t as bad as you think. Your community is a valuable asset beyond just potential customers. We could dive deeper into this, but for now, let’s remember: closing your open source product and focusing solely on a commercial one is unlikely to improve your situation. It could make things worse.

Let’s talk about security

Security is a controversial topic for open source projects. Open code that’s tested and reviewed by thousands of users is very attractive for companies. It’s a mark of quality. Together with that, companies often demand a single point of contact to handle possible issues and integration difficulties, which directly contradicts the open source model of shared responsibility.

That brings us to the next business model: to sell the validated and certified version of the open source product and guarantee to be responsible in case of issues. It can be closely compared with the insurance. A great illustration is PostgreSQL, the database developed for many years by hundreds of contributors from different countries. With Postgres’s rise in popularity, a surge of consultancy services emerged like mushrooms after a spring rain, offering customized Postgres solutions often mirroring the original but supplemented by security certificates.

Investment

To get started, you’ll first need to thoroughly test and verify your product’s security. This is crucial. You have to pass a third-party audit on a company level and a product level, maybe even a few others. You have to set up the process of regular verification. You sell certainty, so you need proof.

Community support

Again, only positive things for the community here. The product becomes more stable and more secure. Who on Earth can complain about that?

Customers

Although security is a crucial part of the product audit process, it might not be enough value to purchase. Although security is extremely important for big enterprises, especially in the financial sector, small and medium businesses can integrate open source software without official security checks. To attract businesses, your product must have a lot of specific functionality to cover their needs, which is rare for young open source projects. At the same time, a few big banks on your list of customers can guarantee you a great and, what is more important, stable and steady income to develop your product for many years.

Competitors

You can argue that anyone could do the same. Anyone can make a fork of your project and provide security documents by request. That’s true. However, as a maintainer, you have the advantage of being a creator. People will trust you more than anyone else because you know your product internals better than anyone else and have more control.

Late delivery comes last

To wrap up our review, let’s explore a unique model successfully implemented by MariaDB. The core concept is straightforward: early access to new features for paying customers. For example, you have big releases every two years. You also have small intermediate releases that are available for Paid Users once per quarter. New important features and enhancements appear in intermediate versions, and customers can start using them immediately. The community will also have access to this functionality with a big release after two years. Some people are ready to wait, while some people want it right now and are ready to pay for that. Simple.

Investment

The investment is minimal: you develop only one product, you support only one product, and you fix bugs only for one product. In the modern world, having two versions of the same product available is the norm.

Community support

This model has a very important benefit compared with the additional feature development model: earlier or later all features will be in the community version. Features requested by the community, features requested by the customers, and all of them will be released and open to everyone. The quality and feature fulfillment of the open source product, in this case, is maximal. It’s like a boosted open source: you accept contributions and also invest money and the ideas of your customers into the open source project.

Customers

Again, we can compare this model with the additional feature development and, at this time, it is not in favor of our current model. The only reason for your customers to buy the product is urgency. If they can wait, they don’t need to pay. It means your main goal will be to create this urgency. It’s not always possible. Is it possible for your product?

Competitors

This means that your main competitor is and isn’t your own open source product again. A sense of urgency for customers determines everything. Your appreciative community may become the main growth driver. Their recommendations and valuable feature requests will attract new customers in the intermediate period. This model is complicated, and not for everyone, but that doesn’t mean it won’t work.

The upshot

Before you dive in and start your business, let’s recap the key points.

We’ve covered five business models that work for open source projects. However, it’s important to note that pure model implementations are rarely encountered in the wild. Companies usually combine two or three in different proportions to get the ideal model for their business. You will need time to experiment and find the right one, but that’s normal.

One last piece of advice: Be data-driven. Your community provides an enormous amount of data about product usage, the most popular features, and user personas. Non-open source businesses will collect such data bit-by-bit for years. You already have access to it. Simple analysis helps you make the right decisions.

Last but not least: have fun. No one can push you to choose a model you don’t like. You have to choose the one that best suits you. Your workload will increase after you start your business, but it’s not an issue if you enjoy the journey.

Good luck!

More from We Love Open Source

• How to import data to your database with DBeaver
• What was the software world like before open source?
• A how-to guide for paying open source maintainers

This article is adapted from “How to choose the right business model for your open source project” by Tatiana Krupenya, and is republished with permission from the author.