Open Source Support Services: An Interview with Kim Polese
by Dan Woods
Kim Polese is a veteran of several key development projects and startups. At Sun Microsystems she was involved in the Oak project which eventually became the Java language. As an entrepreneur, Polese was CEO of Marimba, a company that pioneered automated change and configuration management of distributed computing components.
Her current job is CEO of SpikeSource, a startup that provides support services for open source software. Dan Woods asked her to respond to key questions that IT departments will ask about open source support companies. (Note the Reducing the Risk of Using Open Source: New Tools, Services, and Approaches panel at the Open Source Business Review conference (which is part of this year's OSCON in Portland, Oregon from August 1 through 5) will address the emerging landscape for support and other services.)
Q. What sort of open source projects will lend themselves to commercial support services?
A. Frankly, any that are being used. Commercial organizations want to reduce their costs, and want to know that their deployments are covered in case of trouble. Cost reduction isn't about doing eveything yourself, it is about finding a solution that provides the right mix of services you need at a price point that makes sense.
Q. Are Linux and Apache too mature and stable to require commercial support?
A. No. One might as well ask the same of Windows and Solaris. The fact is, customers want support and maintenance of any deployed solution. And even if a solution appears mature, the world around it changes. This reminds me of the story of the professor who didn't change exam questions from year to year because the right answers changed. Reality changes.
Needs change. Risks change. Customers need service.
Q. How early in the open source lifecycle can support be offered?
A. That will vary by the supporting vendor and that vendor's precise mix of service offerings. Consulting services are frequently concerned with customizations and tuning, and so may be offered relatively earlier in the open source lifecycle while the code is less complete. By contrast, traditional telephone support will become cost effective through economies of scale. Different vendors will probably start offering this service at different times, but we should expect this to follow consulting services offerings.
Q. What sort of bundles will be offered to IT departments?
A. The bundles will be familiar, because the commercial vendors designed their bundles around the business needs of their customers. So you'll see maintenance, which provides software upgrades over time, support to assist with questions and problem resolution, and consulting for assistance with application development, product configuration and customizations.
Where things will differ is in pricing models. Commercial vendors almost invariably charge a maintenance fee based on the license fee. Support fees may also be tied to this metric. This was an easy model to understand. With open source components, other benchmarks will be tried in an attempt to serve customer and vendor needs more precisely.
Q. Will supported open source bundles be application-specific or be more likely targeted at providing infrastructure?
A. Both. This question is really asking whether customers will build their own applications or deploy prebuilt solutions. Some customers will install complete solutions, others infrastructure on which they build their own applications, and some will do both in different projects. In each of these cases, IT personnel will look to acquire services to reduce their deployment and maintenance and support costs.
Q. What skills will an IT department need to use commercially-supported open source?
A. This depends on the open source component's lifecycle and the project underway. A later question asks regarding early adopter, early majority or late majority. The skills required will depend in part on this determination. Early adopters, by definition, are using the open source project before it is fully baked. There will be problems. Features won't be fully implemented.
An IT shop will get involved with the project at this point in time because they have a specialized need and can derive commercial advantage through using and helping to develop this technology.
In this situation, the IT shop will need good development skills, either in-house or through services engagements. Being open source, the rest of the 'team' is remote, so strong communication skills and a different sort of problem solving that works with remote team members and distributed information sources will be important. It is also critical for developers to avoid temptation to make improvements for the sake of improvements - the value of open source is that a large community is working on it, so if your codebase diverges from the mainstream then it will become just another in-house product.
Once an open source product reaches mainstream use, the need to extend or correct the code is reduced and the skillset comes back to communication, remote interaction, and the ability to seek and utilize diverse external information sources.
In all cases, there is an additional need to be keenly aware that your team-mates work for other companies, frequently competitors. It is therefore important in using external information sources like discussion fora and mailing lists to be aware of the difference between public and private information. Debugging problems in public while protecting sensitive corporate assets and proprietary information requires forethought and tact.
Q. Will it appear to IT departments exactly the same as commercial software?
A. In many cases yes. In some cases it will appear better.
If using an 'early adopter' package it may appear much worse. A real strength of open source is the sensitivity to customer requirements. Because the users can and frequently do extend the product to meet their own needs, users of mature open source will frequently find it solving problems their commercial vendors never got to.
The risk in open source is that it is source, and there may be developers in their organization who want to take advantage of the source to "improve" the code. As mentioned above, this runs the risk of diverging your codebase from the public one, and both introducing errors as well as making it more difficult to pick up improvements from the community. The decision to modify the code is not one undertaken lightly. If a fix is really important, you should factor in time to contribute it back to the community.
Q. How much of the traditional productization of open source, item such as install scripts, documentation, configuration tools, will have to be provided by the provider of support services?
A. This is one of the weaknesses of several open source projects, and strengths of commercial support organizations. The developers of open source frequently don't feel the need for good documentation, or the desire to devote the time required to write it. This is one of the parts of usual product release management that is lost by this development model. Similarly install scripts, configuration tools. Open source support organizations will be evaluated in part on how well they assist in this area.
Q. How can IT departments get this right?
A. Don't go it alone. Getting anything right depends on information and planning. Open source deployments are no different. Support organizations are there to aggregate users to provide the economy of scale that is necessary to make good benchmarking, documentation, and best practices development worthwhile.
Q. Which sort of IT departments will find commercially supported open source most attractive? (early adopters, early majority, late majority)
A. It is less about the organization than the project and the status of the open source component being used. As described more fully above, those using early versions of new open source products will find consulting services more valuable. those using more stable, tried-and-true products will get more value from traditional support and the tooling and best-practices knowledge that comes with experience.
Q. What is SpikeSource's business model and how does it address the issues raised so far?
A. SpikeSource will focus on integration and certification of well established open source components, and will offer periodic updates and support services around those integrations. Because of economies of scale, SpikeSource will provide better certification, documentation, and configuration tooling than end-users can justify developing on their own. The product updates we provide will follow a product management process and bug or security fixes will be provided in a separate stream from feature improvements to permit customers to better determine which upgrades they want to adopt when. Most of these updates will be sourced from the community, through active monitoring of development activity, but some will be developed in house in response to important problems that the community hasn't yet addressed. SpikeSource will substantially reduce the cost and uncertainty of integrating open source products into IT applications.
SpikeSource, SourceLabs, Optaros, and a few other companies are pursuing this model. What is the likely effect of these service on the open source community, if any?