Innovation As A Cure For The Dilemma

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.

Comments (5)
  1. ok – this time you will get a response! see later

  2. tecosystems says:

    As Jason discusses here and I’ve mentioned before, he was kind enough to have us out to Redmond last week for a set of conversations on topics relating to open source. Contrary to what a lot of people might believe,…

  3. Brian says:

    Your logic makes sense to me, and I might add two points. First, Christensen’s model is valid only for a specific set of industries and conditions. His notion of “good enough” is relative. By his logic, commodity mp3 players from Dell, etc. should be good enough to dethrone the iPod, but the exact opposite is happening.

    Second, the nature of innovation is much broader than Christensen or OSS advocates allow. Innovation is not what you do to your product; it is what you do for your customer. Companies that focus on product innovation have the most to fear from OSS. Companies that focus on raising their customers to the next level can out-innovate OSS from here to Sunday, and have nothing to fear. If you innovate on customer context, OSS can never catch up (unless they’re already ahead, of course.)

    PS: found your site via the always valuable Tecosystems . . .

  4. So RedMonk been conversing with Jason Matusow recently about open and shared source and the changing nature of software industry business models. Today meanwhile i met with Byron and Cornelius from SourceLabs. Those two guys are definitely going to make…

Comments are closed.

Skip to main content