John Mark

Jan 4

Don’t Let the Tail Wag the Dog

In recent months, the debate on so-called “open source business models” has begun to rage once again, thanks to recent moves from Mongo, Redis Labs, and Confluent. Taken individually, each situation presents unique characteristics that warrant further analysis without jumping to conclusions about each entity. Taken together, however, the sum total of their individual acts presents a clear trend: movement by companies that build products on open source software towards a more proprietary approach. While each case is different, they have in essence declared that an open source approach is inadequate for generating enough revenue to yield return on investment sought by their investors. I believe that this is because the emergence of the open source business model as a distinct class pushes companies that adopt it into a narrow-banded decision matrix that presents limited options for future changes if the need to pivot arises.

To be clear, there are a variety of ways to capitalize on open source software in a commercial setting, but there is no separate open source business model, and to pursue such is to possibly limit your future success.

Open Core 1.0

In order to investigate the movement towards proprietary solutions, let’s look at how we got here. Back in the original open source hysteria of the early to mid-2000s, there was a venture community-accepted way to create open source companies, which we’ll call open core 1.0:

1. Take a successful open source project
2. Hire its core developers
3. Create a product on top of it, often proprietary
4. Convert those stubborn freeloaders into buying the better, proprietary stuff
5. Profit!

As I have pointed out previously, there are a number of reasons why this was a flawed approach. For starters, it assumed that the people using the free stuff were potential customers. It also assumed that there was no inherent value in providing the free version beyond a means to whet a potential customer’s appetite. To accomplish this, these companies would often maintain total control over the code, enforcing copyright assignment to the company so they could issue commercial licenses for the open source and proprietary code to paying customers. This approach failed spectacularly, with one notable exception: MySQL, who were basically bailed out by a desperate Sun Microsystems before turning profitable. Here are the reasons it proved an unreliable model:

• Software communities were permanently relegated to 2nd tier status and clearly not as important as the commercial products
• Communities were limited in scope to the bubble provided by the parent company, unable to develop innovative approaches independent of the parent company
• Communities were never allowed to develop an identity separate from that of the parent company.

Open core 1.0 was a great way to squelch a developer community and prevent innovation. In exchange for giving up a more open approach, these startups were supposed to be able to profit from the commercialization of the software to create a self-sustaining relationship between community and company. But a funny thing happened: by treating the community as a means of transitioning freeloaders into paying customers, these communities often withered. And because these companies had often built their entire business model around thriving, growing communities, the lack of community success translated into disappointing sales and revenue. If you were able to build up enough of a brand name and sell the company within a couple of years, you would be able to reward your investors. If you were not able to do this, you faced a tough road ahead. Investors expecting 10x were often disappointed by their open source portfolio, partially due to the fact that open source companies were judged more harshly compared to others, but also because an open source approach does seem to limit the “hockey stick” growth so often sought by investors. I would argue that hockey sticks are ephemeral and almost impossible to achieve in any situation, regardless of software license, but these people don’t listen to me, so…

Special note about MySQL: they were an outlier. They built a great freemium product before they ever became open source, and they never lost their freemium roots. This was to their advantage. Whereas other startups tried to take existing open source communities and transform them into freemium products, MySQL only open sourced its software as a means to shore up support after open source licensing started to gain steam. It didn’t have to convert its community to a freemium approach — it was always there and baked into their model. Even so, they had great difficulty converting users, but their success is an outlier nonetheless.

It’s worth noting that MongoDB began at the tail end of the open core 1.0 era, and you can see this in its basic business model. More on that later.

The Emergence of Open Core 2.0

