Building a business on an open-source product

There are multiple ways to monetize an open-source product. Let's talk about a few of them here. One important thing to keep in mind is that these aren't mutually exclusive: any company can employ one or more of these options simultaneously.

1. Pure consulting services
2. Open source license + support
3. Enterprise tier with separate licensing
4. Traditional SaaS (pricing, tiers)
5. Product-Led SaaS (with Freemium or Free Tier)
6. The Cloud Protection License

Pure consulting services

In this model, you build and maintain open-source software and sell consulting services to install, customize, or operate the software on behalf of customers. This model was the primary model for open-source software for a generation but has largely fallen in disfavor since the operating cost of maintaining a consulting organization is several orders of magnitude greater than the operating cost of SaaS/Cloud offerings.

Support services

Often a customer is willing to take on the cost of operating, maintaining, and customizing the software, but would like to be able to escalate support issues to the original project maintainers. In this model, you build and maintain open-source software and sell support contracts to clients who want to deploy it themselves on-premises or in their own cloud.

This is another tried and true model for open-source software. However, the operating cost of support is significant. Unlike support for a Cloud-based product, support engineers need to quickly become experts on each client's deployment environment, unique customizations, and unique infrastructure constraints. Perhaps of lesser importance, support engineers also need access to client environments in order to correctly debug and test, a potential liability, especially when dealing with sensitive organizations or governments.

Enterprise tier with per-seat/per-socket licensing

Suppose you want to maintain a core open-source product, but build add-ons and other capabilities that you'd like to charge for. In this model, you'd offer your additional capabilities in a separate SKU (or SKUs) and license this "Enterprise Edition" on a per-seat or per-socket (CPU) licensing model.

This represents a hybrid of the open-source model and the old commercial software model. Maybe your higher-end SKUs are offered as "source-available," albeit with a commercial license, so that customers can still benefit from being able to customize the product and peek into the code.

Several open-source companies burned by the big cloud providers (see Cloud Protection License, below) have turned to this model where their original open-source product is available but their new and future capabilities are in a commercially licensed SKU in order to protect themselves from further cannibalization by Amazon, Microsoft, and Google.

Traditional SaaS

Many open-source projects are highly complex and require significant effort to customize, tune, and maintain. As customers move more of their projects to the cloud, they have gained more comfortable choosing third-party cloud offerings. With a traditional SaaS model, customers can eschew running their own instance of the open-source project and instead ask someone else to do it on their behalf.

Companies can offer and maintain different capabilities on different pricing tiers, providing the means to monetize existing customers at higher levels.

I won't belabor the intricacies of the SaaS model, but suffice to say, it's the obvious direction in which the industry is moving. If you don't yet have a Cloud-first product, it's time to get moving towards it.

Product-Led Growth SaaS

I hesitate to call this out separately from traditional SaaS, but Product-Led Growth (PLG) companies are so popular now that it's important to describe the distinction between the two.

In a PLG SaaS motion, you are ideally giving developers a Freemium experience where they can use the entirety of your product, albeit limited in some fashion. In so doing, they experience all the features and can weigh whether or not to continue with a fully paid account. You can also identify which features are most important to these "pre-qualified" users so that your outreach is targeted and helpful.

The thing I love most about PLG products is that I never, ever have to talk to a live person to get started. I can sign up and get going in seconds. I can elect to pay once I need it. There's no "Talk to Sales" button or "Contact Me" query. The product either sinks or swims on its own.

Because of this immediate feedback, it is essential that your PLG SaaS product is more than just an open-source product that is hosted. Add value, and focus your efforts on the user experience. Make onboarding really easy. Get me from sign up to recognizing value as quickly as possible (see my advice on How to Write a Getting Started Guide for more information). Help me discover new features progressively as I use the product.

Product design and user experience design are essential requirements for a great PLG SaaS product. Your private alpha should be focused entirely on ironing out user experience and onboarding issues. Get this right before going public. With PLG, there's no sales team standing by to paper over any warts in you product. Your product either sinks or swims on its own merit.

Cloud Protection License

I want to touch briefly on an important innovation in open-source licensing, one which open-source zealots routinely disparage. The Cloud Protection License, which we first made popular at Timescale, ensures that the big three cloud providers (Amazon, Microsoft, and Google) can't simply take your open-source product and offer their own competitive SaaS offering.

Competition with the big three is hard enough without having to compete against your own hard work also.

Think hard about including a Cloud Protection License in your go to market plan if you have a pure open-source product that anyone can download and install on their own.