Re: Should IT Leaders Worry about Fragmentation in the Open Source Community?
The basic question posed is:
‘Are we still in the “surfiet of great choices” stage, or (with enterprise interest and acceptance) are we swinging more towards standardization? Is fragmentation a real problem, or just part of the cycle? In other words: Which way is the open source market going?
Rod Johnson of SpringSource commented on this:
‘If there’s a new entrant into a category dominated by closed source vendors, developers (at least) typically welcome it. If there’s a new entrant into a category with at least one strong open source player, developers often react negatively, questioning why the new alternative is necessary.’
I believe fragmentation in open source will always follow a different pattern from the traditional one.
Most people recognize the fact that having a single open source option is not good, so a small number (2-5) of contenders is a good thing. You also have to accept that you need open source options for each standard and/or technology base. This leads to natural and healthy array of options.
Lets take workflow engines as an example. There are a number of current standards for defining workflows (BPEL, XPDL, Wf-XML, etc). Each of these formats has strengths and weaknesses and they appeal to different segments within the workflow domain. Then you need to consider that integrating a C++ work-flow engine into a Java application is not ideal. Developers can be very religious about the languages they use. From a community perspective an XPDL-based C++ workflow engine is not a competing alternative to a BPEL-based Java one. Assuming that at least 4 technologies are common (say C, C++, Java, PHP) we now have room for 24 different open source projects (3 standards x 4 technologies x 2+ options) before the space is even minimally populated let alone ‘fragmented’. While it is true that SOA and ESB make integrating different technologies easier but that does not mean than an IT department wants to maintain and develop in multiple languages.
If you only look at high-level functionality, open source does seem to be fragmented and have too many overlapping projects. But in a technology-led decision most of the open source options are filtered out at the start based on ‘fit’ or ‘suitability’ of the underlying technology. What is left is a reasonable short-list. I think this will always be the case with open source.
The question of how many commercial open source companies any domain will sustain is entirely different.