What Are Open Source Products?

1232

A lot has been written recently about open source products and services, namely the former doesn’t really exist and the latter is the exclusive way forward. As a self-proclaimed open source product expert, I have opinions and would like to share them. Firstly, the blending of enterprise software and services long predated the emergence of open source. And secondly, open source is a development model, not a business model, and it has very little actual impact on the ultimate delivery of products and services.

But first, a refresher on open source products especially as it pertains to how the open source sausage is made.

As I mentioned previously, software product is about so much more than code. Yes, the code is obviously an important component, but equally important are usability, ease of integration, management, and time to value, which I try to itemize in the graphic above. Implied as part of the total solution is product delivery and support, which would include configuration, customization and “day 2” management issues.

In many cases, internal IT teams simply don’t have the resources on hand to fully deploy a new solution and require the aid of a vendor or consultant to get the most out of a given technology. The point is, to look at a product as merely the sum total of its bits is to miss the forest for the trees; any modern generalized solution for complex problems will entail not only the bits, but also packaging, delivery, customization, et al.

This is nothing new. The idea that a software product or solution goes beyond the bits and bytes of its compiled code is about as old as software itself. Whenever I give the talk “It Was Never About Innovation,” I like to walk the audience through a thought experiment: what would change if, overnight, all the world’s software were to become open source? The answer: not much.

Complex data-driven applications that run large enterprises and require an army of consultants to configure properly would become… complex data-driven applications that run large enterprises and require an army of consultants, except now the underlying code would be open source. Big whoop — that changes very little in terms of usability and time to value. The larger point is this: the rise of open source hasn’t changed the idea of software products and solutions, which were always greater than the sum of their collective parts. The big difference is that now, with open source ubiquitous, it’s much easier to plug in multiple components and go to market that much more quickly.

Once Again: Open Source is not a Business Model

I will repeat this ad nauseum until the greater technology world begins to grasp it. Open source is a development model. It’s one way of getting a massive network effect of developers that allows companies to build a product more iteratively, responsively, and dynamically. It is not, nor has it ever been, a business model. The reason that “open source business models” have lost their shine in recent years is because there never was such a thing. This is not to say that open source can’t be an important component of product *building*, and it can be one vehicle for seeding the world with your software (but not always — see Splunk for a successful example of non-OSS “freemium” software), but it is not particularly valuable for selling a given solution.

If your product doesn’t add value for the customer, they’re not going to buy it, regardless of its anti-lock-in properties. Customers these days don’t want vendor lock-in, which drives them to open source solutions, but they buy products that solve their problems. Open source becomes the third or fourth bullet in a sales deck as a suggestion that the product is based on software that may be more easily replaced. Any higher than that, and you have problems with your product or explaining its value.

The reason Red Hat makes money is because they are able to take a collection of open source software, package it together in such a way as to reduce complexity for IT shops, and sell the whole solution. This is not any different from many other software vendors who do pretty much the same thing. The fallacy in asking the question, “How does Red Hat make money?” is that it implies that Red Hat’s value proposition is that much different from other vendors. Their ability to package and sell is only tangentially related to their open source bona fides, but their ability to build a product and quickly add value, on the other hand, has *everything* to do with open source. This is the difference.

While Red Hat is the only profitable “pure play” open source software vendor, we really need to expand what we mean by “open source vendor.” By everyone’s count, open source is packaged with software products all the time. EMC, for example, uses all kinds of open source software with its products and also makes lots of software contributions to OpenStack and other major open source communities. Does that make EMC an open source product company? What about Microsoft, which has also started to bundle in open source components with its products and services, especially with Azure.

What, exactly, constitutes an open source product company? It’s an open question, and my sense is that every vendor, if not already, will very soon become an open source product company. To suggest that Red Hat is the only successful open source product company is to ignore all the changes that have been taking place in the world of software products and to apply far too narrow a standard.

Back to the “Death of Infrastructure Software”

Which brings me back to Boris Renski’s claim that “infrastructure software is dead,” by which he means open source is about services and support, not product. To which I would ask, what movie has Boris been watching? By his own argument, infrastructure software has been dead for years, because services and support are baked into the enterprise software model. To suggest that we are in a new age of services and support is to ignore everything that has taken place in the IT realm for the past 25 to 35 years. This is not to say that he’s wrong, per se — just that he’s a little late to the party.

One of the great innovations in software licensing, the software subscription model, became popular for primarily two reasons: it became an OpEx line item, as opposed to CapEx, and it lumped together software, services and support, instead of breaking them out individually, greatly simplifying the process of acquiring various solutions and accurately predicting their impact on future budgets. The rise of software subscriptions is an implicit recognition of the reality: that software and services are forever intertwined.

Don’t think of them as separate items. To do so as a vendor is to risk losing your value prop to customers, and to do so as a customer is to risk missing out on innovations that will improve your company’s efficiency.