Open-Core Companies Are Not Incentivized To Make Their Projects Good

Image courtesy of Bartosz Prusinowski from Unsplash.

SaaS companies built on open-source projects (also known as open-core companies) are not incentivized for their underlying project to be good; but rather to be _ good enough _.

Few individuals will trust a SaaS product built on a dubious underlying project, so I’m not claiming that these projects are bad. Rather, they are intentionally incomplete.

Many of these open-core companies (which I will hereafter refer to as “unicorns”) have spent time building out their underlying project to help their communities and increase adoption.

However, there comes a point where it is simply not profitable or cost-effective for the SaaS business model to spend time building out features for maintaining the open-source software (OSS) version. The OSS version merely serves as a proof point for guiding a purchaser down the funnel.

Throughout this article, I’ll defend this claim with a few main points, offer some counterarguments, and close with a discussion on the dire need for an update to OSS monetization.

Cannibalization

Photo by Victor Rodriguez / Unsplash

One of the common fears unicorns have is that the open-source offering will cannibalize sales of their cloud service tool. This fear is not baseless.

Consider the case ofHuggingFace, a wildly popular AI tool with over 70k stars onGitHub. They are universally loved by the community, have an amazing core project, and have massive adoption. You would think that with these accolades (not to mention their $2B valuation) they would be generating massive revenue.

That’s where you’d likely be wrong. According to a recent Forbes article, HuggingFace brought in less than $10 million in 2021. While that number is nothing to sneeze at, and I’m sure revenues are only improving for 2022, it hardly stands up to the titanic OSS adoption and valuation. With such a huge evaluation and growing expectations for revenue, it does bring up two important questions.

1. What are the root causes?
2. How does such an adopted project not pull in more cash?

The answer to both of these questions lies in the fact that the OSS project is too effective at what it does. No matter how socially beneficial it is to donate to and support companies that genuinely care for their OSS projects, consumers and companies will rarely do so, as our economic systems don’t incentivize that behavior. While they offer valuable paid services, most users come to HuggingFace for the pre-trained models, which are available out of the box for free.

The HuggingFace community is a genuinely cool place and I am rooting for the project to be successful and profitable. However, companies looking to follow in their footsteps are facing a massive challenge.

Community is a nontrivial endeavor

So even if there is potential cannibalization, thriving communities like HuggingFace will eventually lead to successful businesses… right? While most unicorns will naively believe this to be the case, replicating that success is not so straightforward.

While I am confident that HuggingFace will see success in the long run, many products trying to build a community around their open-core SaaS will likely end up creating a glorified support forum or a place for self-promotion. Additionally, the unicorn will struggle to unify the user bases of its SaaS and open-source offerings, which will appeal to vastly different audiences.

Communities like HuggingFace anddbt provide a lot of genuine value outside of just support and have many dedicated individuals working exclusively on the open-source offering.

For example, dbt has:

• An awesome conference inCoalesce that people are legitimately excited about every year
• Great meetups and culture around them
• A transparent and honest focus on diversity, equity, and inclusion
• Great free online courses and learning materials

As indicated in this exceedingly thoughtful response post to acallout of dbt’s community, CEO Tristan Handy mentions that in May, they had 10 full-time employees dedicated to dbt Core and 8 full-time employees dedicated to community work. This sort of top-down organizational dedication is impressive and notably rare in smaller organizations.

All said, it takes a lot of dedication to form a healthy and vibrant community. If the unicorn doesn’t allocate time and money to building out these resources for people in an honest way, its community will not resemble any of the success stories that came before it.

A product manager’s nightmare

Photo by Kamil Feczko / Unsplash

So where does that leave our unicorn? Their hosted and OSS project are diametrically opposed and the community they fostered is either a support forum, a self-promotion frenzy, or both.

Well, it gets worse.

Every theoretical improvement to the underlying project is limited by the time of their engineers. The unicorn has to constantly make complex decisions on whether or not to contribute every new feature to the open-source project.

Essentially, each feature needs to be inspected to see if it will bring profit as a proprietary offering. Simple improvements that can only be pushed to open-source require dedicated engineers or diverting time that could be spent on proprietary features.

