Be Wary of Geeks Bearing Gifts

[Repost of my Forbes Article]

For many, the words open source conjures up concepts of hippy idealism where geeks in a spirit of free love give away their work to others for nothing. For many, it’s about as anti-capitalist as you can get.

Those many are as gullible as the citizens of Ancient Troy.

Open source is one of the deadliest weapons in the arsenal of any experienced strategist. It can be used to remove barriers to entry into an opponent’s business, to encourage standardization around your practice creating a cost of transition for opponents, and it can be used to develop ecosystems to strengthen your position as part of a land grab for new sources of value or even as a source of recruitment of talent.

Whilst customers delight in the benefits that open source brings, for a vendor the successful application of an open source approach by a competitor can be fatal.

But really … are technology companies that smart?

Take Facebook’s open compute project, which in effect open sources the design of large-scale data centres. You might view this as a generous act by Facebook to encourage and enable efficiency in the hosting business. The benefits for customers and those in the business of providing data centres could be significant. Bravo, Facebook.

But wait, isn’t the ability to operate and maintain efficiently large-scale data centres a barrier to entry into Google‘s search business? Facebook wouldn’t be presenting this gift in the hope of undermining Google’s position … would it?

Take Google’s open source Android project that in effect provides device manufacturers with the software necessary to compete with Apple and IOS. You might view this as a generous act by Google.

But wait, wasn’t IOS and the devices Apple builds a threat to Google’s value chain around data? Has Google created a competing ecosystem to Apple in order to protect itself? Google wouldn’t be presenting this gift in the hope of undermining Apple’s position … would it?

There is a long list of open source projects that on the surface seem generous acts of kindness – a beautifully presented wooden horse. What are often hidden inside are the competitive machinations between companies. Open source is a deadly serious business and those who exclude this tool from their arsenal put themselves at a considerable strategic weakness.

As someone who spent several years developing strategy for the large and rapidly growing open source operating system, Ubuntu, you can bet your bottom dollar people think very carefully in these terms.

The latest arena where open source is being deployed is in the infrastructure layer of the cloud computing stack. For me, this represents a bit of personal journey … to explain I’ll start at the beginning of my involvement.

Back in 2005, I was running a subsidiary of Canon providing software systems throughout the group. I had given a talk at a conference in the previous year on the commoditization of IT activities and how our industry was changing. We were building such a system within the company and we had visions of a worldwide ‘grid’ of utility computing providers.

The idea of providing computing as a utility and the analogy to electricity dates back to Parkhill’s visionary 1966 book. Hence, this obviously wasn’t new in 2004. We understood the cycle of economic change and how once innovative activities (such as electricity or a thousand other business activities) then evolve to become ubiquitous, well defined and more like a commodity. We understood that each time this happened it caused an explosion of growth of new, higher order industries.

We were well armed, we understood the principles, we knew we didn’t need to fear the incumbents because of their inertia – but we needed an edge. It didn’t take long to find it but I’ll come to that soon.

In early 2006, we launched ‘Zimki’ – the world’s first dedicated platform as a service enabling others to build applications. Of course, we didn’t call it a platform as a service – the term hadn’t been invented back then. The service was provided as a utility and contained all the basics a platform should offer. It was designed to make it easy for anyone to build entire applications by removing all the unnecessary muck of worrying about installing machines, configuring systems and so on. You simply wrote code and launched.

The resultant speed of development was revolutionary. As Zimki grew, Amazon entered the fray with EC2 and we were joyful with the validation of the market. We looked like we had a potential but imperfectly formed winner in our small Canon subsidiary. We also had our edge – our secret weapon.

We understood that customers would have inertia through concerns over governance, transparency and lock-in. Some of these we could tackle with education but for others, we needed to remove the fear. Hence, in late 2006, we announced that we were open sourcing the entire platform. We were going to enable competitors and customers to build their own Zimki environments. We were going to create a competitive market of utility providers with an open source system at the heart of it.