With the spectacular failure of Open Core 1.0, new approaches emerged which were much more realistic. As I mentioned in my series “How to Make Money from Open Source Platforms”, the open core approach morphed into what I call a “hybrid approach”: using collaboratively developed, open source platforms as the basis for building largely proprietary systems management frameworks for enterprises. Cloudera is probably the best example of this, using the extensive Hadoop community as its software base, but there are many others. Apache Spark spawned Databricks. Apache Kafka spawned Confluent. One thing about these new hybrid models is that it’s difficult to ascertain which came first, the software project or the company. RedisLabs is one company attempting to hew closely to the older open core model, but they have also made an attempt to run their Redis project as independently as possible, having learned from the anti-patterns of previous efforts. Among companies still in existence and thriving, Mongo is probably the closest analog today to open core 1.0 style governance.

But many of these companies experience difficulties with respect to their business models, as can be seen from a bevy of recent licensing schemes that attempt to straddle the line between open source and proprietary. Mongo is attempting to capture users of its software by mandating that anyone creating Mongo-as-a-Service must release all code under the “Server Side Public License” (SSPL). Confluent changed the license for some of its platform components to the Confluent Community License (CCL), which prevents others from running KSQL as a service without permission from Confluent. And of course, the company that kicked off this whole controversy was RedisLabs, who changed the license for some of its Redis Plugins to add the Commons Clause, similar to the CCL, preventing unauthorized companies from using its software as a service. What leads these companies down the path of taking some of its software out of the open source ecosystem and into their own proprietary ones? I believe the decision tree is kicked off by a faulty belief in open source business models.

There is no Open Source Business Model.

Once you begin with the premise of “I need an open source business model”, it leads you down a path of “I need to monetize my project” rather than “I need to build a product that delivers value”. These may not sound very different at first glance, but it pushes you in a direction where licensing changes are a logical conclusion. Going down this path restricts your ability to pivot on your business and product goals. I believe that if you focus on creating a product that delivers value for your customers’ core use cases, the choice of license for your software will become less relevant, if not immaterial. If you haven’t read Stephen Walli’s or VM Brasseur’s takes on this subject, I highly recommend you do so, and then continue below. I also wrote a bit about why projects aren’t products and some more about building open source products (a 4-part series on “How to Make Money from Open Source Platforms”)

Got it? That was fun, yes? Ok…

The Cloudera Example

Let’s use Cloudera as a primary example. At one time, they may have begun with the premise of “let’s monetize Hadoop”. Luckily for them, because they entrusted their business to one of the smartest people in the business, Mike Olson, they very quickly went down the path of “what can we deliver of value for customers” and then built it. It’s almost quaint to remember that when Cloudera started, they were “the Hadoop company”. That is simply no longer the case. Now they’re the “Enterprise Data Cloud” with plenty of data analytics and data science-y solutions. You won’t see any messaging on cloudera.com that indicates they’re trying to “monetize Hadoop”. Or Spark. Or Kafka. Or any other open source project. Cloudera is a product and solutions company and they sell things of value to their customers, who couldn’t care less where the software comes from. You may think this is off putting or offensive to your open source sensibilities. I do not.

Let’s assume that Cloudera had decided, way back when, to continue to be “the Hadoop company”. Let’s snap our fingers and imagine that’s what Cloudera is doing today: they bought the domain hadoop.com and branded themselves as “Hadoop, Inc.” (Yes, I know: Apache Hadoop is governed by the ASF and would never allow their projects to be co-opted like this. Work with me on this hypothetical, for Pete’s sake.) In one fell swoop, Cloudera went from focusing on delivering value to its customers to also simultaneously carrying the Hadoop flag. How does this manifest itself in the decision tree for Hadoop, Inc.?

