“Years ago it occurred to me that Amazon.com was a software company. That’s not news to anybody any more now that they’ve turned pieces of their infrastructure into cloud computing products that they lease out, but I realized it long before Amazon announced their Web services products, and even before they started outsourcing their online store and logistics to other retailers like Borders and Toys R Us. Early on, Amazon was thought of as a retailer, but their retail strategy was based on building the best software for running an online retailer. My guess is that Amazon.com knew from the beginning that they were in the software business, but a lot of companies that expend a large share of their resources building software don’t.”
– Rafe Colburn, “Do you want to be in the software business?”
James and I tend to agree: Amazon is, in fact, a technology vendor. Even if you don’t subscribe to that idea, you should be planning as if they are. Because the evidence is mounting that the software vendors are facing a powerful new market competitor: their customers.
Why do you think Facebook would sponsor the Apache Foundation? Because, like Amazon, they’re in the business of producing software. Software like Cassandra. Why does Google run developer events at Moscone? Because they’re in the software business. Why is Yahoo the largest single committer to Hadoop? Because…well, you can see where I’m going with this.
The mainstream technology industry has, in recent years, eschewed specialization. Virtual appliances, each running a version of the operating system customized for an application or purpose, have entirely failed to dent the sales of general purpose alternatives such as RHEL or Windows. For better than twenty years, the answer to any application data persistence requirement has meant one thing: a relational database. If you were talking about enterprise application development, you were talking about Java. And so on.
The result is an effectively homogenous set of technologies upon which ran the majority of workloads.
A homogenous set of technologies that has largely been rejected by the businesses that have built themselves, in the last decade, on the web. That can, as Tim Bray puts it, “deploy better systems at less cost in less time at lower risk than we see in the Enterprise.”
Why? Because the general purpose stack wasn’t what they needed. From either the technology or cost perspectives. As Cloudera’s Jeff Hammerbacher related to Curt Monash, Hadoop enjoyed advantages over commercial relational alternatives for Facebook, from price to schema flexibility.
Nor is software production solely the province of the Web 2.0 giants: Ruby on Rails came out of 37Signals’ Basecamp, a Software-as-a-Service project management tool. Django? Extracted From the Lawrence Journal-World’s website. Crane? Derived from Flightcaster. Git? Written by Linus Torvalds to manage the Linux kernel tree.
None of this software, of course, would be all that interesting except for one important change: this in-house developed code is open source, and shared with others. Which has led to entirely new – and entirely unanticipated – business models. Or maybe you saw Github coming.
“Roll your own” as a software development approach isn’t new; if anything, it’s the original software development process. In days of yore when you wanted something built, you built it yourself. And fiercely guarded that code, because it could be, someday, even if you didn’t know how or why, a “competitive advantage.”
Eventually, of course, enterprises looked around and noticed that pretty much everyone had a customer relationship management system, or an enterprise resource planning system, so the opportunity for competitive advantage in general purpose – as opposed to, say, high volume trading – applications was increasingly slight. So why bother? Run on the same infrastructure as everyone else and get on with the more important things like running your business. Does IT Matter? et cetera, et cetera.
And so things went for a time: vendors built out extensive businesses and revenue structures around general purpose enterprise software, and customers bought into them in a big way. Even if, in many cases, the software wasn’t a great fit. The perceived risks to introducing new, unproven technology were greater than the pain of adapting general purpose software to the tasks at hand, so the equation favored the incumbents.
Until the last few years, when more accessible languages, cheaper hardware, and a growing catalog of open source software assets led firms small and large to question the status quo. To decide, on a volume basis, that the available frameworks, development tools, databases, operating systems, and so on weren’t quite right for their needs, and that rolling their own was preferable. And that, once built, they could amortize the costs of developing these assets if they made them publicly available. Which has led to Rackspace contributing to Facebook’s Cassandra, Facebook contributing to Yahoo’s Hadoop, and IBM contributing to all of the above. The days of rolling your own are back for some portion of the would-be enterprise software customers, if not for the same reasons as in the past. Many enterprises will lack the necessary skills to build their own Hadoop, obviously, but thanks to that project’s developers they don’t have to. Some will argue that the likes of Facebook and Google can’t be counted as potential enterprise software customers, because they were never likely to buy from traditional providers in the first place. I would respond that this is precisely the point. Having participated in the infrastructure build out of a lot of startups as a systems integrator from 2000-2003 or so, I can tell you that those I worked with overwhelmingly preferred the standard at-the-time enterprise infrastructure of BEA, Oracle, and Solaris. These days? Well, let’s just say that startups are making different choices.
Think about it. How many of the really interesting technologies of the last few years are the product of companies that primarily sell software? Which, in turn, begs the question: if the interesting code is not coming from the software vendors, what is a “software company?” My own view is simple: you are not a software company because you sell software, you are a software company because you build software. Which means, of course, that the field of “software companies” is much wider than is commonly realized. From which we may, in turn, conclude that the software competitive landscape is that much fiercer, because vendors are typically designed to compete with other vendors – not customers designing software for other customers.
In other words, you may want to consider Rafe’s original question very carefully: Do you want to be in the software business?