One strategist told me I was “mad” to give away this advantage. However, our eyes were on bigger prizes. Yes, we would have a small piece of a larger pie but we were looking further up the value chain to capture the exchange, the assurance and the switching services that such a market creates.

We had our secret weapon, we knew the big prizes, we could deal with customer inertia by creating a competitive market, we were rapidly growing, we were a profitable company, we were at the vanguard of a new industry in early 2007 … we had everything. What could possibly go wrong?

Alas, I made a mistake and didn’t counter the internal politics and build the right sort of internal alliances. As a result, when the parent company focused on outsourcing IT, I didn’t have the political capital to counter.

Despite this failure, the game plan itself was sound. So, when I started to run Cloud strategy for Canonical (the providers of Ubuntu), my focus was on using open source to both solve lock-in issues and make a land grab whilst co-opting Amazon’s growing ecosystem.

It was this search that brought us to Eucalyptus – a start-up providing open source technology to create an equivalent of Amazon’s cloud.

Unfortunately this game is always full of twist and turns. Eucalyptus was our anointed target to dominate this space but they soon embarked on an open core route mixing both open and proprietary elements. Despite its uptake and the growth of Ubuntu, the lack of a strong open source community raised concerns.

At that time, one of my colleagues had moved to Rackspace where he was instrumental in Rackspace and NASA’s own open source play – OpenStack. Their approach was clearer – an open source equivalent of Amazon … what could go wrong?

Unfortunately, for reasons which today are still unfathomable, OpenStack appeared to focus on competing rather than co-opting what had become the de facto standard of the industry, namely the Amazon Cloud APIs of EC2 and S3.

The screw then recently turned again.

With the failure of OpenStack to capture the space combined with a new highly experienced open source CEO at Eucalyptus, there has been a flurry of recent announcements including a partnership with Amazon to ensure fidelity of Eucalyptus’ APIs with Amazon’s.

Hence, on one hand we have the EC2/S3 equivalent cloud that isn’t quite open sourced (yet), and on the other hand, the entirely open sourced cloud that isn’t quite an EC2/S3 equivalent (yet).

What a pickle.

An unkind observer would comment that Eucalyptus has built its wooden horse but debates over who pays for what whilst OpenStack can’t quite decide whether it wants a wooden horse or a wooden cow? The Trojans can sleep quite soundly.

Except, Citrix has today rolled out onto the battlefield a bright shiny wooden horse packed full of soldiers. It’s an obvious move but the point is that Citrix has now done it.

Citrix has taken CloudStack – a technology used by many companies for building infrastructure clouds – and entirely open sourced it under the Apache foundation. They’ve announced significant funding for the project and openly discussed fidelity with the Amazon EC2 and S3 APIs. They have a list of supporting companies to make you gasp.

For us customers, one way or another we’re increasingly heading towards a future of competitive utility computing markets based around open source systems providing the de facto APIs of Amazon.

Will it be CloudStack, Eucalyptus or OpenStack? That depends upon what moves they play next.

However, for competitors in this space, if you’re not wary of Geeks bearing gifts, you should be.

--- 12th June 2015

Well, the screw turned again and again. 

Eucalyptus ended up being purchased by HP and OpenStack has all the flurry and noise of victory without the install base combined with a collective prisoner dilemma. CloudStack seems to be in the long game. For the time being, AWS has walked away with the prize. 

There are potential threats to Amazon's dominance in IaaS on the horizon such as Alibaba along with other smaller environments such as Google compute engine and Azure. However, in practice we're into the long haul for open source to win back the space. We didn't have to be here but that's where we find ourselves.

