Source Support Offers
The whole idea of open source support raises the following question: what does it mean to have support for any
of software? For commercial
, support is stated as one thing, but IT departments purchase support for reasons other than those stated in the support agreements.
6.1.1. The Generic Commercial Software Support Offer
For the most part, commercial support agreements provide access to a team of support professionals who help ensure that the software you purchased works the way it is supposed to work. Another important aspect of support is access to a steady stream of software updates and bug fixes. Vendors often provide different levels of support, with more services or faster
in exchange for a higher fee. Support can come in the form of a database of information about the product, or collections of technical notes about problems other customers have had and ways to solve them. However, support usually means an IT department can call a company, report a problem, and get help resolving it. IT departments that purchase commercial software usually pay from 15% to 25% of the total licensing fee per year for access to support services.
Software vendors that provide support are
careful about defining what they will provide. Support is usually limited to software of a certain age, and it does not
cover older versions. Part of the reason for this is to
software. Another motivation, however, is the expense of keeping a team up-to-date on many different versions. Software companies also limit support to certain versions of operating systems and databases. You might be required to install specific patch levels to be eligible for support. It is not uncommon for a support call to begin with confirmation that the software you are running meets all the requirements for support services.
Then, of course, there is the issue of how the software should behave. Some software includes exhaustive documentation that specifies its behavior in all situations, but most does not. When software behavior is not clearly defined, software vendors and IT departments frequently argue about whether the behavior amounts to a bug that must be fixed or a feature that is just fine. If a bug is indeed found, it might be weeks or months before it is resolved.
As a practical matter, however, what IT departments are really buying when they pay for support are not the benefits mentioned so far, but rather, the
of mind that comes with knowing someone is being paid money to be there to solve problems. Support is a form of insurance. For a commercial product, support means an IT department has one throat to
6.1.2. Evaluating Open Source Support Providers
Supporting open source software is an IT department's responsibility. There is no one else to yell at or to blame. There is only the IT department and the source code. This can be a frightening prospect,
for IT departments at the beginner or intermediate level. For all these reasons, as use of open source grows to areas that are increasingly mission critical, more IT departments will seek out support.
Commercial open source support providers cannot get around the basic economics of their business. They must answer the same questions as traditional support providers, and the way they answer these questions, and deliver and price their services, will ultimately determine whether they succeed. In addition, they have unique challenges, such as supporting software they did not write, which will be more or less difficult depending on the vagaries of each open source project. In the following analysis of different open source support models, we will examine how open source support providers answer these questions:
What is being supported?
What is the definition of proper software behavior?
What operating system, database, and
software configurations are supported?
How will support services such as upgrades, patches, and hot lines be provided?
How much will support cost?
6.1.3. What Kind of Open Source Will Be Supported?
Given the vast range of quality in open source programs, it is clear that some are practically
to support, and others are
Emerging open source projects that are evolving
will never be included in a generic open source support model. Companies will be able to find support for such software, if they require it, but the support likely will come in the form of a consulting relationship with people involved in the project.
At the other end of the spectrum are the most mature products that have become commodities. Linux, Apache, and MySQL are robust, stable products. For the most popular configurations, they work well, and most open source support provided today focuses on these products. The question for this sort of open source is not whether it can be supported, but how much that support is really needed. For the most common uses, this sort of open source software just works. But then again, most commercial software also works great for its intended purpose, yet companies still feel they need support. Support for stable software is clearly something organizations want and are willing to pay for, and companies offering commercial open source support planning meet that need as one of their first priorities.
What about the open source software in between the fast-moving early projects and the stable commodity products? This software is
for certain uses, but it might not be appropriate in lots of different configurations. The definition of what this software does is not as poor as that for emerging products and not as clear as that for commodity products. It is this category of software that represents a large amount of value and a large amount of risk for different sorts of commercial open source support companies described later.
Chet Kapoor, an executive at BEA Systems, Inc., has studied how corporations use open source and has
how it is likely to be supported. In Kapoor's view, a large number of IT departments have been using open source for development and non-mission-critical applications for many
. Now, many more of them are starting to use open source for production, which is going to create a large opportunity for support services.
Kapoor's view is that open source projects, like other technologies, will proceed through the following stages:
When the project is just introduced
When the project is starting to become popular
When the project starts to work in a uniform way, with increasing productization
When the project is absorbed into the technology stack that supports computing
Kapoor thinks the big opportunity for support providers comes when an open source project has reached the standardized stage. This is when the software is generally
enough for a service provider to make money supporting it.
Now that you're armed with a clear understanding of the types of open source software that can be supported commercially, let's
to the different types of support services being
The earliest support for open source came in the form of a subscription. Companies including Red Hat, Mandrake, and SuSE collected the public distribution of Linux and other related programs into a neat package that came with regular updates. For an added fee, users could upgrade these subscriptions to include support provided by technical experts over the phone, just like with commercial software. Red Hat has been especially
in terms of increasing the breadth of the software offered through its subscription and supported by its technical support services.
Now, what sort of support do you get with these subscription products? Mostly, you get support for proper product installation and configuration, plus limited support for software operation. Interested in doing some kernel hacking? Subscription support is not likely to help. What if one of the APIs on your content management product is behaving strangely? Subscription support will probably do no more than point you to the web site for that content management product.
Subscription support provides a
service by collecting a useful bundle of stable software into one package, and making sure that all the integration or compatibility problems are resolved. Custom installation scripts and documentation make up for lack of productization, and can help an IT department
the skills gap. Subscription bundles usually
stable software at or close to the operating-system level, which doesn't require a lot of support.
Subscription support has been around for several years. While the amount of support provided is low, the price is also low. This is not the focus of the companies that were just coming out of the gate at the beginning of 2005.
22.214.171.124 Certified bundles
New companies such as SourceLabs (http://www.sourcelabs.com/), SpikeSource (http://www.spikesource.com/), and Wild Open Source (http://www.wildopensource.com/) are reaching beyond the realm of commodity software and are providing bundles designed to meet the needs of narrower but still common use cases. SourceLabs, for example, is providing certified bundles of commonly used software that works together, such as Linux, Apache, PHP, and MySQL. SpikeSource is providing another sort of certified bundle, and Wild Open Source will customize a Linux distribution for use in an embedded system or high-performance context, and then support the customized distribution.
As with the subscription model, these companies package up a collection of software, resolve problems concerning interdependencies, and make up for some of the lack of productization by creating easy-to-use installation scripts and providing documentation. However, companies supporting certified bundles include a much wider variety of software and intend to support many different bundles aimed at different audiences. The bundles might be
for reliability and be configured for high-performance operation.
For example, SpikeSource offers a certified bundle that contains 50 products, including Apache, JBoss, MySQL, Tomcat, Axis, Hibernate, and PHP, which are certified to run several different installations of Linux. Other companies such as SourceLabs offer other sorts of certified bundles.
The goal of the companies offering support for certified bundles is to become the trusted provider for a collection of software that becomes the foundation of custom development. Companies offering certified bundles will be seeking to help independent software companies who might want to deliver their commercial products on an open source platform. Certified-bundle companies might also choose to offer support for the infrastructure of custom open source projects created by systems integrators.
The obvious challenge for companies offering certified bundles is to define bundles that are attractive to the greatest number of potential customers. However, another difficult challenge is to narrow their offerings so that support can be provided. As we mentioned earlier, at every opportunity commercial software vendors choose to limit the scope of supported configurations as much as possible. How will certified bundles be limited? What versions of what software products will be supported? How will the fast-moving nature of some open source projects be reconciled with the need for a stable configuration to support? Most of all, certified-bundle companies must determine what price they can charge for support, and whether this price will support a service organization. These are not easy questions to answer. The right answers will vary from bundle to bundle, and they will be found only through trial and error.
As the support market matures, competition will increase. In addition, unlike with commercial software, in which only one company can provide support for a given product, multiple vendors will be selling support services for the same open source software. Not only will this drive down the cost of support, but also, because the vendors are competing on service it might result in a new standard for the quality of support offered. This raises the following question: will these bundles become products with a new form of vendor lock-in, or will an organization be able to switch from one open source support provider to another? The answer depends in part on the decisions your company makes moving forward.
126.96.36.199 Custom enhancements
A close relative of the sort of custom distributions we mentioned in the previous section are custom enhancements to open source projects. These are generally created and then supported by experts. Programmers from Sony Pictures Imageworks, Industrial Light & Magic, and Rhythm & Hues participated in the development of Film Gimp, an enhanced version of the open source Gimp image-manipulation program, to make the program more appropriate for certain manipulations used in movie production. Frequently, these enhancements are
to the original project. However, even if they are, companies might want to engage the experts who created them in an ongoing basis to support the enhancements.
6.1.4. Open Source-Based Products
A variety of independent software vendors have noticed the power of open source development, and a new breed of commercial software based entirely on open source is cropping up. Under this model, a software vendor creates a product based exclusively on new development, using open source projects as a foundation. The products are licensed in a variety of ways that do not conflict with open source licenses. These products frequently come with support for the entire configuration of open source used to create and run them.
Companies such as Gluecode (bought by IBM in May 2005) create application development platforms for IT using open source as a foundation. Other software companies such as Compiere and SugarCRM have open source versions, either as a marketing technique or as a vehicle around which to sell consulting services.
6.1.5. Consulting Services
When systems integrators create solutions based on open source, the service frequently includes continuing support for the open source configuration at the foundation of the solution.