Open Source More Expensive In the Long Run?

Jack William Bell asks: "Could the PHBs possibly be right on this one? A recent evaluation I performed of competing commercial and Open Source products yielded the surprising result that the Open Source products were more expensive (in terms of lifetime costs) over a long term than many of the commercial offerings! Why? Basically this mostly revolves around higher support costs for Open Source products where no commercial support is available (unlike, say, Linux where you can purchase support from Red Hat, etc). This particular case might also be a result of one special set of requirements and environment and a similar evaluation for a different set of requirements and environment might yield a different outcome. But, nonetheless I found the experience instructive and I would like to ask two questions of the Slashdot readership: Firstly, is Open Source usually more expensive when all lifetime costs are factored in? And, secondly, is anyone in the business of providing commercial support and training for the entire universe of Open Source, perhaps contracting on a product-by-product basis? I guess a corollary to that question is, if not then why not? There might be a viable business model here!"

"Here are some details for you:

I am currently doing consulting work to create a complex custom search utility for a governmental agency. The first major step was, of course, to select a Search Engine that provides as many of the custom requirement features as possible; thus reducing the amount of custom code and my expensive time. Besides high-end search features my customer also required something that was fast, easily administered and likely to be supported for a very long time. Why the last? Well, the expected lifetime of the new project is ten years and this is not out of line considering that their current system is more than a generation old!

Consider again the environment; this is a government agency and is somewhat resource starved. They have a limited number of staff and the staff must split their time among many different working areas. They must be generalists and do not have time to specialize. Plus there is some turnover, especially among the better skilled staff. These factors lead to a basic requirement that there is someone they can call for support for every product they use, preferably 24 x 7. They also need to know that this support will be available for the entire lifetime of the project -- in this case a full decade.

Now to the chase -- without going into boring details, or names, we were able to locate nearly sixty Search Engines that might be suitable. Most of these were commercial, but some were Open Source. From this list we selected eight that seemed most likely to provide all the capabilities we needed, of which one was Open Source (in fact this was actually two variations of the same project). We then performed detailed paper analyses of these products, comparing features to our requirements list and doing some estimated per-year costs to determine the lifetime costs. From the results of this we selected a smaller number for in-house evaluation and from that we selected the final recommendation.

For the commercial products the vendors could supply us with support costs, often broken down in such a way we could choose our support like a Chinese menu. But for the Open Source products this was not the case. Contacting the maintainers of the Open Source products and asking if anyone provided commercial support was fruitless; in one case the response was downright rude (basically a variation on RTFM) and in the other the response was more helpful, but still could not suggest anything other than being active on the mailing list.

So I had to figure in the cost of one of my customer's IT staff staying active on that list and learning enough about the product to provide in-house support supplemented by the email list. Estimating this at one tenth of an FTE and that FTE at a low $80,000 per year resolved to $8,000 per year. This was nearly three times the cost of the most expensive commercial product support!

When factored in with equal administration costs, adding in training and support (available from these vendors) and other one-time and yearly costs (for such things as licenses), the commercial products were more expensive for the first four to six years of lifetime costs, after which the Open Source product became more expensive. Of course the difference wasn't too great, ranging from 20% to 60% higher in a ten-year lifetime. But it was there nonetheless.

Now my customers are not averse to using an Open Source product. After all, there is no guarantee that even the most established vendor will not fall by the wayside in those ten years. They just want to have a certain comfort level, even if it is illusory. And I must admit that any commercial product will require some time from their IT staff, but because there is 'support' available this is seen as being much less important. Major fixes or changes can be dealt with by hiring consultants like myself, and lesser issues dealt with by calling customer support. They might even be right in this estimation.

My estimates might have other holes as well, but that isn't germane. The selection process is nearly complete now and, in a detailed analysis the Open Source products turned out to be missing a couple of features that would have been showstoppers even had support been available. I want to know what resources I can use to (honestly) avoid this issue the next time I am comparing Open Source to commercial software for a client!"

Comments

Can be

[MrChuck]

Sure, it can be.
Mismanagement can make lots of things really expensive.
I've used BIND for YEARS. Very little effort except to keep it up to date. Low costs.

I've seen people mangle Lotus Notes into being unbelievably expensive, shown when the lies, damn lies and statistics took into account the same costs they fixed to our Sendmail and QPopper infrastructure (every desktop admin who did pkg_add of my sendmail build once on the machine was had their salary attributed to the cost of standards based mail). We suggested that their notes costs that left out administrators was a bit slanted.

Careful management and selection of software is important.

The acquisition of software is usually the smallest cost.

But support for "unsupported software" and, more, the ability for a talented administrator to fit it to his company's needs is often well worth that lack of security PHB's have.

That and a list of unresolved bugs from our "supported" software :)

. So yeah, I can take a bug tracking/CRM system, install it and make our bug tracking process fall in line with the vendor's notion of how we should do our business or
I can take open source components (bugzilla, GNATS, etc) and other tools and use them to fit how we do our business already.

The latter might take more effort, but at my previous company, we had an ENORMOUS CRM tool that only ran on windows (now add cost of desktop windows where before we had been a 70% unix shop) and we ended up with a tool that Sales marketing and tech support HATED. The data in it was often useless because it was such a burden to use, and we ended up hiring extra people to deal with data entry.

But I know that I could make a case that showed it was cheaper than using Open Source by perhaps showing that features we didn't really want before, but used later only because they were there (report generation that was handy, but far from critical) would have been an additional cost to add to O.S.S.

On the other hand, I've used tools where once we've been bound in, the ONLY way to generate reports was through expensive tools.
A little Perl and ASCII logs from Open Source often make Open Source a winner on this, but that often won't be taken into account.

Many of us here have slapped in a free tool to do things that the corps were taking forever on. Example:
A $3000/machine host monitoring solution was found and chosen.
Now there must be a committee to best decide how to deploy and configure it.
We get bored. net-SNMP on all our machines (runs scripts, reports info, etc) and NOCOL and 2 days later we have 40 machines monitored via the Web, pages getting sent on outages etc.

6 months later, we're told to take it down and pony up $3000/machine to use the "blessed" software.

Re:One benefit

[DunbarTheInept]

If you think the benefit of changable code that open source advocates claim is purely based on in-house people making the changes, you aren't thinking it through. So long as SOMEONE SOMEWHERE makes that
change you can gain from it. Over time this tends toward programs that the user population wants to use. The big problem most open source programs have is that their audience is typically tech-saavy people only, and therefore the changes that get made are driven by the needs of the tech-saavy only. It's not that the developers are unable to meet the needs of the less tech-saavy - it's that they have no incentive to.

And that's why the most successful Open Source software is that software that tends to have a tech-saavy userbase ANYWAY regardless of whether it was Open Source or not. For example, syadmin tools, programming language compilers, dynamic web servers (not just serving static pages, but running programs on the server), ascii text editors, and so on.

The other place Open Source software does very well is in an embedded device where the user never deals directly with the software anyway.

The only way closed source software has saved ME time is that when it says something cannot be done, I tend to believe it more, so I don't waste much time TRYING to get it to work. I just accept that it's hopeless and move on.