Open Core - Monetize Through First Principles

Compared to a few years ago, there’s no doubt that open source vendors can be financially successful. Red Hat paved the way. In the last quarter before the IBM acquisition, Red Hat achieved a $3.7B annualized revenue run rate^[1]. That’s incredible. Despite Red Hat’s success, the overwhelming majority of today’s open source vendors are not following Red Hat’s footsteps. For good reasons, most companies follow an open core model (selling proprietary software that extends the functionality of the “open core” aka the open source project). It provides more flexibility and allows for better monetization in most cases.

When I reflect on the many conversations I had with technical startup founders over the last year, I see another sea change happening: It’s less about the open source movements' ideals and philosophical beliefs. What matters to this new “class” of founders is whether using open source makes their company more successful or not. Some of them push it to an extreme and see it as their primary differentiator. “We are like x, but open source”. I don’t believe this theme will last for long but might provide an edge in certain markets for a short period of time. The approach can be powerful if paired with another unique differentiator (e.g., Mattermost = Slack but self-managed/on-premise + open source).

Some people believe that open source software will take over the world. I disagree. Open source doesn’t necessarily result in better products. More importantly, most non-developers^[2] don’t care about open source. It’s irrelevant to their purchase decisions. It’s not driving consumer behavior. The reason is straightforward. If you don’t have the desire or skills to download and run an open source project, there’s no advantage over a comparable product that’s free. There is one caveat to this. Developers can bring non-developer products into a company if they play an important role in adopting these products (e.g., Stripe as a payment provider).

If you consider building a B2B company that serves a technical audience, open source might be a powerful tool for you. Most likely, you will pick open core^[3] as a monetization strategy. Open core has a “built-in conflict” between the open source project, the community, and the commercial vendor. By definition, if you extend the “open core” with proprietary functionality (so that you can monetize), you hold functionality from the open source project. Managing this conflict is crucial for the success of your company. It will help tremendously if you derive what goes into open source vs. what’s proprietary from first principles.

There’s one important question you should ask yourself for every new capability:

Who is the primary user of this feature?

If the user/beneficiary of a feature is the developer, it should always go into open source. The better your open source project is, the more adoption you will see. In case there are multiple, competitive projects in a given problem space, it will also help you differentiate and win^[4]. All of that results in a larger addressable market for you. As an open source vendor, you are constrained by the adoption of your open source project. Assuming you hold back those developer features, and try to monetize them, you will not generate a lot of revenue. The money is somewhere else (manager, executive). If you want to monetize the developer adoption, offer a SaaS product.

If the user/beneficiary of a feature is the manager, you can most likely keep the capability proprietary. The most important exception to this rule is if engineering managers are the primary users of the product (e.g., a tool that helps the manager manage). Another way to think about this is the following: Within an organizational hierarchy, you monetize the top (exec/manager) and contribute the bottom capabilities (practitioner/manager) to open source.

If the user/beneficiary of a feature is an executive, you keep the capability proprietary.

There are two reasons for this framework.

The obvious one is the monetization potential of a given capability. Executives can spend more money ($$$), than managers ($$), who can spend more than practitioners ($). You lose very little by not monetizing the persona with the least monetization potential. In return, you are more likely to get a lot of bottom-up adoption, making selling to executives/managers easier. Additionally, offering a SaaS product allows you to monetize the practitioner segment at least partially.

The second reason is less obvious but equally critical. Executives won’t contribute to your open source project. Managers will do it rarely. If they need a specific capability, they won’t open a PR towards your open source project. In some cases, they might ask an engineer in their organization to build it for them, but that’s the exception, and rarely the case if you offer the capability for a reasonable price. Developers are the opposite. If they miss a capability, they will be inclined to contribute. This is fantastic and exactly what you want because it increases the value of your open source project. Most important, rejecting a PR from a developer for a developer feature (because you want to monetize it) will inadvertently create conflict. Other developers will be less inclined to contribute, causing your open source project to suffer. You won’t have a thriving and growing community.

Open Core is a terrific business model if you manage the inherent conflict about what to open-source and what to keep proprietary well.

[1] Source: https://www.sec.gov/Archives/edgar/data/1087423/000108742319000017/rht-10qq1fy20.htm
[2] I use “developers” as an umbrella term for people who have the skillset to build/run applications, understand source code, etc. It includes data engineers, devops engineers, sysadmins, and so on.
[3] I will save my thoughts on why I believe open core is the best model for another blog post. Without getting into too much detail, offering a SaaS product isn’t sufficient long-term. You need differentiating and proprietary capabilities as well.
[4] As an open source vendor, you want your open source project to be the default and industry standard for a given market.