'Free lunch' and open-source support

Sometimes "free" is not so free.

I recently discovered this when a large, global system integrator (SI) deployed Alfresco Labs, our free and unsupported product, for a large client in Europe. The SI wasn't a partner of ours, and as the client soon learned when its deployment stumbled, the SI wasn't capable of providing enterprise-class support on the product. Yes, it knew the product well enough to deploy it and get paid over $50 million for its trouble, but when the deployment hit a glitch, guess to whom the SI came crawling for help?

It's not just my company. I know of another global SI that has deployed well over 100 Mule ESB instances, without buying support through MuleSource for its clients for a single one of them. If something goes wrong with those installations, the enterprise clients are going to end up paying a premium for the SI to figure out how to resolve the problems on the client's dime, never mind potential indemnification issues.

Not all SIs act like this, at least not all the time. My own company works closely with Satyam, SAIC, Booz Allen Hamilton, and others, and Accenture sells supported instances of the Spring Framework, but this is the exception to the rule for the large SIs, many of which seem happy to deploy open-source software for their clients without buying support or production-grade versions of the software.

Such SIs seem to believe that life has started raining free lunches.

This is a myopic way to do business, as the large SI in my initial example found: in that example, spending $50,000 (in the midst of a $50 million project) would have saved the SI the embarrassment and cost of trying to support a product that experience proved it didn't know nearly as well as it thought it did. The SI risked the success of a $50 million project to boost its margins by $50,000, only to find that one problem with the software ended up costing it and the client far more than $50,000.

If you're an enterprise looking for a strong SI on a project, here are a few things to consider:

1. Be sure you know what software it will be deploying for you. In the case above, the SI's client had no idea it was deploying unsupported Alfresco. Had it asked, the end-result might have been very different.
2. Be sure your SI is a certified partner. Just as you wouldn't buy proprietary software from an unqualified source that couldn't support you, don't buy open source from an unqualified source that will likely be incapable of assisting you if the deployment goes awry.
3. Be sure your SI gets you a support contract. I buy Microsoft software through it or its certified partners because I then know I'm going to get what I expect, and can call for support as needed. The same holds true for open source. Buying open-source support makes sense in most cases, as the source of the code is going to be able to support it better than an SI that has no direct relationship with the code or the company/community behind the code.

Yes, I'm biased in this, as my company offers support for an open-source project, but it's what my experience has taught me after doing this for nearly a decade. There is no free lunch, and there is no free (as in price) software. You either pay to acquire it or pay to deploy it or both.

The great thing about open source is that it allows you to choose how you want to pay, and whom. I actually think it's a great thing that customers can get our software without having to rely on us - it means more choice and flexibility for customers, which is what open source is all about. In the examples above, the problem is that many SIs don't invest the sweat equity to understand open-source products well enough to actually support them. In such instances, buying a support contract is the safest (and cheapest) way to go.