Connecting open source software expertise, support and services
One of the best things about blogs is the conversations they enable. Each blog has its own purpose and reach, but if the conversations could be chained together in the form of trackbacks, comments, response posts et. al they form the makings of a marketplace where the ideas, facts, viewpoints, and even perceptions drive what is an integrated, global bazaar.
Anyway, a small tidbit of the blogging expanse recently caught my attention. Rod Johnson, Interface21 CEO, posted a response entitled "Replies to Nonsense about Open Source." The spirit of this post, and that of its predecessor, is probably best summed up in Rod's own words from the latter:
"You can't divorce the process of maintaining software from the process of creating software."
I agree with Rod. The above is precisely why the term vendor lock-in was coined. When closed source software vendors "sell" customers a product they are in actuality on selling the right to use it under the terms of agreement set forth by its license. Customers must rely solely on that vendor for maintenance and support of the product (even if the vendor is replaced with a reseller, the equation remains the same). On the other hand, open source has done a lot to restore a healthier balance to the vendor-customer/user-creator equation with the concept of shared ownership.
What it takes to service and support
Openly available source code has also created room for a new breed of support and service. SourceLabs is one example, Covalent is another. Both companies have built business models around leveraging freely open source software through shared investments in their communities. SourceLabs lists the following as contributions (from their website):
- Active participation on Axis and Axis2 user and dev mailing lists, answering questions and offering assistance
- Wrote Axis 1.5 release plan
- Contributed code to Apache Axis, Apache Jakarta Taglibs
- Apache Commons committer (formerly Jakarta Commons)
- Apache Struts committer. Bugfixes and testing of Struts 1.3.x releases.
- Apache Commons committer. Release manager for CLI 1.1, Lang 2.3, IO 1.3.1, IO 1.3, Discovery 0.4, DbUtils 1.1, Lang 2.2, Attributes 2.2.
Covalent states the company has(from their website):
"[A]ssembled one of the deepest talent pools of Apache experts in the industry and is proud to be one of the most distinguished supporters of the Apache Software Foundation (ASF),"
Both SourceLabs and Covalent are also providers of open source stacks providing testing, integration and support of SASH and ERS, respectively. In effect they have built a commercial product plus infrastructure around proven experience and expertise. Obviously, both company's ties to the open source community behind the software assets in question run quite deep. In this particular case the aforementioned community for both SourceLabs and Covalent is the Apache Software Foundation, which happens to operate as a non-profit operation and entirely different from the operating style of the incorporated Interface21.
The OpenLogic case
Where Covalent and SourceLabs feature service and support models built on specified areas of expertise, OpenLogic takes a broad-scale approach. Yesterday, the company launched its OpenLogic Exchange (OLEX) that provides access to more than 300 open source packages
in the OpenLogic Certified Library. I'll go on record as stating that, 300 is nowhere near the total number of open source software packages available, but it is a large number nonetheless.
In his two posts Rod highlighted the difficulty of providing true enterprise level support for open source software, a point I think was taken out of context as implying that only the developers paid by vendors like Interface21 are qualified to diagnose, fix and apply patches to open source. What I took from that statement is that its terribly difficult for third party developers, no matter who skilled they are in general, to tackle the complex issues which can arise in conjunction with mission critical deployments of open source. Sure the source code is there, but complex issues are best handled by those who are examining and working with the code base on a daily basis. To be fair, it is highly probable that the OpenLogic Expert Community contains a healthy number of developers with extensive Spring experience, it may even include committers from select projects. But I have to wonder if the same can be said for each and every one of the 300+ packages supported by the company?
As a result, it only seems logical to assume that in order for OpenLogic to provide the level of quality enterprise support necessary in mission critical environments their Expert Community must be in direct contact with the entities that fund most of the dedicated manpower for projects, companies like Interface21. The prospect of OpenLogic having acquired more than enough experience to go without doing so is slim to none. Committer experience does count for something, after all. It comes with specified familiarity to an extent that generic software development experience does not. Even outstanding developers aren't granted immediate expertise with a particular code base on the sole basis of having written good software before. Likewise, I personally know some really sharp Java developers who can work magic building Spring driven web applications but don't have an ingrained, deep-dive understanding of Spring's entire internal architecture.
Outlook
Hopefully this post isn't taken as a critique of OpenLogic, either. Actually, Rod did them a favor whether they see it or not. They are in position to open up and fully engage open source communities through their OpenLogic Expert Community. The company could begin to work at developing processes for connecting not just with Interface21 but the entire layer of bona-fide Spring experts across the world. Perhaps, OpenLogic feels they are competing with Interface21 for service and support contracts so they've got to wall them off? I hope not, as that approach is going the way of the Dodo. Rather, their goal should be to lay the foundation for a real expert community, one that resembles a truly integrated network of expertise, one that could pushes the current boundaries of the current conceptualization of open source support and services.
Comments