A few years ago I was at a presentation at the Open Source Business Conference listening to an idiot. He compared people who supported various open source models to babies and derided “catering to developer preferences.” I don’t remember who he was but everything he said is wrong. Here’s why.
As the migration to the public cloud completes, eventually the number of transactions and thus operations executed in the public cloud will stagnate. Once that happens each technology vendor’s share of those operations and ultimately revenue will be a function tied directly to (drum roll please) developer preferences.
We can see this modeled in the web. The number of hits a popular website gets was growing as a function of the number of people on the Internet growing regardless of its increase in popularity. Once nearly everyone is online that changes. As the growth of Internet usage starts looking more like population growth in developed and developing countries, you see traffic stagnate.
You can see evidence of this on Netcraft or in the app market — as one product becomes popular the category becomes locked to new entries. The rise of Instagram means effectively no more Flickr. Even Google couldn’t make Google+ work. Ultimately everyone competes for a share of the existing traffic.
Slicing up the cloud pie
So developers are the people who generally make the technology choices. You may say “well the architect chooses” but over time developers decide. Architects would be wise not to choose technologies that turn off developers but it seems like it happens frequently. However, in the long run, this tends to backfire. The company can’t recruit, a project fails, that architect loses their job, and different choices are made.
You can argue that the second most hated database is the most widely used database, but what does its growth look like? DB2, the (rightly) most hated database, has been declining in market share for years.
Developers also generally make really rational short-term decisions that eventually add up to long-term trends. How many times have you tried to use something and within 5 or 20 minutes realized it was too frustrating and just picked its closest competitor because you could get it working quickly?
If developers make technology decisions over the long term and apps are written by developers and deployed to the cloud, then who decides cloud winners and losers? I’m not talking about Amazon vs. Google vs. Microsoft, because ultimately providers will be decided based on cost and reach. And who really cares anyhow? I’m talking about everything above that layer. (Where Amazon, Google, and Microsoft compete not with each other really but with third-party software vendors.)
While the cloud is currently charged to customers on the basis of a weird hybrid of time and utilization, let’s assume that if we reach efficiency those are all just a proxy for operations. Meaning let’s say I pay some fraction of a penny for every database write, every HTTP hit, and every API call. If public cloud migration becomes relatively complete in a few years (as trends suggest), eventually the number of operations and fractions of pennies will stagnate or align with population growth in relatively affluent countries.
Up until now, long-term increases in cloud usage have been driven by new technology and more people connecting. However, sooner or later, we face inevitable stagnation. Even with the Internet of Things, after every factory that is being automated is automated and everyone has a Ring, a Nest, and an Alexa along with that Internet-connected dishwasher—there will be effectively stagnant growth in cloud operations.
What developers want
Once the number of operations plateaus then developer preferences will decide which vendors or open source tools get the biggest shares of cloud spend. This means that if most developers decide they like Spring, then VMware should do well.
There is a catch, of course. Developers like open source tools and technologies. Amazon and Google and Microsoft like open source tools too—especially if they can use them to capture that ultimate spend. So while developers will decide the type of those ops (i.e. a Spring API call), it may be IT operations that decides which implementation of Spring will be used (assuming perfect compatibility can be achieved). That implementation might come from VMware, or from one of the cloud providers, or from somebody else.
In short, vendors should spend most of their time catering to developer preferences and the rest of the time ensuring their “as a service” is the best implementation. Developers love open source. So if you want them to use your software, you should probably be providing it as open source.