“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?
Related posts:
“When Your Customer is Your Competitor: The Return of Roll Your Own”: http://bit.ly/5WMmT0
This comment was originally posted on Twitter
When Your Customer is Your Competitor: The Return of Roll Your Own http://bit.ly/5LHdK7
This comment was originally posted on Twitter
I know it seems obvious, but determining when to create your own tech instead of using or extending existing solutions is tough. Even tougher given the tendency of people to think their situations are unique instead of being "just like situation X with Y added."I mean, how many times (to beat a dead horse) have you seen someone say "I wrote my own framework because <insert contrived scenario that other frameworks have solved or are easily extended to solve>".
Yes, sometimes your situation is so unique you need to role your own solution. Chances are it’s your ego talking instead of common sense.
This comment was originally posted on Hacker News
When Your Customer is Your Competitor: The Return of Roll Your Own: http://bit.ly/8MT6hM Comments: http://bit.ly/7NJs9p
This comment was originally posted on Twitter
True, but then there are situations like Rails, where 37 Signals could have built their apps using existing tech, but said ‘there should be a better way’. I mean, if you told someone "I’m building this project management app, and I’m going to take an esoteric language no one knows, and write an app framework from scratch" they’d rightly tell you you’re crazy.Most endeavours that start like that end up as failures, however without these attempts tech would stagnate.
This comment was originally posted on Hacker News
If one were to set out on such a path and accomplish the goal out of hobby or desire to learn a new language, or for whatever reason, how long would something like that take? How long did it take 37s to build ROR? How long did PHP take?I’m just curious…
This comment was originally posted on Hacker News
Disclosure: I wrote the piece.But anyway, I’m still with andrewvc here. I concur that NIH – the pathology you’re describing above – is equally unproductive, and that deciding when to build or buy is a difficult question to answer.
That all being said, it seems fairly clear that due to a wide variety of factors, heterogeneity is accelerating, which makes life more difficult for general purpose, volume solutions. Think of it this way: Windows XP was, for a lot of people, a more than acceptable compute interface. But it wasn’t designed for phones, devices, tablets, and the like. And attempts to bend it to that purpose largely failed.
We need different tools for different jobs, and with the number of job increasing, sometimes there just isn’t a good tool available. At which point rolling your own is not only appropriate, but desirable.
Point being that specialization is the new norm, and as such roll your own – or at least leveraging the results of someone else’s roll your own – will become more common. IMHO, and so on.
This comment was originally posted on Hacker News
When Your Customer is Your Competitor: The Return of Roll Your Own http://bit.ly/8lBoCO
This comment was originally posted on Twitter
When Your Customer is Your Competitor: The Return of Roll Your Own – http://su.pr/1CjOBF
This comment was originally posted on Twitter