The most obvious question facing an industry built on core assumptions of intrinsic software value is: how did this happen? How did an asset that has generated trillions in profits become gradually devalued? The answer to that question is complicated, but the evidence has been there for some time.
One of the most obvious factors acting as a brake on software pricing has been the wider availability of open source software. As the Encyclopedia Britannica discovered with Wikipedia, it is difficult to compete with free, even in cases where the premium product is technically superior or differentiated in a meaningful way. Likewise, proprietary software vendors have been forced to adapt to a library of open source alternatives growing by the hour.
Organizations seeking to commercialize open source software realized this, of course, and deliberately incorporated it as part of their market approach. In a 2013 piece on Pando Daily, venture capitalist Danny Rimer quotes then-MySQL CEO Mårten Mickos as saying, “The relational database market is a $9 billion a year market. I want to shrink it to $3 billion and take a third of the market.” While MySQL may not have succeeded in shrinking the market to three billion, it is interesting to note that growing usage of MySQL was concurrent with a declining ability of Oracle to sell new licenses. Which may explain both why Sun valued MySQL at one third of a $3 billion dollar market and why Oracle later acquired Sun and MySQL. The downward price pressure imposed by open source alternatives have become sufficiently visible, in fact, as to begin raising alarm bells among financial analysts.
The legacy providers of data management systems have all fallen on hard times over the last year or two, and while many are quick to dismiss legacy vendor revenue shortfalls to macroeconomic issues, we argue that these macroeconomic issues are actually accelerating a technology transition from legacy products to alternative data management systems like Hadoop and NoSQL that typically sell for dimes on the dollar.
We believe these macro issues are real, and rather than just causing delays in big deals for the legacy vendors, enterprises are struggling to control costs and are increasingly looking at lower cost solutions as alternatives to traditional products.
— Peter Goldmacher Cowen and Company
Even hardware companies are at risk. Cisco has built itself into a large systems supplier primarily on the back of its networking business; switching and routing are typically responsible for close to two thirds of the company’s revenue. For years, even as areas such as compute and to a lesser extent storage began to succumb to the onslaught of software-powered alternatives such as the public cloud, networking remained relatively immune. With the rise of software-defined networking on the horizon, however, networking giants will be forced to compete with a new breed of player, one that like Mickos before it wants to attack a large industry, shrink it, and siphon off a portion of the profits. What would this mean for Cisco specifically? According to one report, CEO John Chambers asked a few of his senior executives just this question. Their answer? A move to SDN would turn Cisco’s “$43 billion business into a $22 billion business.”
Nor is any respite in sight. What began as a trickle of open source software with the early success of the Linux, Apache, MySQL, and PHP (LAMP) stack has lately turned into a flood. The number of software categories without a viable open source choice is growing smaller by the day. As Donald Knuth recently put it in an interview:
The success of open source code is perhaps the only thing in the computer field that hasn’t surprised me during the past several decades. But it still hasn’t reached its full potential; I believe that open-source programs will begin to be completely dominant as the economy moves more and more from products towards services, and as more and more volunteers arise to improve the code.
— Donald Knuth Professor Emeritus at Stanford University
From modern technology organizations committing to open sourcing the majority of their nonstrategic codebase to companies using open source as an asymmetrical means of market competition to software developers making their solutions to various problems available to the wider world, the rapid growth of open source has forced commercial software vendors to adapt both their products and the models with which they sell them. In many cases, open source software has also impacted pricing.
So if open source is cannibalizing the commercial software markets, it’s all smooth sailing for those who commercialize open source, right? Well, not exactly. In order to monetize an otherwise free and open source software product, vendors have been forced to develop creative new business models to get buyers to pay for what they can otherwise get for free. The most common of these are described below.
The reality then for purveyors of commercial open source offerings is that while the models have been demonstrated to work, in some cases generating substantial market value, none work particularly well. Each model has limitations that act to inhibit the types of growth we have seen from the software market in years past. It’s commonly accepted, in fact, that the market will never see another Red Hat, which is to say another billion-dollar revenue entity that primarily or exclusively sells open source software. And even those responsible for open source businesses admit that open source is problematic from a business model standpoint. As Cloudera founder Mike Olson articulated in an essay for LinkedIn:
The moral of that story is that it’s pretty hard to build a successful, standalone open source company. Notably, no support- or services-only business model has ever made the cut. Red Hat, the apparent exception, isn’t: The company rode its closed-source Red Hat Network offering to dominance, effectively crushing the competition before releasing that hosted infrastructure as open source in 2008….
So here is the conundrum facing enterprise infrastructure software companies: You can no longer win with a closed-source platform, and you can’t build a successful standalone company purely on open source. [emphasis his]
— Mike Olson
If open source is challenging proprietary software companies, and also those wishing to commercialize the open source software, the real moral of the story might be that it’s pretty hard to build a successful, standalone software company, period.
In addition to the challenge of competing with software that is freely available, commercial software vendors are increasingly pitted against software that is freely consumed as a service. Certainly this was the view of then-Microsoft CTO Ray Ozzie, who as far back as 2005, had told the software-focused company that “the most important step is for each of us to internalize the transformative and disruptive potential of services.” Unfortunately for Ozzie, it wasn’t until his departure in 2010 that Microsoft appeared to be fully putting its weight behind that message with the launch of Azure.
In the early years of the last decade, vendors such as Salesforce were building traditional business applications that were not designed to be shipped to and installed at a customer’s premises, but rather hosted remotely and accessed via a browser. While the browser technology of the time had its limitations, the model’s convenience more than offset any functional issues with the platform. Over time, the browser-based delivery model became not only accepted, but the default. Even software that is installed and hosted on-premise today is more often than not consumed via a browser; native applications are increasingly rare outside of mobile.
More recently, other categories of software such as databases have been made available as services. Amazon and Google, for example, both host versions of the open source MySQL database that users may leverage via an API. Both companies also offer more specialized database services in Redshift and BigQuery, respectively. Beyond database-style services, Amazon and Google, along with a wide market of other public infrastructure providers, offer a range of compute, storage, and other software-based services.
What this means for commercial software providers then is that would-be customers are increasingly able to choose between two options: software they are responsible for selecting, purchasing, installing, customizing, integrating, deploying, and maintaining, or software they simply consume as a service. While not yet appropriate in every customer scenario, the number of problematic use cases for SaaS is growing smaller by the day. Which in turn means that the competitive pressure on standalone, on-premise software is increased, because it is inherently more difficult to consume than SaaS alternatives.
Two decades ago, businesses needing a way to persist data were most likely to turn to one of the major relational database suppliers: IBM, Microsoft, or Oracle. But as users’ demands for innovation grew, vendors were unable to keep pace. As Adam Bosworth, a former employee of Microsoft, Google, and BEA wrote in 2004:
About five years ago, I started to notice an odd thing. The products that the database vendors were building had less and less to do with what the customers wanted. This is not just an artifact of talking to enterprise customers while at BEA. Google itself (and I’d bet a lot Yahoo!, too) have similar needs to the ones Federal Express or Morgan Stanley or Ford or others described quite eloquently to me.
— Adam Bosworth
Whether driven by an inability of vendors to meet their needs, the high cost of the proprietary software, or both, the end result was that users with the means to create their own databases did so. From Google’s Dremel, Pregel, and Spanner to Facebook’s Cassandra, Hive, and Presto, an entirely new ecosystem of software was created by businesses that do not sell software. Nor was this roll-your-own trend limited to databases; Git, the distributed version control system behind GitHub, was written by Linus Torvalds to replace a commercial alternative. Rails, the popular Ruby-based software framework available on PaaS platforms like Heroku, was originally extracted from an existing SaaS product from 37Signals called Basecamp. Even companies like GE are helping to fund noncommercial software, having contributed $105 million to Pivotal, the home of projects like Cloud Foundry. The first version of the OpenStack project, meanwhile, was created using code from both NASA and Rackspace.
Not every business has the resources or capability to build software that would compare favorably to commercial alternatives, of course. But fortunately for less technically capable entities, a great deal of the software written to solve problems within an organization is subsequently released as open source software. With the exceptions of Dremel, Pregel, and Spanner—about which there are papers documenting the technology and approach—every example mentioned was released as open source software. When users are able to help other users solve technology problems with software, the attendant commercial opportunity for vendors becomes more problematic. It means either competing with free, which as discussed is enormously difficult, or attempting to monetize free by commercializing open source software, which is possible but growing more difficult.
All of which helps explain why, as we’ll see later, many commercial organizations are aggressively diversifying their revenue streams by expanding from software into services.
The biggest potential challenge for commercial software organizations, however, is the developer. As the availability of source code and services has democratized access to technology and irrevocably altered traditional procurement processes, developers have increasingly become technology kingmakers. Where technology acquisition was once the province of the CIO, today it’s the practitioner leading that process, because by the time a CIO typically hears about a project today, a majority of the technology and architectural decisions have already been made.
To be sure, this is not the first time we have seen a major shift within organizational technology buyers. As technology grew more common within enterprises, for example, responsibility for purchasing and procurement gradually moved from traditional operational elements to departments that specialized in technology usage and deployment—what we today know as IT. In more recent years, meanwhile, IT’s control of technology usage and adoption has been waning, frequently in favor of more empowered marketing departments.
But from the standpoint of a commercial software vendor, there is one key difference between developers and other organizational bodies that have controlled technology acquisition in years past: developers typically have no budget. Which means that the single most important audience from a technology adoption standpoint frequently has limited or no ability to pay for the products a commercial software vendor is offering.
Most commercial software vendors, though slow to wake up to this new reality, are beginning to move aggressively to court developer populations and update their engagement and outreach capabilities. Instead of relying strictly on an enterprise-focused sales force, armies of technical evangelists and developer engagement professionals are being unleashed on unwitting developer populations in an attempt to ensure a given software vendor’s relevance for the population most likely to be making technical decisions.
The problem facing software vendors, however, is that while recognizing the problem is indeed the first step, the solution is less than obvious. Commercial software vendors are particularly disadvantaged, because they are compelled to compete in a two-front war with both free software and software made available as a service. From a competitive standpoint, this means downward pressure on price with potentially higher costs driven by a need to compete with different models.
But as discussed, even commercial open source vendors are challenged by a market that is increasingly valuing convenience and availability over performance and features. Developers have long prized availability and speed, and while open source software is preferred, open source software that is managed by a third party possesses crucial advantages in terms of convenience.