Slashdot Mirror
Open Source More Expensive In the Long Run?
"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!"
I find that commercial software is updated or "upgraded" to a new version, new license, hence a new lifetime much more often, whereas the OSS applications we use such as Apache, just age and get more patches, hence a much longer lifetime, and more apparent support required. Looking at our system to admin ratio, the M$ systems are at like 15 to 1, while the unix systems run more like 30 to 1. Note I am not counting the Bazillion M$ desktops because they are generally imaged and they do very little trouble shooting, just reimage and restore.
errr....umm...*whooosh* *whoosh* Is this thing on ?
I work for a company that is trying to migrate from Sun to PCs, and (against my advice) chose the windows NT line (it won largely on the support argument). For some of our in house applications we do a lot of parallel computing, NT was simply not able to do a lot of what we needed it to do. Anyone care to guess how much support we have gotten? We have gotten none, MS responded to our complaints by telling us (paraphrased) 'you need to find a way to hack our system'.
In closing...
You have to consider the quality, and amount of support you get for the commercial stuff, not just that they claim there is support.
"I'll have a Guinness, no wait, make that a Coors Light" -Grad student I work with, who shall remain anonymous...
Our FEDEX machine is Windows NT; support for that consists of some phone tech reading (haltingly) from a flow chart.
Our office PC runs Windows 98, unsupported by MS. We have two Macs, one a clone running OS 9.2 (unsupported), and the other running 10.1 (Apple has moved on to 10.2.)
At home, I'm using BeOS (unsupported - Be is dead, soon to be supported open-source style!) and some other unsupported Windows configs.
Security and bug patches for windows 95/98? New SPs for Win 2000? Nope.
What was the question again?
There is an economy of scales working here.
Where support costs on OSS really make sense is in a company where there is one geek that can manage several OSS products. If this fella is getting paid 80,000 per year and he can support many OSS products, your cost of support decreases. As he supports more products the cost per product drops.
On the other hand, in your case, there is one product that must be supported, and one person supporting it -- or there is only outside support. In your case, OSS software probably is more expensive than a supported, probably more intuitive product.
RedHat's Advanced Server is not flying off the shelves, despite companies demanding that there be a less frequently changing, better supported version.
Sendmail, Inc is not growing wildly despite their MTA being on 84% of the Fortune 100's gateways (according to their website). And who knew they had IMAP and Webmail products (not open sourced, apparently).
Nominum is Vixie's support org for BIND and DHCP after the ISC didn't really attract tons of money from people who live and die by BIND.
Source Forge code didn't really work on anything but VA Linux boxes running their Linux. Lots of work got it to RedHat, but it was complex and impossible to setup 18 months ago. Now it's commercial saying, to me, that you need someone else to come configure it.
Would Mozilla exist without paid developers from Netscape^WSun^WAol working on it?
-
It seems that post-bubble, that the Commercial support of OSS model isn't really working out? Is it because on our side of the fence - the linux/bsd users won't pay for ANYTHING? One big failing is that last 10% that Unix programmers tend to skip - the part that's not fun to program that makes the tools Usable by Mom<TM>
"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."
Did you try: we're gonna pay you 400$/month to answer our questions regarding product xxx?
As a long time corporate IT hack, I can tell you that you need in-house expertise for almost all of the software you end up running. I dont care how much it did or did not cost to install; that is irrelevant.
For mission critical applications, even commercial support is lacking.
I market my skills with many commercial products to many different clients. IBM MQSeries, MVS, HP/UX, Microfocus Cobol, Oracle, DB2, IDMS, etc. etc. etc. Even thou the client has a support contract with every vendor, there is still an in-house need for that support. That's when the contract me..(james bittner at netscape dot net)
The lack of that type of support for OSS is a vailid concern, but the cost estimates where way off base. OSS or commercial, doesnt matter, they is a certain level of in-house (could be contracted on temp basis) support required that did not get figured into the estimates.
Trust me, vendor support does not mean they will make everything work for the cost of that contract. the contract allows for minimal help, and everything else is billable....
j.b.
Your cost differential analysis is flawed because of a base inequity. You presume that your for-pay solution will not have a percent-of-FTE-time associated.
Even when you pay for support for a product, if you don't assign someone to actively track the product you will not gain the benefit of the support you pay for.
Few if any support contracts provide that "whatever the supporting company discovers will be broadcast to the paying customers." That is, while the infomation will be "made available" to the supported entities, it will not be spoon/force-fed to same.
Consider the typical support contract. Such a contract entitles the user to certian things:
1) reasonably unrestricted access to some sort of knowledge base.
2) reasonably unrestricted access to the current patch archive.
3) telephone/email (whatever) access to someone who will help you find your way through items 1 and 2.
4) the opportunity to add bugs to the development chain.
Usually, these support contracts seem to have more value because of the phantom-element number five. (Someone to blame when the fix isn't available.)
Now a truely expensive contract that garentees *any fix whatsoever* let alone garentees to *fix your problem in (whatever) time or less* tends to run into huge dollar amounts.
So the total service rendered for a paid comercial support contract is for items 3 and phantom-5. And you only get to use these items when something is really broken. If you are not actively persuing items 1 and 2 yourself and at your own expense then you will have taken no preventative action, and an unmaintained system will likely break no matter how you acquire it.
So Decide... Are you pricing a system that will be maintained?
If so, you will have to allocate some fraction of an FTE. That cost will be similar no matter the source or positioning.
If not, then cost will be a function of frequency of breakdown.
Then, once a breakdown occurs...
Does your support contract *garantee* a fix?
If not, then the total cost expended on the support contract was paid to deflect accoutnability and allow you to contact a person who will walk you through the existing database of problems.
Remember, almost nobody who has paid Microsoft, Oracle, Sun, or IBM to "support" their applications has *ever* gotten to do more than submit a trouble ticket. Paying support doesn't reserve you a programmer who will jump to your needs like a hound to a scent. It just buys you the right to be heard and the right to hear.
Joining the mailing list (or hopefully bugzilla-style issue/ticket database) for an Open Source product is the free equivalent to 90% of what a support contract is anyway. The only thing you don't get free is access to someone who has the cookbook for pawing through the data.
You need to quantify your expectations for "service contract" before you can properly assess the cost.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
A number of posts here have attacked the 10% of an FTE figure I used. These posts basically break down into "4 hours a week just to read a mailing list, that is so ridiculous!" and the more informed "You would still have to patch and update a commercial product, what about that?"
To the first I answer that it isn't 4 hours a week to read a mailing list. It also includes time to come up to speed with the product, with the tools the product uses (like 'make' and GCC which are not used in the shop) and with the programming language the product is written in (also not used in the shop).
These are not one-time costs because, as I pointed out, they do have employee turnover and it is usually the 'best and brightest' -- who would likely be the ones doing doing the support. So any one year it might be 25% of an FTE or 5%. Also I figured most of this effort was just so they could ask the right questions on the mailing list and not get a 'RTFM' in response. Sure I just took a SWAG and used 10%, but it was a figure my customers felt comfortable with.
Remember, I am a consultant. I assist my customers in making descisions, I don't make the descisions for them. If they prefer to err on the high side of something they are not sure about they are in the right to do so.
As to administration costs, sure they exist in commercial products. And I had a separate line item for that! The problem is that, even when I set the admin costs the same for both, the long-run effects of the support costs proved surprisingly high.
Note that making them the same may not have been entirely honest because the Open Source product would likely have had higher admin costs than a more 'polished' vendor supported product.
Jack William Bell
- -
Are you an SF Fan? Are you a Tru-Fan?
Hence why there are so many people that bash Microsoft.
However there are long running commercial product lines, all fed by yearly support costs.
Look at AIX, HP Unix, OS/390, and AS/400 software packages as specific examples, sometimes there are upgrades available but often not. Computer Associates and IBM are famous for long support contracts.
There are manufacturing applications that are still running on OLD VAX systems that are still actively supported by their creators.
$sig=$1 if($brain =~
But betting on MS really doesn't help when like most businesses you use software other then windows and Office. So while with MS your technically more "safe" form them going under, that doesn't help for all the other software out there. In the end commercial software can't guarantee lifetime support. While with Open source you can. Sure it may cost you, but as long as you have access to the source, you can pay someone to fix it. Maybe you don't want to, but that's a nice safety net that can never be taken away, unlike what you get with closed source software.
"Most companies out there would prefer to take their chances on Microsoft's long term viability then they would on taking the chance that some Open Source project is going to continue to be actively developed"
The only thing that guarantees is that long term you'll be under the thumb of MS and its heinous licensing fees.
That's the lemming point of view that has gotten the computer industry to the point where it is now. No innovation in markets that MS has a monopoly in. MS blinks and everyone takes out their wallets or stop developing software in that market.
" maintain some open-sourced program whose chances of dropping off the radar screen or having its developers lose interest are much, much higher"
That's why you choose wisely. Here is why that point which always comes up is a complete red herring. I wouldn't heavily invest my company in any commercial company who either a) may be on the skids or b) is brand new. The same logic applies to open source. Your not gonna pick some project that doesn't have a good track record. Choose your software wisely and you'll do just as well with Open source as you do with commercial, plus access to the code.
So in conclusion if you have the staff to implement it, and have made sure there are support avenues available, there is no situation where Open Source doesn't trump commercial software Period.
If you wanna get rich, you know that payback is a bitch
A GS-11 is the highest (theoretically) civil servant position that does not come with a mandatory "Management" hat. When I worked for the US Governement (2 years ago), GS-11's were making right around $50K (from what I remember).
Assuming the employee in question is a government contractor, he is probably still not making $80K. From what I've been told, goverment contracts come with a max 8% profit cap which typically means that the contracting company is going to get the cheapest labor they can find. Any attempt to get "expensive" labor will probably mean losing the contract because, unfortunately, the Government likes low bidders.
"Estimating this at one tenth of an FTE and that FTE at a low $80,000 per year resolved to $8,000 per year. "
Where are these $80,000 full-time jobs working with open source software support? I've never made close to that. The one person I know personally (granted, I don't live somewhere it costs $40K to rent an apartment) who's made that kind of cheese did it working on some proprietary stuff. Nobody I know is required to support "the universe of open source software". We support a list like apache+mysql+proftpd+qmail or so. Other stuff is supported on an as-needed basis, but I'm not an expert in more than three or four of these products.
The scope and price of this whole things is just unheard of. I'm not saying the conclusion or the premise were totally off base, but the scope is just not practical. I don't know anyone who's an expert on the universe of proprietary software, either, so I don't look for one catch-all expert on OSS.
-j
I'm offering a case study.
All vendors shall remain nameless.
We purchased a search engine back in 1995 for indexing our intranet. At the time, I was working with Matt's Simple Search, and we needed to add X x 10 features to it.
Needless to say, a TCO supplied by the vendor "proved" that rolling our own was going to be almost double what their product was. We purchased the commercial system.
This was not your basic "I learned Windoze programming" type search engines. We bought a dedicated AIX box, etc, etc, etc.... However, when we moved to putting PDF's online, we found that we could not use the old search engine to do this.
Wev had just had another vendor go out of business, and they didn't want to pay to get their hardware back. So, we set up Xavatoria (formerly known as Matt's Simple Search) on a separate server and added the code for indexing PDF's.
AS HTML eveolved, the old search engine was choking on JavaScript and other new HTML tricks. We wrote perl front ends to strip these tags. And on and on like this. During the last year of that search engine's life I spent 25-40% of every week getting it to work. The program itself had a slight problem of corrupting its keyword database every month or so, yada yada.
We finally ended up switching because FDSE could parse and return a value from a 50MB index in 1/4 the time as the commercial product. They kept asking: "Why is this page so slow and the rest are normal??"
Now, we could have upgraded the SE in each of the cases above. Original cost of the Search engine: 12,000 + hardware and AIX licensing. If we had purchased all upgrades to that point, we would be on our second server after suffering through 4 major revs to the product. Each upgrade was priced higher that the initial cost.
1998: 12,250
1999: 24,125
2000: 18,750 (Discounted because of the need for a new server)
2001: 16,250
2002: Company out of business, product EOL'ed
(Support contracts ran from 8,000 py. initially to 43,000 py. in 2000. Mostly this was due to our version being EOL'ed for so long. If we had upgraded the support would have been 22,000 py. in 2000.)
That AIX box is now making a nice file server, and we are using the Fluid Dynamics Search Engine (Formerly known as Matt's Simple search and Xavatoria) to index our sites and our PDF's.
Over the life of that machine it was an almost $400,000 money pit. FDSE runs for free on a server we didn't pay for. Even counting my time (which was less than used to support the older product) I would say it was 1/3 of a FTE (me!)for initial setup. This includes adding custom functionality that the other product didn't offer.
That's still about $30-40,000 TCO. 0.1%. And that is before you count the time I spent maintaining the old one.
~Hammy
Kevin Stevens wrote:
Or you just use Debian: apt-get install foo
For things like basic file utils, it really is as easy as that. Arguing that it's some kind of huge effort to install a new prog in Linux is either FUD or evidence that one hasn't ever used a decent distro. This isn't 1996.
In principio creauit Linus Linucem.
There are VERY FEW commercial software companies that support a particular app for more 5 years. 5 years is a LIFETIME. Win98 is EOL and it's only 4 years old. Ditto for NT4 which was still being sold 2 years ago, and support is for the most part GONE.
With OSS, you can basically support it forever, porting to new architectures, adding enhancements, fixing bugs, whatever. You just can't do that with comercial closed-source software.
The problem with code-escrow of commercial code is that you won't know how bad the code is until you NEED it. You may find that it's unmaintainable. Not an issue with OSS, where you know what you are getting into right up front. There are also other problems with code escrow but it usually is dependant on the terms of the contract.
I developed an application / custom hardware sold to utility companies about 8 years ago that is still in use. That code has had about 6 different maintainers since I left, and they hacked the code to shit, lost backups, etc. leaving my former clients in the lurch. We did offer code escrow, since the utilities end up using this stuff for 20 years or so, but not all the utilities took us up on the offer (since we charged extra for it.) Some of the equipment we replaced was over 50 years old. If I was doing this again, I would have pushed to just give the code to the utility up front. It just ain't right what happened to them. If they had the code, they could have hired someone to port to more modern hardware (it was PC based) or even a different OS (the code was designed to be very portable.) The code was useless to anyone that didn't have the custom hardware.
Bottom line is that comercial support is USELESS if your needs are long-term, and the company can't / won't support it long-term.
OSS give you freedom. It's hard to put a dollar figure on freedom. Some say that it's priceless.