When Sun announced it was acquiring MySQL I was pretty skeptical that a potential customer would trust Sun to provide them with support any more than they would MySQL - which employs almost 100% of the developers of the product an has the technical expertise, and already had enterprise support systems in place.

However, anecdotal evidence suggests that the acquisition has had a big impact on how some potential customers (particularly conservative ones) view the MySQL database. Sun's support resources and its existing relationships make a difference.

That doesn't mean that all open source vendors have to be acquired by Sun to gain entry into enterprise accounts (although many more of them will be no doubt). Most small vendors face the same problem, whether they are open source or proprietary.

Red Hat has shown that it is possible to establish that level trust of trust with customers, although clearly it takes a long time and total commitment to customer service. Fortunately the subscription model lends itself to keeping the customer satisfied.

Above and beyond the support topic, many enterprises have cited that "lack of in house knowledge" is a key obstacle in adopting open source solutions. This was found thru a recent survey on open source by EnterpriseDB.

Without a vibrant and responsive community willing to spend time with new users, companies that want to try to use an open source solution suffer the pain. This is one of the reasons why commercial open source companies exist today, to provide the best possible support and services for the open source project they are supporting.

An open source company that provides the best and most responsive product support and services for both customers and prospects is the real winner. When an open source company is slow to respond, then the customer will begin to think twice about whether they want to move forward with using an open source product. The good news, most of the major open source solutions have a great community of users who enjoy helping new users of open source solutions. The bad news, some of the open source projects suffer from poor product planning and development processes. This shows up in the form of poor quality releases that are riddled with bugs and sometimes released before the product is truly ready. Those open source projects that have rigid processes like PostgreSQL deliver very high quality releases to the market. Great open source products that delivery high quality code certainly require less technical support issues over time.

First I'll echo Matthew's and Bob's comments - Having an organization with a reputation for enterprise-class support (like Sun) back up a project will make a difference for some customers. And, well-managed release processes that reduce the need for support will also make a difference. Anything that will assure customers that they will get high-quality support, or will need less support to begin with, will certainly help.

However there's a bigger picture that's being missed, namely, it's not just about support. It's a broader concept, let's call it "enterprise fit". The way modern enterprise IT works, there are numerous expectations for a piece of software coming from outside. During the OSA's Customer Forums, we heard about these over and over again. Certainly support came up ("where do I get it, how can I ensure a solid SLA"), but also:
- How can I make sure the licenses are clean
- How can I assure quality, performance, reliability
- How can I stay up to date with latest releases, security fixes, etc
- How can I get visibility to the roadmap / influence the feature set
- How can I make sure it interoperates well with what I already have

Customers look to vendors to help them with all of these issues. The last one, interoperability, comes up frequently. Typically the bigger the organization, the more frequently it comes up. The most frequent instance is when interoperability with proprietary systems, particularly Microsoft, comes up. Running on Windows, integrating with ActiveDirectory, SQLServer, Sharepoint, you name it. "It's the big problem that the industry has done the least to address" is something we heard multiple times. The open source community has legitimate issues with Microsoft's ways of doing business, but from a customer perspective, these disputes have gotten in the way of addressing their needs.

Fortunately, commercial vendors do recognize these issues and have tailored their product development, support and services offerings accordingly. Moreover consortia such as the OSA have done a lot here. Particularly, the OSA's Common Customer View was a reference implementation including several open source applications (Adaptive Planning, Concursive, JasperSoft, Openbravo to name a few), integrated with open source middleware (Talend, Ingres, etc), and we also integrated with proprietary technology including the Oracle database and ActiveDirectory.

The result was the functional equivalent of the Oracle data hub ... addressing the common issue of "single source of truth" for customer data. That's ultimately what customers want - Help with delivering a holistic solution, not just "who do I call for support".

Overall it's not an easy problem - How to harness the grassroots innovation from developers all over the world, and deliver it in a form that enterprises are ready to consume. But if we start with defining the whole problem (enterprise fit) instead of a part of it (support), then it's solvable.

- Dominic, wearing my "OSA President" hat :-)

A support contract is an insurance policy and like other such policies it may or may not be used. Whatever comfort they give to CIOs, they can be very useful in providing, well, support.

Just as some people frequently re-evaluate their car insurance policies, open source support contracts should be reviewed on a regular basis. Here are some criteria:

• Was the contract ever used?
• If so, was it worth the money?
• Did users try to use communities or web search to fix their problems or answer their questions? How successful was that?

It may turn out for some open source software (indeed, for some software of any type) in your organization, purchased support is just not used or necessary. Other software may need it and it may be cost effective.

It may be less a question of the software and more of who the users are. Different user bases might need dramatically different support levels. Don't just assume everyone needs the same.

In the end, do the analysis and get the support contract that helps you sleep at night. But don't throw money away on insurance that you just won't use.

I think this is one of the areas where open source is not that different from traditional enterprise software. If you are a company putting software into production to run applications of significant business value, you need someone to call if you have an urgent problem. Whatever some developers may think, IRC/forums/mailing lists are not the same as having an SLA. Nor do they guarantee any answer--for example, if the problem can't be reproduced without a specific environment, or if the problem is simply a boring problem that doesn't appeal to a volunteer developer.

I don't think it's hard for companies to obtain reliable support for important open source projects. Most companies who create significant amounts of open source, not just Red Hat and Sun, provide solid support with the kind of processes and SLAs customers require.

I do think the support issue should encourage some discipline for end users in their consumption of open source. If you are using hundreds of open source projects, there's a high probability that your architecture is too complex or simply ungoverned. Getting it under control will ensure you can easily figure out which vendors you need contracts with to get quality support, and bring other benfits.

It's important to remember that not all open source projects are equally complex or important. Whenever I hear a company talk about "hundreds" of projects, the support problem can usually be boiled down pretty quickly to a handful of projects that matter.