Given the fact that we chatted about exactly this subject at OSCON back in August, Jason’s probably not going to be surprised by the fact that I don’t align with his view of open source and integration. Oversimplifying for the sake of brevity, I’d characterize the basic argument as open source = small parts, loosely joined, while closed source = (for lack of a better term) integrated innovation. But those are my words, here’s the argument in his:
I have long said that a key weakness of the OSS model in commercial deployment is founded in one of the fundamental elements of the OSS dev model – loosely coupled components. In an earlier blog entry I posited that the tester becomes a celebrity as OSS continues to be commercialized. SpikeSource is my favorite player in this space. The SpikeSource presentations I have sat through are focused on the difficulty in integration of loosely coupled components and the testing rigor required to bring OSS stack solutions up to par for commercial deployment. Of course, if you are to deploy a well tested solution from them or Red Hat or any other OSS player you will notice that the binary licenses and/or support contracts will specify that there shall be no modification of source code (or else the testing is not worth much).
Is there truth to that argument? You bet. Open source, most notably in the case of Linux [1], has often made a virtue of limited ambitions and focused design – eschewing the path of complex integration. This approach works for some IT staffs, and doesn’t work for others. Certainly it hasn’t been an impediment to sustained growth over a statistically significant period of time. But without a doubt, there are segments of the market that prefer to have everything neatly wrapped up for them – an opportunity that Microsoft perceived and capitalized on with Windows.
Now Jason as I’ve said many times before is a very smart guy, a very well connected guy, and when we spoke he supported his arguments with some very interesting examples. But I just can’t be convinced, however, that this approach is somehow a “weakness” or limitation of open source. In fact, I’m inclined to argue just the opposite: it’s a strength. Here’s why:
- 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. The link above has quotes from the likes of Joel Spolsky and Mini-Microsoft on the topic – who presumably have a decent view of the Microsoft internals – and more recently we’ve had the likes of Dare Obasanjo weigh in with the following:
The primary way this manifests itself is integrated innovation, a buzzword that translates to more dependencies among shipping products, less control of one’s product destiny and longer ship cycles.
This point isn’t as much about open source as much as its antithesis, of course, but I believe is important for contextual purposes. In short, open source certainly has its limitations, but the same is true of the alternative.
- I also think the notion that open source does not foster integration can by itself be proven wrong, or at least prone to exceptions. The plugin model popularized by projects like Eclipse goes a long way to providing many of the benefits of an integration heavy approach, without some of the limitations. The Eclipse community is an excellent example of how numerous independent entities – open source and commercial – can work together to produce a tightly integrated whole.
- Further, 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. Interestingly, the integration is not limited to a single vendor or approach: we have everything from traditional services (Optaros, Virtuas) to on the fly developer integration and configuration (OpenLogic) to heavily tested and certified stacks (SourceLabs, SpikeSource).
- 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? If one accepts – as I do – that in the wider market there are customers up and down the spectrum from do-it-yourself to do-it-all-for-me, which is better able to service needs on both ends of the spectrum? Open source, which is generally unintegrated, but has integratable options? Or Microsoft, which generally pitches a more monolithic, integrated stack approach and has a limited ability to decouple?
Ultimately, Jason and I are more or less agreed on the approach that open source (generally) takes with respect to integration, we’re merely divided on the implications of that approach as it pertains to enterprise wants and needs. Which is pretty much how we left it at OSCON 😉
[1] Here’s a quote from Linus: “Nobody should start to undertake a large project. You start with a small _trivial_ project, and you should never expect it to get large. If you do, you’ll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision.”