For starters, now that their success is hitched to the fortunes of the Hadoop project, they’re pretty much tied to the success or failure of Hadoop with little wiggle room for future maneuvers should Hadoop’s success flatline. It also leads to other uncomfortable questions and decisions: what happens if Hadoop is “too successful” and overshadows Hadoop, Inc? Isn’t Hadoop, Inc. incentivized to ensure that the Hadoop project isn’t easy to use? What if other companies want to build products on Hadoop? Should they pay Hadoop, Inc? What if they don’t want to or can’t afford to? Does this mean Hadoop, Inc. is now going to look askance at any “freeloader” who doesn’t pay up for enterprise products? “Aha! I’ve got it!” exclaims some newly-hired MBA. “Let’s take some of the more popular Hadoop components and make them proprietary! That way, the freeloaders will *have* to pay us!” And thus begins the cycle of pain whereby every new technology feature or project is run through the decision tree of whether this technology is “core” or “complementary” and whether is should be open source or proprietary. It is an endless cycle marked by change and regret. What was once considered “core” may become “complementary” and vice versa, resulting in stagnation and misplaced priorities, where the tail now wags the dog, with the tail being “we must monetize Hadoop”.

At this point, you may be thinking — aren’t Cloudera’s management products proprietary? Yes, they are, and I have 2 things to say about that:

1. Because there is clear separation between open source project and Cloudera product realms, there is little confusion. When creating Cloudera solutions, there’s no tiresome debate over whether it’s core and part of the open source side of the house. Everything developed for Cloudera is product space, and product managers can focus on delivering value. Done.
2. Cloudera has chosen to make its management “topping” proprietary. I would argue that it’s immaterial how the underlying software is licensed, and this is where I quibble with Mr. Olson.

The important thing about #2, above, is that it’s Cloudera’s choice to make, unencumbered by what impact it made on Hadoop. Whether they use proprietary or open source code for its management products has very little impact on the Hadoop community, a large ecosystem of developers and companies building out a number of open source projects. I can understand why business people might balk at open sourcing all the code you use, but think about it: if you’re a customer, and you need a reliable solution that just works, are you really going to task your team with piecing together a home-grown solution on which you build your business? How do I know this? There just so happens to be another company that makes its living selling open source products with management solutions built on top, and they build all of their products using open source components. And they make money. Who is this unicorn company? Red Hat. As I have said, repeatedly, no one has ever reverse engineered and reimplemented the Red Hat model. Cloudera comes close in concept, but as I’ve described, their implementation differs in important ways. Red Hat, like Cloudera, makes money by selling license subscriptions to customers who need ready-made solutions. Unlike Cloudera, Red Hat decided that all of its software would be open source, because they wanted to derive the value that comes from accelerated innovation through software collaboration, and this has not impeded them. Why? Because Red Hat understood early on, before most, that value for customers is not tied to the license of the underlying software, but rather to the inherent value of the total solutions, ie. does it actually work as promised.

The Amazon “Problem”

It’s very much en vogue these days to use Amazon and Google as examples of companies who take your open source software and build products on it without paying, but let’s get serious for a moment: Amazon and Google are not going to use your software, particularly your management software, “out of the box”, proprietary or no. They’re going to build their own management UX and UI, because they have their own particular requirements to serve their needs, and they’re going to build them using existing platform APIs. Their scalability demands are so off the charts compared to your typical enterprise customer that it would be foolhardy for the vast majority of vendors to even try to meet their requirements. This is why introducing licensing shenanigans to solve the “AWS problem” is a non-starter, a solution looking for a problem. You’re not going to resolve your own business mistakes by reverse-engineering a licensing solution to what was essentially a business model problem. Do you honestly believe that Amazon was going to use RedisLabs’ management implementations when introducing its in-memory database services? The fact is, whether you’re Mongo, RedisLabs, Confluent, or anyone else, you’re free to sell your solutions as a service to customers using any IaaS platform, including Amazon’s or Google’s. In fact, Mongo has done precisely that, and by most accounts, pretty successfully at that.

If you’re thinking about starting a company, don’t let the tail wag the dog. Start with the question “how can I deliver value for customers” and work backward from that. Then piece together the open source components you’ll need for your ultimate solutions that deliver value and construct your software supply chain. At this point, you may decide, like Red Hat, that you want the benefits of collaborative development, or you may decide, like Cloudera, that you want at least some of that to be entirely under your control. The point is you can make that choice without the baggage of “let’s monetize ‘X’”. You’ll be much happier with your choice.