Innovation As A Cure For The Dilemma

  • Article

Last week I hosted the guys from Redmonk, Stephen OGrady and James Governor. Other than noting Stephen’s obvious character flaw (he is a Red Sox fan) and James’s steadfast belief that the airlines will provide you with the luggage you checked through at the beginning of your flight, it was a productive day. We spent the day talking through Shared Source and open source software issues.

 

Two items came up during the day that struck me as worth thinking about more deeply. The first centered on the effects of commodity in software and Christensen’s Innovator’s Dilemma. The second had to do with Tim O'Reilly's Architecture of Participation. Due to my extreme laziness, and the length of this cab ride to the airport, I’m going to stick to the first one and get to the second a little later.

 

It has been a while since I read the Innovator’s Dilemma, and more than a year since I sat through a couple of outstanding sessions with Professor Christensen at OSBC 2004. The basic commodity argument put forward by Stephen and James was in line with what I hear often from the OSS point of view (and I certainly heard it a great deal at OSBC) as well as from Christensen. The assertion, in regard to software, is that once a basic workload has been commoditized, there's no point in trying to sell a proprietary offering for that workload. Also, as something is standardized, there inevitably will be an OSS implementation of that standard; thus, there is no compelling reason not to just adopt the open implementation. The line of logic looks something like this:

  • starting at the lowest levels of the stack (operating systems) software becomes standardized and commodity implementations become readily available
  • software companies must run as far up the "stack" as possible and enjoy the economic opportunities there while they last
  • OSS inevitably start nibbling on their toes from below with "good enough" offerings
  • the OSS offerings inexorably migrate higher and higher up the stack
  • thus, software companies necessarily morph into services companies

 

For the past year and bit, it has been bothering me that the discussion about commoditization and software has not seemed to take into account the infinite malleability of software and the role of innovation. Professor Christensen’s book uses many examples of industries where the effect of the commodity is consistent – but if memory serves, he focuses on a physical goods. Are there implications for applying this model to software, where an organization or individual can make substantial changes to the commodity and thus rapidly make it unique again?

 

Entering data into a computer seems to be a space that might qualify as commodity. Yet Microsoft has spent considerable effort investing in that exact space with the Tablet PC. The screen, pen, and software (“ink” as a data type with its own API exposed through VS.NET) are each part of the investment in a commodity space. These innovations significantly affect the value proposition of Office, which is the most often cited example of the Innovator’s Dilemma in software. 

 

I am not of the school of thought advocating that in software the answer is cut-and-run if there is an open source implementation of a software package you are offering. I think that an OSS offering places a great deal of positive pressure on a vendor to innovate and to do so rapidly, or the predicted effect of commoditization will be its fate. The need for innovation can be sated through the expenditure of sweat equity or through a buy-versus-build equation. The good news for innovators in that equation is that they get compensated for their innovations. Witness the interesting twist of IBM acquiring Gluecode – IBM didn’t “acquire” the Geronimo code base, but it did pick up the innovative expertise of the developers behind the code. (Thanks, Stephen and Matt, for your great blog entries.) 

 

I’m more than happy to be proven wrong on this, and I am most certainly not putting myself ahead of the truly industry-changing work of Professor Christensen. I’m just not convinced yet that I’ve seen the argument that says when an OSS project enters your space – evacuate. 

 

 

This posting is provided "AS IS" with no warranties, and confers no rights.