Open source software is the rule in IT infrastructure automation. But what business models do companies like us apply, and how do these affect product decisions and open source users? The so called “open core” model is common, but we believe it introduces schizophrenia, as Chef just announced they do too. This post will explain why, present our own business model and help you understand why this may change a lot of things.
Here at Normation, we are strong free software advocates and most of us have dedicated many years of our lives to open source software projects, companies and evangelism. As a company we also had to figure out how to make money from our activity. Therefore, open source business models are part of our daily thoughts.
The configuration management space is one of the most active and innovative domains in IT at the moment (arguably – ok, let’s say “cloud” and “big data” trump “devops” for buzz word status, but hey…). The main players – CFEngine, Puppet, Chef, Ansible, Salt – and of course ourselves with Rudder are all open source, but their business models vary.
Chef’s recent announcement to go “true open source” is the sign of big changes starting to happen in our market. We chose this approach from day 1, so naturally we’re very enthusiastic that Chef have made this choice, and applaud them for it. Let us explain why.
Open source business models
Let’s start with a quick recap of common models that enable companies to monetize open source software they work on:
- Services: This is the original open source model – all software is free and companies charge for services such as consulting, training or support. This is equivalent to getting a new tire for free and paying someone to fit it on your car’s wheel. PostgreSQL is a good example of success around this model.
- Open core: This involves two distinct products, one open source and one that is sold exactly like traditional, licensed software. Usually these two products are built on the same code base, and are commonly called “Community” and “Enterprise” or “Pro” versions. MySQL was a good example of this model.
- Convenience bonus: In this model, all source code remains free, but the companies sell a service to help users out such as an easy-to-install version, productivity boost, etc. The inventor and biggest example of this is Red Hat – their operating system is completely open source but they sell a compiled version of it.
- Platform for addons: This model involves the software being free and becoming mature and stable enough to become a platform for extra features and services. These extras, such as plugins, themes, widgets, etc can be sold or distributed as more open source components. A great example of this is WordPress, and it’s thriving ecosystem that builds, gives away and sells themes, plugins, bundles, etc.
There are a couple of other alternative approaches that I haven’t listed here, because they are not purely about software. In particular, hardware vendors and SaaS companies often publish all or part of their source code under an open source license, while selling their main offering. This is a business model that works well for them, but is not strictly speaking about the software.
Many commercial offerings end up mixing parts of these models together. For example, Red Hat sells a subscription that bundles a convenience bonus (#3) – the compiled OS – with a services subscription (#4) – support. Arguably, bundling these together probably increases sales for them – but now we’re talking marketing tactics.
Open source is essential in IT infrastructure
Our domain, IT infrastructure, has two particularities with regards to open source software:
- This domain is where it initially started to thrive, so a lot of infrastructure is already using high percentages of free software, and the people involved in building it know the ropes.
- Software in this domain can so easily break production systems, causing terrible damage (reputation loss, business loss, or worse, physical disaster). Therefore, nothing matters more than software being reliable, stable and providing the freedom to build awesome services on. That’s where the essential freedoms of open source come in.
Open source software in infrastructure enables so much more than developers just letting some folk use it for free. It really is a foundation for innovation and nurturing new ecosystems. Would the idea of cloud computing have appeared if OSes and good virtualization software weren’t available to use and change freely? Maybe, but it would certainly not have come as early and be as widespread. In this sense, open source is already a game changer in IT.
These reasons explain why more and more companies building software for IT infrastructure now choose to distribute it as open source software. Looking at infrastructure automation tools, every single one of the main contenders – CFEngine, Puppet, Chef, Ansible, Salt – and of course ourselves distribute all or part of their software under an open source licence.
But these companies still need to make money, thus the discussion on open source business models. And this is where is gets interesting…
Open core’s schizophrenia is toxic to free software
The open core model involves publishing an open source version (often called “Community”, or just the product’s name) and selling a proprietary, non-free version (often called “Enterprise”).
The problem with this is that it divides everything into two separate entities, but the same people need to work in both. This brings all sorts of questions that just add overhead to what should be simple:
- What version should new users use?
- Developers need to add features and fix bugs, but which version do they do that in?
- Should the company help out people not using the Enterprise version, even though they’re not paying customers?
- Wouldn’t it help the business to add some limitations or remove features from the open source version, to encourage sales of the Enterprise version?
- Partners want to build a business on the open source version, and grow a community and customer base around the product, but wouldn’t that actually hurt Enterprise sales?
I have often heard the argument that this isn’t as drastic as it sounds because the Enterprise version is actually built using the Community version, so improvements and bug fixes in Community help Enterprise. But that’s just about code, and a long way from solving all of these problems.
As Chef’s Adam Jacob explained so well:
With Open Source Chef and Enterprise Chef being different products, there was a natural tension between which one would be getting attention at any given moment in time. Do we always ship them at the same time? Which gets priority for security releases? Which features go in where?
In short, the open core model simply aligns a company’s focus on their Enterprise product – that is what makes them money. The open source product is no longer their priority, and nor are it’s users. The company may choose to keep improving their open source version, but don’t get fooled, someone high up in that company is going to be worrying that it’s taking focus away from the “real” business or, worse still, decreasing the value proposition of the Enterprise product. Everything becomes schizophrenic: “am I working for the open source version or the Enterprise version?”
Oh, and let’s think back for a second, why is it important for these tools to be open source? Ah yes: Reliability. Stability. Freedom. Now, let’s ask ourselves: if a software company is focusing on their Enterprise (non-free) product, is it in their interest to focus on these promises for the people using the open source version?
Normation’s model
These limitations of the open core model have caused businesses to think outside the box, and imagine other, better, ways to make a living around open source software. Models #3 and #4 (as described above) come from that thought process.
Obviously, you’ll have gathered that here at Normation, we didn’t build our business on open core. We put a lot of thought into our business model, and strived to make it as true to open source as possible. Like many, it is a mixture of several of these models, but strongly leaning towards #4 – a platform for addons.
We develop Rudder, our infrastructure automation tool focused on ease of use and compliance, as an open source project. Our business offering includes:
- Support: Remotely helping users with incidents (urgent, “help me now!”), and providing expertise on demand (advice, “how is it best to do this?”).
- Platform support for Windows and AIX: Rudder’s agent can run on almost any operating system. Packages for most GNU/Linux distributions are freely available (BSD and Android coming soon!), and it can be compiled manually on other operating systems. As a convenience, we sell pre-built packages for these proprietary platforms.
- Advanced reporting plugin: Plugins can extend Rudder’s base functionality and can be either open source or proprietary (this is up to the plugin author). Normation built and sells a report generator to display KPIs as pretty graphs and statistics.
- Sponsored development: Often enough, users ask us to implement features they really want. We plan a lot of features in our roadmap, but give the chance to sponsor a feature, in order to get it implemented faster. We sell sponsoring at 50% of the estimated development price, so long as the developed feature becomes open source.
- Services: We also offer traditional services such as consulting and training.
We designed our business model back in 2011, and are very pleased with it. Customers find it fair, and open source enthusiasts congratulate us on it.
So far, this model has shown only benefits. It is sustainable, and scalable, thanks to several offerings based on recurring subscriptions (support, platform support and plugins). It’s designed to avoid any possibility of the tension resulting from an open core model – with just one main product to improve, every sale contributes to continuously improving Rudder as a platform for us and our partners to build business on top of.
You may also have noticed a theme regarding the addons we sell. They are all targeted either for proprietary platforms (where open source is not the de-facto standard) or as a productivity boost (our reporting plugin is a pretty layout for some graphs built from simple SQL requests – any engineer could rebuild it, given the time). They are effectively all convenience bonuses (see business model #3 above). Having a clear line as to what becomes a for-pay feature and what goes in the main open source platform makes a huge difference: no schizophrenia.
Last but not least, sponsored development is a great way for customers to contribute without writing code. Everything we sell helps fund R&D, but this gives us more: really good insight about what features customers really care about.
Welcome to the club, Chef!
I’ve been meaning to write about our open source business model for a while, but what really sparked me into doing this now was the news that Chef was moving to a similar model to ours, earlier this week. We really think that they have made the right move, and I anticipate this question will soon be a game changer for software companies in the infrastructure automation space.
So: a warm welcome to the beautiful world of true open source, Chef!
By the way, I also proposed a talk on this topic at the upcoming special devopsdays 5-year anniversary event in October: “Why open source is to free software what automation is to devops”.
In case you had any doubts after reading this far, open source isn’t just a business model to us. We really believe that true free software is the way forward for our industry. We have been working with non-profit organisations promoting free software here in France to better understand the ecosystem and its business models, and help share these ideas, such as AFUL and Systematic’s free software working group (GTLL), which Normation is a business member of.