Contribute too few features and the OSS community will weaken and adoption will slow to a halt. And, if you contribute too many features the OSS offering will start the cannibalization process of your hosted service.

This product management problem can be represented by an optimization function described with the following parameters, usually ordered by this priority:

1. Fix major bugs for the hosted product before anything else.
2. Fix major bugs for the OSS offering as soon as possible.
3. Create differentiated features for the hosted product.
4. Create features for the OSS product that can be absorbed into the hosted product.
5. Improve the self-hosting experience for OSS products if there’s any spare time (which there usually isn’t).

Not all companies abide by the priority list; to be clear, I am not suggesting that all SaaS companies operate this way. Many will put their OSS product first to gain favor from the community. This is a noble feat but does not guarantee a reward.

The point is, the journey of profit maximization will cause the unicorn to eventually pit themselves against their open-source community, whether they like it or not. This became the norm because venture capital realized that open-source communities are powerful marketing engines for a new startup to break into crowded markets.

💡

The question that follows is: how do we fix this incentive structure?

Counterexamples

Before we go into suggesting what a healthy monetization scheme for the OSS ecosystem would be, I wanted to acknowledge that there are some healthy counterexamples to the points that I have made.

Docker, Elastic, and MongoDB are great examples of succeeding with the hosted open-core SaaS. However, they are potentially large exceptions to this rule. The main differentiator here is that the global scale at which the community adopted their projects made sure that even if they only captured a small percentage of their users, that slice would still bring in significant revenue.

This is the reason why I believe that HuggingFace will eventually be successful. While everyone should aspire to this, the chance of achieving this level of adoption is low and is usually an exception. On the journey toward this level of adoption, companies will need a reliable and sustainable business model to stay afloat.

Fixing the incentive structure

Photo by Danny Howe / Unsplash

To fix the incentive structure, we need to attack the two halves of the problem. One half discusses what we can do about companies that actually benefit from being open-core and the other side discusses companies that don’t.

Let’s start with the first one.

Open-source support agreements are healthy

In the name of endless hypergrowth, unicorns and venture capital realized that support agreements aren’t exponentially scalable. They require lots of hands-on attention, have high customer acquisition costs, and are not always worth the business that it brings in (not all revenue is created equally).

On the other hand, cloud spending is comparably cheap to acquire, requires less hands-on attention, and can scale to your infrastructure and marketing budget. This is often referred to as product-led growth.

However, open-source companies need to accept that the majority of their big deals and logos come from support contracts, not cloud spending. Even if the landscape has changed since the old days of Red Hat’s support model revolution, the support contract system will always retain a mutualistic relationship with supporting the open-source project. The better the OSS project is, the fewer issues that pop up and require hands-on attention. Additionally, companies with support contracts can request features that will usually get pushed upstream for the greater community of users.

One may suggest: “If things are running perfectly, won’t customers reduce their required engagement or remove the support plan?” Generally, no. The cost of keeping experts around is usually far lower than a SaaS bill and new features will always need to be built.

Hypergrowth is cool but is not necessary to create a sustainable and effective business. Sometimes, insane aspirations will even lead to wildly unprofitable companies in the short term.

Your hosted SaaS does not need to be open-core

I have exclusively worked for companies that are based on open-source projects because I have a deep love for open-source communities and the ecosystems they foster. However, I have seen lots of founders opt-in to open-core purely for the potential sales funnel that they can create with their open-source “community.”

Additionally, unicorns think that open-source automatically means cool and trendy. This is wildly untrue; there is nothing less cool than an open-source project that is difficult or impossible to self-host. There are only so many benefits to be received from being able to stare at the source code, most of which are already captured through security compliance.

If you are creating a hosted product, seriously consider whether you can both sustain a business and bring legitimate value to a community before you consider making it open-core. Closed-source is not automatically uncool. What is cool is being genuine and honest about the way that you intend to monetize your business.

While we don’t have a SaaS product, one may ask, “won’t your open-source project fall into the same trap?”, which is a fair question.

In turn, we’ve used this as an opportunity to detail our monetization plan here.

If you have any further questions about how we plan to monetize, head over to our community Discord and ask us questions in the #feedback channel. We’ll be glad to help clarify any doubts.