The Red Hat model only worked for Red Hat

Giant value creation, very little value capture. That is the Red Hat model. The first company to successfully commercialize open source software at scale, Red Hat managed to make a billion-dollar business out of selling vetted open source updates and providing multi-product support, services, and training. At first, the model seemed like it could be the blueprint for commercial open source software. The only problem is no other company has been able to replicate this model successfully.

Low rake

Any company, open source or not, always has to think about rake: how much of the value that you generate do you capture? Red Hat may have one of the lowest levels of rake in the history of any software company. The company generates way more value than it captures and has a low rake out of necessity—none of the software it creates is proprietary. If Red Hat tried to force people to pay too much, everyone would switch to the freely distributed versions (AlmaLinux, Rocky Linux, etc.). To increase profit with a low rake, Red Hat greatly increased the value it created by not just providing updates and services for Linux but for an entire suite of products.

A complicated model under constant threat

Red Hat’s 30+ products span a huge range of categories, from platforms to application services to cloud computing, data services, and automation. According to Gartner, the company competes with nearly every major technology company. It’s under constant threat of being disrupted or undermined by other open source providers. The problem with selling open source updates is that you don’t own the update—it’s open source! Red Hat faced this problem when CentOS launched in 2004, offering Red Hat Enterprise Linux (RHEL) software updates for free. To quell the issue, Red Hat hired the maintainers of the CentOS project. Under Red Hat control, CentOS no longer modeled RHEL production code but was marketed as a beta—a preview of what was coming down the pipe. Eventually, the company sunsetted the project entirely, and as a result, new copycats emerged. AlmaLinux was created specifically to fill the gap left by CentOS, and the original creator of CentOS created Rocky Linux with a similar mission.

All along, the company could have switched to creating proprietary functionality, but it stayed extremely principled to completely open sourcing all its software for 30 years, and that should be applauded. But selling a product that is 100% open source is a very delicate balancing act. Low rake, a complicated multi-product model, and the constant threat of disruption make Red Hat an economic outlier that another company is unlikely to replicate with success.

The open core model

Most open-source-based startups today are focused on a single product. These companies generate higher rake by adopting an open core model: making some of the codebase proprietary but source-available. Many companies have started with a similar updates and services model, but the open source companies that have shown exponential growth ultimately went public with an open core model.

MongoDB started as an open source support-and-services model under its original name, 10gen. Until 2011, the only “product” offerings promoted on its website were support, services, and training for the open source project Mongo. In 2013 the company switched to an open core model and rebranded to MongoDB. It went public just four years later. When the co-founders of Elastic first formed the ELK stack comprising three open source technologies, it wasn’t long after that they released their first commercial plugins. In case of Odoo, an open source ERP and CRM software. CEO and founder Fabian Pinckaers tried a services and support model for years before switching to an open core model. After nearly a decade of struggling, things started to turn around quickly after pivoting its business model.

The Red Hat model won’t be repeated. In reality, open core is the most economically viable model for commercializing open source software. It’s poised to replace proprietary software as the default and is the path for open source projects to develop into sustainable businesses.

Support and services models don’t achieve hypergrowth

Technically, a support and services model is an option for commercializing open source software, but it’s highly ineffective and definitely not a business model for high-growth companies. Margins are thin, making it difficult to invest in research and development and marketing. Getting contracts for development work with large customers can be difficult since most organizations already have preferred vendors for software development. Developing features under a support model gives you no entitlement to the technology. And, if you’re good at what you do, you’ll eventually put yourself out of a job since customers can use it without help.

The goal of providing support should be to make the software itself simpler, easier, and better to use. When issues and problems arise via support tickets, it’s much better for everyone if improvements are integrated into the software. Similar for services. While there will likely always be situations where complicated setups and integrations are necessary, the goal should be to eliminate long-term, ongoing service needs by consistently improving the software. Simpler, easier-to-use, easy-to-integrate software will only gain in value over time. This approach benefits more people and creates a more reliable revenue stream. When improvements are added back to the core and premium features are sold as subscriptions, margins are wider, so you can invest in things like R&D, sales, and marketing.

Support and services companies are uninvestable

The biggest reason why we don’t see support and services companies achieving hyper-growth is that they are uninvestable. Annual revenues are low and nonrecurring, and margins are tight. VCs are looking for 80%+ gross margins and hockey stick growth.

That’s not to say you shouldn’t offer support or services. Offering a generous amount of support and services as an early-stage company is a smart way to get early customers, get close to their problems, and develop a relevant roadmap based on real customer problems. But instead of charging hourly for professional services, get early customers on subscription contracts and offer unlimited support. The customer gets access to future product releases, including requested features and functionality, and you get access to invaluable customer insight.

Professional services as a jumping-off point

Open core companies benefit from developing around an existing open source technology that presumably already has users. Offering support and services to existing users of the project is how you can start building relationships with users, onboard early customers, and get feedback for feature development.

Still, when getting started, you don’t have much to offer. The feature set is slim (if it exists), and no one knows who you are yet, so trust is low. Selling the first handful of subscriptions is incredibly hard. Any subscription service is essentially a support contract when the product doesn’t exist. The first few customers that take a chance on you are invaluable, especially if you can land a few large organizations that would benefit from your highest-paid tier later. You need to treat them right. This may look like offering a high level of support and services at a steeply discounted subscription rate.

At this stage, professional services engagement is less reactive and more of a proactive way to get closer to the customer. Learn what problems they face and incorporate them into the product later.

Transitioning from subscription-based services to a product company

It can’t be overstated how important it is that early customers start on a subscription contract rather than billing hourly for professional services. It ensures recurring revenue for you and provides a promise of goodwill to your customers that you will make the software better and better. Once you’ve improved the product to the point where you have sellable features, you don’t have to worry about transitioning early customers to a new contract, as they’re already on subscription. It’s seamless for you and them.

Set expectations with your customers about what long-term support services will look like. The customer is looking for support in the near term, but once you’ve improved the product and have legitimate features to sell, support and services should become an add-on or follow the terms set under the subscription tier. Ideally, you’ve improved the product so much that there is less need for support. Be flexible and generous with your terms with these early customers.