Open Source Business Mechanics: Stacks versus Networks
I'm pulling together a small set of short observations about free and open source software and business mechanics. Many of these ideas came together in the essay to be published shortly by O'Reilly, and were presented in the USENIX 2005 invited talk.
One of the things that continues to bother me is everyone keeps talking about "the stack" model, as in "open source is eating it's way up the stack." I think this view is too limiting and prevents people from seeing real opportunities (and threats). It's not a stack — it's a network.
In our world, the stack is always presently like so:
This is the "classic" sort of drawing we've all come to see. And people talk about open source eating its way up the stack because they all look at Linux in the operating system layer and the onrush of JBoss and MySQL in the middleware layer, and so forth.
But the "stack" doesn't really look like this. Regular readers will know I'm a big Christensen fan. In the original book, he talks about value networks and presents a diagram of such a network (p. 39 of the 2003 softcover, ISBN 0-06-052199-6) that shows an exploded "stack" with nodes coming off the sides of each primary layer of the stack. The stack is merely an ordered walk through the network. It is really more like this diagram (with my apologies for the architectural liberties):
This is where we start to see it's not very "stack" shaped anymore. With not too much imagination you could start adding new nodes and edges and the "network" begins to get quite complex quite quickly. You could further expand nodes with soft services like training, consulting, support, and indirect products like fabrication and design tools.
So why is this a better model than a simple stack? First, it better reflects the reality in a connected market and allows people to realize the stack they see may not be the same stack their customers, partners and competitors see. (They may have a different ordering of what's important to them.) In Christensen's second book he coined the Law of Conservation of Attractive Profits (which is since renamed the Law of Conservation of Integration). His research bears out a model that when the incumbent in a market space over delivers, so begins delivering functionality faster than their customers can or will adopt it, there is generally a call for standardization, and the component players can now make money, and profitability begins to move to adjacent nodes in the network.
Moving to a network model and getting away from simple statements like "open source is eating it's way up the stack" and the disconnected observations of "open source is a services or hardware play" allows us to see a richer picture of opportunities. And if you're the incumbent, you can better see the threats.