Stephen O’Grady posted a great response to my earlier posting on integration issues for OSS projects. (There are also a few strong comments to his posting as well.) Apparently, I should have bought a beer or two for Stephen at OSCON rather than a bad piece of pizza. Live an learn.
I like his arguments a great deal, and I would say the most important place where we would agree is about trade-offs. Imagine a line with two end-points, the first of which is perfect componentization and the other complete integration. No organization would want to a) produce or b) consume software that was at either extreme of the spectrum. The real question is where along that line do you want to be? I think the answer for this is going to be very different for the producers of software compared to the consumers of the same.
“My most obvious pushback would be with the alternative, in this case integrated innovation. It’s no secret that I’m skeptical of the benefits of integrated innovation, which in my view increasingly trade customer convenience for the inability to substitute alternative components and product cycle time.”
A lucid statment regrading the trade-offs in the integration spectrum. Yet I think there are some elements that may need teasing out a bit more. When Stephen speaks about “customer convenience” I think he is missing the more important concept of “cost to the customer” of both money and manpower. But, he is right in that customer’s also have very valid reasons for maintaining choice and the ability to alternate components (for both functional and purchasing power reasons). So we are back to the trade-off. I believe that the long-term costs for organizations that take on more of the integration burden in order to maintain flexiblity become prohibitive.
Stephen went on to say:
“…open source by its nature creates an economic opportunity for third parties interested in addressing the needs of customers demanding tighter integration of the various components, an additional level of comfort, support, etc”
And thus Optaros, SpikeSource, SourceLabs, OpenLogic etc. have a market opportunity. Their value-add is that they drive down the integration burden for a fee – as long as their fee remains some fraction of the overall costs they are seeking to aleviate. But this is where Stephen’s point does not add up for me. If all of these commercial players put in place binary use and/or support agreements that limit flexiblity, is the customer not losing the very choice they were looking to foster? I don’t want this posting to become a rehash of the “vendor lock-in” discussion, but it is clearly a factor in this discussion. A source code license is only one layer among many in which a vendor may choose to provide compelling reasons to stay with their technology or service.
So Stephen then asks a really hard, but worthwhile question of Microsoft:
“If we accept as above that open source can in fact integrate – if not to the extent that Microsoft can – I think it’s interesting to examine whether or not the reverse is true: can Microsoft decouple?”
Decoupling can take many forms (Wonder Twin powers–activate! Form of a layer of abstraction. Shape of standardized interfaces. 🙂 I think the opportunity for us to learn from OSS regarding the benefits of components is one we should take seriously. We will not stop betting on the value of integration, but the way in which you do it, and the range choice and flexibility you give your customers is critical. I would never put forward the idea that we should be monolithic in our approach, in fact that would be suicide for us. A rich ecosystem with many players plugging in to the stack is the way to maintain long-term health. But as complexity increases, if you are not looking to reduce the most costly aspects of the solution and move as much as possible onto the technology’s shoulders then the issues with integration become problematic.
In the end, I agree with Stephen that this is a question of how the customer will see it. Where do they perceive value and what are trade-offs that they are willing to make.