One of the important issues facing software procurement decision makers is the availability and price of support. The TCO (Total Cost of Ownership) of a software system over the long term is more than the purchase price divided by the life of the product. Often, support costs far exceed original purchase costs over time. People who are responsible for making software acquisition decisions know this, and if they’re smart, they do support cost research before they procure.
Predictably, claims of lower support costs for open vs. closed source products abound on both sides of the argument. Open source proponents often claim significantly lower support costs for open source, based on the idea that support is a community affair. In his article, “Open Source Security: Better Protection at a Lower Cost,” Steve Schlesinger states “The open source model also lends itself to more vigorous and timely after-sale support from an active community of users, which in turn lowers the cost of support…” Similarly, Robert Westervelt notes in “Open source making its mark,” that companies planning to move to MySQL based solutions do so in part because they are “…lured by low cost of support and maintenance…” On the other side of the coin, in a TECHWORLD article by Phillip Britt, Joe Burton of Cisco (in responding to lower TCO claims of open source software) said that “…
- Quality support must be available either on a business hours or 24/7 basis, depending on the product and the company.
- There should be no possibility that a support issue will not be addressed by some responsible entity.
There are free support options for open and closed source products. A product of any significant market presence will inspire forums and newsgroups where users of the software congregate and help each other out with problems. However, if you’re a corporation, you will still pay for support one way or another. There must be a chain of responsibility that ensures the company won’t be hampered in its day to day operations by bugs that show up in software. So how will you pay? Here are 3 common options:
Paid Phone Support
You can get paid phone support on almost any common software system. For closed source companies (and some open source companies) there is a staff paid to answer the phone and help customers with issues. For open source companies that don’t offer paid corporate support, there are often third-party companies that exist to provide support for their products.
The problem with phone support is that except for trivial issues, there is no guarantee you are going to get your problem resolved. I know in my own experience, by the time I call technical support about an issue with a development product (which is typically what I use), I know significantly more about the associated behavior and technology than the support guy does. More often than not, I wait for a couple of days while he gains the specific knowledge he needs (and which I already have), and then he fails to give me a meaningful solution. I suspect that anyone who uses software regularly has run into the same issue with phone support – satisfaction is hit or miss. (This is why large companies making significant software purchases will often insist on a custom support agreement that includes processes for expediting bugs and guaranteeing certain types of response within certain periods of time.)
Another way to pay for support is to hire a true product wonk. She’ll go on the paid IT staff and make sure the installation stays up and running. She does this by being a subject matter expert; she knows how her products work, where to go (community-wise) for answers, and who to call in a pinch. These rocket scientist types pull down large salaries, and a little research on Monster and other job sites shows that salaries are equivalent for these people, whether their expertise is in open or closed source systems.
Paying a consultant on an as needed basis is a way to get the rocket scientist with a lower cost. While this is common for small companies who have to keep costs very trim, there is a down side to this approach. They may not always be available when you need them, and they may not have the same sense of urgency that an in-house employee will.
Claims to the contrary notwithstanding, in the final analysis I think it’s clear that there is no general support-cost answer that advises toward open or closed source products. The real cost of support will need to be measured on a product by product basis. Those costs depend on many factors, including how well the product works out of the box (or out of the download folder), specific support offerings for the product, whether you already have an expert in house (or the availability of expertise if you don’t), and many others.