The game itself has now moved up the stack into the platform space with CloudFoundry making a pretty decent open source play. Let us hope they avoid all the errors that lead to a collective prisoner dilemma (e.g. encouraging differentiation on features rather than operations) or failing to act as a decent gardener of their ecosystem (i.e. Pivotal trying to capture all the space or failing to understand the importance of others making value or failing to work effectively with others due to own interests). They've got a good team but you never know ... never underestimate the damage that some out of their depth Exec / MBA could do to a good strategic play.

Beyond platforms then confusion reigns with containers becoming the new "paradigm" shift of marketing enabling a future platform of ... oh, it's pitiful. Containers are a great subsystem but unless your goal is causing endless sprawl in enterprises then many of the approaches seem half baked and doomed to repeat the lessons of past failure.

These days I've moved on from mechanisms of strategic play (e.g. situational awareness, open source, use of ecosystems) and basic economic patterns (e.g. weak signal detection, evolution of organisations) and I'm focused on competition between nations. I occasionally take a peek at what is going on in the cloud world. It's often rather depressing to discover a breed of self proclaimed thought leaders / consultants discovering basic concepts like componentisation & inertia along with economic principles such as Jevons' paradox or punctuated equilibriums all over again. 

I'm glad I retired from cloud back in 2010 after five years. I don't think I could have coped with a constant rediscovery of existing stuff. The allure of financial riches was there (the same when I worked for a market maker on LIFFE) but I have the constant need to move on and to discover new possibilities.

The good news is we're entering a really interesting time with multiple points of industrialisation (big data, sensor as a service, robotics, currency, immersive tech, 3D printing, genetic engineering etc) looming over the next 15 years. In particular 2025-2030 is looking likely to become a peak time of wonder across multiple fields ... endless possibilities of recombination and genesis. This is all very exciting.

You never know by 2030, open source efforts in the IaaS space might have clawed back their position but most of us will be too distracted to care. We will all be dazzled by the new possibilities.

Pet Rocks of the Software Kind

[Repost of my Forbes Article]

Napoleon Bonaparte once said “Never interrupt an enemy when he’s making a mistake”. For those in the business of organizational warfare, this rule is golden.

It is one of the reasons why we are a fairly secretive bunch about the finer points of value chain evolution and the games to play – blocking strategies, choke points, positioning, barriers to entry, exploitation of ecosystems and tactical weapons such as open source. Anything that gives an advantage is secret, everything that doesn’t … well, write a book on it.

I thought I would let you in on a ‘secret’ which you already know. Most of us are spending far too much money in IT on things that don’t really matter. It is the software equivalent of paying high prices for builder’s rubble because someone called it a ‘Pet Rock’ which you could customize.

You can guess what I’m going to talk about – the suspects are already forming in your mind ... Financial Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) must be top of most people’s list.

It’s not that these things aren’t necessary; they’re an essential part of every modern business. However, it’s precisely because most businesses need them to compete that they are ubiquitous and therefore of little differential advantage. Of course, heavy customization is where we gain the advantage … or at least we are told, whilst quietly ignoring that everyone else is also doing this. It’s not that these systems didn’t at one time create a differential advantage, they did. However, this was when not every company had them, when CRM and Financial ERP were less common.

Alas, things don’t stand still. All business activities evolve from the once rare, poorly understood sources of differential advantage (genesis) to more commonplace, well-defined commodities that are simply a cost of doing business. No matter how you dress it up, a rock’s a rock and something that doesn’t differentiate doesn’t differentiate. Failing to understand this can lead to poor investment choices. I know, I’ve made a few. I’m not alone.

Two years ago, I discussed this issue with over a hundred CIOs. We examined Financial ERP and it became clear that whilst everyone was heavily involved in customizing their system, we were spending significant amounts of resource and effort doing exactly the same thing. We were chasing differential advantage that didn’t seem to exist.

We do this because as customers we don’t talk transparently enough with each other. We believe that our ‘customization’ will give us an advantage, hence we keep it ‘secret’. We’re unaware that everyone else is doing the same. How many ways can an invoice be printed? How much differential advantage can be gained through invoices? What are the odds that everyone else is ‘secretly’ working on a customization that has the ability to share, create or print invoices via an iPad?

