The rapid proliferation of open source in the enterprise has been accompanied by an increase in third-party consultants, service providers and distribution firms offering support services. Customers have been left to sort through this set of choices for the maintenance and support of open source platforms. Last year's Unbreakable Linux support offering and the joint Microsoft-Novell announcement in 2006 have done a fair share in furthering uncertainty in the marketplace. For buyers, competitive dynamics between vendors, coupled with the perceived immaturity of the available offerings, has been at the heart of price volatility across a landscape of providers which has yet to take shape.
Keeping the above in mind, it pays to remember that support is more than maintenance and operation. In most cases, the real value lies in providing integration and/or solutions. Most commercial open source providers already offer a unique set of service offerings tied to a software package, which is fully expected. And, with business models tied to subscription revenues, it makes sense that these companies would sport a deep dive expertise in maintenance and support of their particular software package. However, some of the biggest challenges with open source are found in integration with the rest of an increasingly heterogeneous software stack. Unfortunately, this mostly falls mostly outside the scope of many support agreements.
To the rescue: the third-party provider. These serve as a source of reliable open source support. The competent ones have a proven track record of supporting and maintaining complex software (open and closed) configurations over an extended period of time. This is critical since after the initial install and configure period, once software is integrated with other platforms or a change (versioning, replacement, etc.) takes place to components in the stack -- the real work begins. And it takes a considerable level of experience managing complex, integrated enterprise quality software in order to even consider doing so. Therefore, the following capability checklist should be consulted before choosing a provider.
- Experience across multiple products and platforms. This is especially important as open source is being deployed in multiple configurations. The combinations of open and closed source software escalates the chances of cross-platform interoperability issues across the moving parts of a stack. Here is where experience supporting related configurations (open and closed source) enables a higher quality of service to be rendered.
- Direct connections to open source "product" resources. Buyers should always take the effort to inquire whether a service provider is involved with the open source communities associated with the products/packages for which they claim support. Providers with actual experience will almost always have some tie to the community if only because they benefit from staying close to its productive flames. The number of programmers and support personnel dedicated to support of an open source resource should be reflected in a commensurate involvement with the community. If not, a provider should be able to produce their training and certifications demonstrating a sense of significant experience.
- Industry-standard SLAs. This might be somewhat of a no-brainer, still expectations for open source service and support should be no different from expectations for proprietary counterparts. Robust SLA's, formal processes geared towards problem resolution, time-hardened tools and methodologies; and SLA accountability in the form of pre-determined consequences for non-performance.
- An understanding of the open source value proposition. In the same way that enterprises benefit from drawing a complete picture of the open source value proposition, IT services firms will as well. Even though software is software, qualified support and service providers must understand how to pass the value of open source to their customers. A firm grasp on the concept of open source value proposition will allow a provider to keep costs low, guarantee higher service quality and reduce problem resolution time in the face of an issue. This step is a precursor to creating and bundling any notion of a standard stack of open source components.
- Client references. Providers who have a demonstrable, multi-year track record of open source maintenance and support are preferable. Longer contracts tend to entail the support of more than one complex projects that serve as a test harness for quality of service and the strength of the client/provider relationship. This isn't always the case, but more often than not provides a reliable indicator of the level of capability for a provider.
About the blogger: Alex Fletcher is lead industry analyst at Entiva Group Incorporated, a research and analyst firm which specializes exclusively on the open source software industry. In addition to his analyst coverage activities, he advises organizations of all sizes on establishing governance, strategy and policy surrounding use of open source software as a competitive differentiator. Alex has prior experience as a consultant, software engineer and start-up founder. He can be reached at alex dot fletcher -at- entivagroup dot com.




Leave a comment