John Mark Walker is the Open Source Ecosystems Manager at Red Hat.
Disclaimer
I am a Red Hat employee, however, I do not speak for the company. My thoughts in this series stem from a long career involved in a number of open source companies and communities.
Back to Open Source Platforms…
In the previous article, I was explaining how the open core business model worked (or didn’t) and how the industry has progressed to hybrid models that still smell “open core”-y. I admit that many of these models are still evolving and, while I don’t have definitive answers, I can speak from experience about several aspects of them.
Services and Support
One thing I noticed in the commentary on the first and second articles was some discussion around offering services and support for Open Source code. Because I titled this series “How to Make Money from Open Source Platforms” it is noticeable that I have refrained from touching that particular model. And it’s true: quite a number of companies offer services and support around open source technologies, either as an adjunct offering to complement their products, or as their primary source of revenue. There are a few reasons why I chose not to emphasize this particular model:
-
It doesn’t scale. I wanted to restrict the subject matter to ambitious business models that could, eventually, grow into a global scale. Services and support don’t necessarily prevent that, but it becomes much more difficult. If you have money to burn, scaling out such an operation is feasible. If you don’t, it’s pretty much impossible.
-
Investors don’t like it. See bullet point above. As much as I have a love-hate relationship with the VC community, I can see their point in not investing in services and support companies. Investors want companies that will give them a significant return on their investment, and building a services company is a long slog – longer than with software products.
-
Mom and Pop. If you want to create a viable business with a couple of people and not much more, and you have some runway before you have to turn a profit, a services model is great, especially if your team has sought-after skills that aren’t very commonplace. For anything more than that, you need to seriously think about how you can grow this model or whether it’s a good idea. Unless of course, you’re simply using your services cash flow to fund product development, which is a strategy that can work for startups before they’ve signed their first term sheet.
So yes, there are quite a number of companies using business models not explored here in depth that make money, but for a variety of reasons aren’t particularly interesting to me. The focus here is on product. Specifically, that one can make a profit on open source products, which is something that seems to be in doubt. In fact, there are some who think that services and support are the *only* way to build a business on open source software, and this series is an active attempt to counter that line of argument.
Open Source Platform Value
What is the value of an open source platform? Would someone ever pay for it outright? Indeed, how does someone use an open source platform? Let’s start with the oldest and most significant of open source platforms, Linux. For the longest time, Linux was dismissed as a non-viable data center technology for “enterprise-grade” or “business critical” operations because it had no support model, no applications that ran on it and no obvious way to make money from it. How, then, did Linux become the engine that fueled the growth of the world’s open source ecosystem, an ecosystem that could be valued in the trillions of dollars, when calculating the percentage of the world’s economy that relies on open source systems? Was it just a bunch of hippies sharing the software and singing about it, or were there clear business reasons paving the way to its eventual victory?
If we flash back to 1999 or 2000, it’s sometimes difficult to remember that Linux was, while ascendant, very limited and not the runaway juggernaut we know of today. There were many Linux distributions that packaged Linux for end users, but none of them could boast of a product that made any substantial money. They were mostly packaged in boxed sets and distributed through big box stores, unless you were lucky enough to have a big enough internet connection to download your own copy. The idea of subscription-based enterprise software had not yet landed, and the only business model that most people understood for open source software was product support and services, neither of which were particularly easy to scale, especially for startup companies with limited resources.
It is in this context that we examine how some enterprise-class open source products started to make headway and achieve something resembling success. How did this happen? One thing is clear, the successful open source products never ever discount the intrinsic value of a scalable, world-class, reliable open source platform. Open source software may be usable, or it may not, but it’s open source bona fides have nothing to do with its usability. Or consistency. Or reliability. Or manageability. And most enterprises have a different view of “usable” from your average computer enthusiast or hobbyist. For an enterprise, “usable” means being able to achieve scale without having to resort to a whole lot of customization or private consulting. It should “just work” and fit neatly within an enterprise’s existing workflow. Simply releasing the source code of an open source project does not imply any kind of guarantee of usability. Sure, enterprises can throw resources into making an open source project work for them, or they can pay someone who’s already created a product that can do that more quickly.
Open Source: It’s About Way More than Code
This brings us to the most important question regarding open source products: how do you differentiate between the code that’s available to everyone and a product derived from that code. This is the part that everyone gets hung up on and often leads to poor decisions. After all, if everyone has the code, then they have access to everything they need to run it, right? Thus obviating the need for a product? Not necessarily. Creating a product is a messy, messy business. There are multiple layers of QA, QE, and UX/UI design that, after years of effort, may result in something that somewhat resembles a usable product.
What the hybrid approach mentioned previously gets right about open source is that you can’t inject artificial limitations on an open source project and expect it to grow into an ecosystem. What it gets wrong, however, is the assumption that no one will pay for the base platform. A vendor with this approach assumes that anyone can install the platform on their own and will never need to pay for it. This is simply false. Getting a platform that is certified against an array of complementary technologies, software components, and hardware takes significant time and effort. Any enterprise that values its IT systems and any independent software vendor that wants to make sure its applications work with the platform will gladly choose the certified solution that fits their needs. (Yes, I know, there are a significant number of organizations that choose un-certified goods. More on them later.) As most IT folks know, the cost of software acquisition, proprietary or open source, is far less than the total cost of operation over time. Thus, if paying some more upfront means reducing the TCO over time, that’s a trade any CIO will gladly make.
(At the risk of losing readers here, the accounting calculations around software amortization are in the favor of upfront costs and then deducting the declining value of the software over time as a “loss”, whereas paying for continuing services over the years will track wage increases over time and cannot be amortized. Thus, some upfront costs with lower TCO makes sense for the bean counters out there, which is a point in favor of purchasing open source products, not necessarily services. Unfortunately, annual renewal fees may muddy this calculation, although I bet that the TCO aspect is still in favor of products, not services, even with annual renewals. Can you tell I married a CPA?)
So how do you know if you’re using the particular brand of open source software that is certified for your infrastructure? After all, if it’s open source code, then anyone can change it at any time, and you never know what you’re getting, right? Actually, that’s not true at all, and is one of the great myths of open source software. This is where copyright and trademark law come into play, and any smart open source vendor knows how to leverage the tools of intellectual property law to their advantage.
Let’s imagine you have open source project “foo” and you want to transform your highly successful open source project into a software business. You’ve looked at building services around support and customization, but frankly you have higher ambitions than a mom & pop software services and support business. No, you want the big enchilada and are obsessed with changing the world. How do you sell a commercial version of this without resorting to the open core or hybrid approaches, because of their inherent deficiencies?
If you take “foo”, devote many man-hours to polishing the software, and then create this splendid unicorn, how do you sell it in a way that connotes its value above and beyond the open source project? Do you call it “foo supreme” “foo super” or just “foo enterprise”? Think about this very, very carefully. You’ve spent much time, resources and money making “foo” into something most enterprises can use. If you call the product something that evokes the name “foo”, what are you saying? Someone might get the impression that it’s really just “foo” with some extra naming thrown in but not much else. Does the name “foo ___” confer the effort undertaken to make sure it works cleanly? This has been the great undoing for many open source vendors, from MySQL Enterprise to Hyperic Enterprise Edition and on and on. It also leads to the impression that just plain “Foo” is somehow crippled or otherwise less valued. Remember, you want your open source project and community to be highly valued, otherwise you lose the benefit of an open source strategy and fall back to the problems with open core.
Imagine an alternative scenario. You know that “Foo” is world class software, and you have a really large user and developer base. Now, instead of calling it “Foo X” let’s just call it “Bar”. What now? By naming it “Bar” you’ve now created an entire namespace reserved for your commercial efforts. There’s no more confusion in the market around what is paid for and what is free. The user and developer communities that either aren’t ready to buy a product yet or never will know that “Foo” is a dynamic open source community with a product that will satisfy their needs. Your prospective customers, the guys who just want something that works, know that they want to check out “Bar” – because that’s the thing they’re looking for.
Every day, thousands upon thousands of enterprises are just looking for a product that works – why not give it to them? Perhaps they don’t care if it’s open source, because they’re simply looking for value from their software vendors. They won’t get confused by the name “Foo” because it’s either outside of their day-to-day work, or if they do know about it, they want the certified thing that they know provides a reasonable guarantee about how well it will work in practice. It also helps that the only way to get “Bar” – the certified thing that’s been tested against a wide array of different technologies – can only be obtained through entering into a commercial contract.
This is where protecting your trademark is essential. You are the one who creates the strategy for “Bar”, you’re the one who invests hours into quality assurance and testing, and you’re the one who’s taking on the risk by making a substantial investment in the product. Therefore, you are the only one who gets to create a product called “Bar”, assuming, of course, that you took the time to register the mark in the first place. It’s equally important to protect the mark of the open source platform, Foo. The last thing you want is some other company claiming that their version of “Foo” is “just like ‘Bar’”! Thus, it’s important that whoever controls the mark for “Foo”, whether it’s a software vendor or a vendor-neutral organization, also engages in vigorous defense of the trademarks.
Secrets to Open Source Products
Creating, marketing and selling a product is no different in the open source space from any other endeavor. What trips up many software vendors is that they *think* it’s much different, and because of that are led down a path of landmines and less successful strategies.
Considering the previous section about trademarks and namespace, is it really just about the name? Well, yes and no. Calling a product by a different name can be an important step that leads you in the right direction. After the decision to name your product something else from the open source platform, you invariably face a cascade of ramifications that force you to think about product development in a more positive manner, instead of simply thinking defensively about how to prevent your open source project from becoming “too successful.” After naming a product, you need to develop tools specific to your product name, including branding, documentation, etc. You’ll need to facilitate a community around your product, because you don’t want to give your customer community the idea that all they need to do is consult with your open source users. (While helpful, you need your customers to buy into the notion that you, not the volunteer community, are the final word on your product.).
And then you face the decision of what to do with the code itself. If you’re taking code from an open source project, don’t you have to release that code as open source? In many cases, yes, but that shouldn’t affect your product strategy. By all means, *do* release all of your source code, especially the bugs you find from your top-class QA and certification infrastructure. While you may release all of your source code, that doesn’t mean you have to release your full test plans, or your QA strategies, or your particular continuous integration suite, or anything else.
And that is the big secret of open source: It’s about way more than the code. In order to build a certified, predictable, manageable product that “just works”, it requires a lot more effort than just writing good code, although that is the starting point. You’re not just testing your code, rather you are testing how well your code integrates with the vast array of components that enterprises are forced to face down on a daily basis. You can release all the code you want, and you don’t have to worry about competitors “stealing” your productization process. Some may try, but if they’re capable of that, then frankly, they’re probably better equipped to sell an open source product in the first place (although nobody likes to hear that).
In the next (and final) part of this series, I’ll go into more detail about the process of differentiating your product from the project(s) you rely on, and how users (freeloaders) of the open source code are actually an essential part of your product-building strategy.
Read more:
Part One: How to Make Money from Open Source Platforms
How to Make Money from Open Source Platforms, Part 2: Open Core vs. Hybrid Business Models