This is where we make our mistake. When something is common there is no differential advantage, only operational efficiency. And something can be common without us realizing it, including our most cherished customizations. Of course, that doesn’t mean differential advantage can’t be created on top of these systems – that is, by moving up the value chain and creating higher order systems.
History teaches us that it wasn’t the innovation of electricity with the Parthian battery, but instead the introduction of utility electricity services by Westinghouse and Edison that changed our world. It did so by enabling higher order systems and industries to form from the telephone to radio to Hollywood to Silicon Valley … an awful lot of value built on top of a commodity. Differential value is never in underlying systems that are common and well understood. The value is in what can be created on top of these.

So why isn’t a commonplace activity like Financial ERP provided as a utility service? This is already happening to infrastructure with the likes of Amazon EC2 as well as other parts of the computing stack.
The problem is inertia. As business activities evolve from genesis to commodity, they move through three economic states:

• One of build.
• One of peace.
• One of war.

What limits that movement is inertia from customers and vendors.

In the peace state which is characterized by relative competition between vendors, the incumbents build huge cultural inertia to any change due to their own past success. As the activity becomes suitable for utility provision, it’s normally an outside player who initiates the war, a time where disruption tends to exceed sustaining change and competition becomes a fight for survival.

Think about provision of electricity as utility services, the corresponding explosions of growth of new activities (telephone to radio) and the disruption of past industries (for example, gas lamps). This pattern of evolution, from genesis to utility, from build to peace to war constantly recurs in our industrial history and we’ve no reason to suspect the pattern will stop.

In the case of computing infrastructure, which has evolved from its genesis in 1943 with the Z3 to utility services, then the outside player who initiated this ‘war’ was Amazon. A retail company not encumbered by a hosting business model is forcing the hosting industry to evolve.

But with Financial ERP, aren’t the incumbents changing? Both SAP and Oracle have cloud offerings and Microsoft has, in the last few weeks, announced it’s getting in on the act. As both Blockbuster and Kodak taught us from different industries, even if you were first into a field, this doesn’t seem to help if you can’t deal with the past industry you’ve built up. Is it likely the incumbents will truly initiate and embrace the war and disrupt their own business? Or will it be the new entrants such as NetSuite, Infor and Workday who will change the game?

The million, or should that be billion dollar question, is “who is really going to shake up this space?” An obvious candidate would use Financial ERP extensively but not be encumbered by any past business model. They would need to overcome trust barriers that enterprises adopting such a service would inevitably have, and they must have a financial interest in doing this. By interest, it could mean their existing business model is under attack and they need to move up the value chain and secure relationships with large enterprises in other ways.

I’m not convinced we’re just going to replace one set of software vendors with another because retail banking could be such a candidate. Am I seriously proposing that banks might provide utility services for Financial ERP? It sounds odd, but no more than an online retailer providing utility infrastructure. Given the potential impact of mobile banking in this sector, I wouldn’t be surprised if some move up the value chain to strengthen their relationships with enterprise customers.

So this brings us to the mistake. The question we really need to ask is whether spending on customizing and upgrading Financial ERP systems is sensible given the likelihood of a change? Doesn’t sweating existing assets makes more sense? I’m all for opponents charging ahead especially when it might involve spending vast sums where it’s not necessary. But I would be mindful that Financial ERP will evolve just like every other business activity and if everyone is doing this then it’s only a matter of time. I expect those existing models will start to be disrupted and commoditized to utility services in the next few years despite the dismissal of many.

I’m used to a world of “it’ll never happen”, “it’s too complex”, finding simple ways of happening. In a case like this, there is a good argument for procrastination.

As Napoleon also said “A revolution is an idea which has found its bayonets” … well currently utility approaches are making a charge on former hosting models. Financial ERP can’t be far behind.