The Sourceforge marketplace advisory board, held in Portland over OSCON 2008 days, was a great chance to meet in person open source VIPs and talk about issues and conundrums in the open source world.
A beautiful Long Tail by I-P-S
Dominic Sartorio, director of product management at SpikeSource and Open Solutions Alliance‘s president, just after the lunch break introduced us to the results of a survey conducted by SpikeSource. Among the survey’s findings is that any given customer has a component distribution that falls everywhere on the long tail, Dominic said.
If, for example, the customer uses 10 components, it is true that 8 or 9 of them may be in the head of the tail, but, most of the time, the remaining 1 or 2 will fall far out on the long tail, well beyond the 100 threshold to which a support vendor may be able to scale.
I agree with Dominic that the open source support business greatly differ from music, books, and other Long Tail markets, and not in a good way.
In short, open source components need to work together. They need to install, run, and be managed together, in the context of whatever application is depending on them. They need to be a coherent stack. Other markets don’t have this problem – Books, music, shares of stock, and so forth, don’t need to “integrate†with each other. Why is this a problem? Because the need for integration itself adds complexity to the support challenge – It is not enough to amass technical competence in a large number of components; one also needs the competence to do root-cause analysis, and determine which component in a given stack is causing the problem the customer is experiencing.
Making valuable the open source long tail is not easy. The SF marketplace maybe an important piece of the puzzle, but what is needed is an enabling ecosystem, or possibly more than one. Given the importance of High-tech SMEs in Europe , the Observatory of European SMEs analyzing success factors for the networking among high-tech SMEs found that the lack of a coordinator, either a larger leading firm or an agency, is key.
To understand how big the problem is, I asked Dominic how many components should be supported to satisfy customers’ needs.
If we extrapolate the survey data (basically assuming that, had we 10 times as many respondents, the shape of the distribution wouldn’t change significantly) we find that supporting 100 components would satisfy only about 30% of the market. Supporting 300 would satisfy 50%. One needs to go beyond 1000 to support 80%, and close to 5000 to support over 90%.
Turns out that it is possible for vendors to choose which 30%, or 40%, or even 50% (depending on their ability to scale their technical competencies) they want to serve.
How open source vendors are coping with the problem?
SourceLabs, for example, chose to focus on the SASH stack, which ended up serving a broad class of the financials industry (among others). OpenLogic scaled federated support to hundreds of components and, by focusing on enterprise customers, found established development and governance best practices that themselves didn’t scale beyond a few hundred components. SpikeSource chose to focus on specific stacks of solutions that had a mass market, thereby limiting its component support needs to those components appearing in those stacks. SpringSource/Covalent packages a distinct set of components as a platform which credibly competes with application servers in the application development market. Systems integrators like Unisys have the ability to charge time-and-materials for open source support, thereby, in effect, passing along the costs of scaling technical competencies to those customers willing to pay for it. And so forth.
The “open source mediation conundrum” – as Dominic named it – has not been solved yet, it will be interesting to see how and if open source actors will cope with it.
Technorati Tags: commercial open source, open source mediator, sourceforge, spikesource, DominicSartorio, long tail
Peter Vescuso 7:55 pm on August 19, 2008 Permalink
While the appeals court decision is certainly an important move for software creators, and one that organizations should review carefully, it should not scare people from using open source within development. More and more companies that are using open source code are doing so in the right way, so that licensing and other obligations are met. Black Duck sees the court decision as more of a wake up call to software development organizations without a proper open source use policy in place, rather than an industry-shifting milestone.
Open source is becoming an increasingly important and strategic component of today’s software development process – enabling faster and more cost effective product evolution. Underscoring its importance, Gartner recently found that 47% of the companies surveyed say they are using code from external sources. A large number of these organizations have well-established policies for open source use and adoption that take into account license obligations. The combination of proprietary and open source software has created a hybrid software development model that definitely requires careful attention to licensing – but can be managed.
Developers and their organizations should have a clear understanding of what’s inside their software components, no matter how seemingly insignificant, in order to avoid legal, financial and business ramifications. Open source code analysis is not about policing developers or prohibiting use, it provides a clear, concise and efficient way to track open source use and license restrictions- a necessity of doing business in a world in which software development is an open field.
-Peter Vescuso, Black Duck Software