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!"
Just a quick comment: commercial support isn't always the answer, and there are subtle, hidden realities there.
For example, my company pays $2000 for annual support on a commercial mail filtering product. This product will (seemingly randomly) return about 2% of all outgoing mail as undeliverable. No problem, because we have the maintenance contract, right? WRONG! Because the vendor plays the finger-pointing game, saying it's the firewall, or the mail server configuration, or anything else but their software.
Software, either purchased OS'ed may appear to be cheaper or more expensive than the alternatives, but be careful, and thorough, when doing the comparisions.
I run a small (one employee) business. All critical business functions are performed by commercial software. Sure, I'd like to use an Open Source server product and release my software to work with it, but I'm not comfortable doing that. There's too many possible configurations out there to try to support, and telling the end user that they have to do it my way never seems to work in the Linux world. These are people who pride themselves in being different - they want to tinker. I can provide a Windows installer and let that make all the decisions. Besides, my industry (transportation and logistics for small companies) is ruled by Windows. That's the reality I have to target.
Writers imply. Readers infer.
In nearly all cases, if you have competent admins, you don't need support. Tech support staff are by and large not good at troubleshooting and are don't know the products they support very well.
On the other hand, most trouble can be solved by groups.google.com, good investigation and troubleshooting, and sometimes an upgrade.
Honestly -- who really uses support?
I, for one, welcome our new Antichrist overlord.
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.
You seem to have failed to mention how you are being *assured* that company selected will be in business 10 years from now. You mention it as an important requirement but don't say how you satisified it.
In this economy, odds are good any company you pick is going to be tits-up 10 years from now. If keeping a dinosaur alive the next 10-20 years really is important to you, then you had better have written into your service agreement that if the company goes belly up OR if the version of the product you are using is dropped, then you get the product and source code free.
If your PHB are banking on the myth that buying a big-name product from a big-name company gives them security, they are idiots.
I think it is possible to find good open-source support, cheaply or freely.
The hardest part, usually, is finding a source that 1) gives quality support, and 2) is not comprised of contributors who like to treat newbies like idiots.
For just about any good OSS project, there are good FAQs, How-to's, Forums, and Mailing lists to help answer your questions. I few I can think of off the top of my head are projects like PHP, Apache, LEAF/LRP.. the list goes on. Usually, the closer you are to the source of the project, the better luck you will have and the nicer people you'll have to deal with. The more removed your source of support (133+ script kiddies! yo!) the more of a chance you are of being belittled by kids who can't even drive yet.
I've also found that dealing with companies who offer commercial solutions built on top of OSS projects -- (Ciphertrust's IronMail, for instance) tend to be very knowledgable and helpful, granted for a price. But, the support is out there. Good support is out there. And for little or no more than you'd pay to Intel, IBM, MicroSatan, or any other vendor...
Ed R.Zahurak
You know, oblivion keeps looking better every day.
1) If you are looking for commercial suppose for an open source product, why would you choose one where it's not available? That seems pretty silly, as does the related point in the original posting.
2) 10 Years is a long time in the software business. What are the chances that the product will exist in something resembling its current form in 10 years? Obviously there is some software that has a very long life, but the great majority of it does not. Assuming the commercial vendor still exists in 10 years and hasn't merged / split / dropped the product, will they still have anyone working there to support the very old software?
Yup, My company ditched an entire OpenSrc. collab. suite for exchange b/c we had no support or if we did it took a 250/hr *NIX guy to come out or do remote work. We had an IT budget of a 200 person compnay when we are only 45 people. The initial costs of getting exchange and MS products were a bit large but we have been running for a year with an IT budget that has yet to exceed its limits.
Now, I dunno what kinda search engine you're looking at but 10% of a staffers time (4 hours a week) seems high to monitor the relevant mailing lists just to "keep up". Particularly high if the staffer is just "keeping up" with security and compatibility issues and not regularly implementing extensive feature changes.
Aside from that there's the simple issue of someone riding herd on the commercial vendor's install. Depending on what kind of contract you've got generally someone in-house has to keep on top of things and make sure that the vendors is maintaining their install up to date and secure. That may well be about the same amount of time as the Open Source project may require, something I think you may not be accounting for.
Lastly there's the whole long-term viability/migration issues. We've all seen any number of projects get cut, killed, their vendors wither into uselessness, etc. As many have pointed out with Open Source at least you've got a copy of the source code to hand to someone else hired down the line and keep running. One can of course write in code escrow clauses into a commercial vendors contracts but generally they add a lot to the cost and it's a constant battle to keep them up-to-date. Plus in a decade when the whole thing is re-up for evaluation with Open Source at least you have the file formats identifiable, with closed you may have a dickens of a time pulling back out your data.
Frankly I don't think your evaluation is particularly useful, especially as a generalized one. It may well be that the Open Source project only requires a low-level staffer's yearly look-see to keep up to date. Or the commercial version may demand bringing in outside consultants to baby-sit as the entire environment evolves from today's assumptions. Or the other way round. Good topic, bad example.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
The nature of distributed collaboration leads much better documentation. On many open source projects, the manual is actually a source of information. See debian's policy.html for a good example. For similar reasons, open source news groups usually have much more helpful information than vendor groups.
:-)
Most of the time googling will lead to exactly the answer you need in very little time. Sometimes, all you need to do is cut and paste the error message into groups.google.com to get an answer.
And if you want to buy support, you can still purchase it from RedHat, etc. But I heard a dirty little secret from some folks who sell support for Perl -- it doesn't really need it
~ Patrick
Yes, it will cost time/money for your IT guy to find the problem. But.... once he finds it and compiles, he can (usually) distribute it out to the whole company w/o incurring a $50 licence fee per box.
Oh boy, a Bot-Mitzvah... Shalom hunger, Shalom free food...
I just completed a project approved by the DEPSECDEF... vital to the war effort.
vital.
and it is running on a brand new PII with ISA slots because the software we had only worked with the ISA version of some cards we needed to use.... and even though PCI cards were available that did the exact same thing, we couldn't migrate to the PCI cards.
And, you guessed it, this also meant that i could not move to a stable OS like Linux or Windows 2000.
The end result was that a mission critial weapon system is out there.. and its running DOS 3.31.
It also crashes multiple times a day - which does not make ANYONE happy. Our project was almost completely cut out to let non-optimal alternatives take care of the job
(To give you some idea of what THAT means: It would be like having to airiate a field, but because the tractor you have breaks down every few feet, they chose, instead, to drop 5 2000 lbs bombs on the field.. because, damnit, the field is gonna get fscking airiated, and it doesn't matter how.)
So...because someone before me didn't think that using open source software was important... I had no solution to my problem.
A problem i had to explain to my boss to explain to Paul Wolfowitz (his boss is Don Rumsfeld).
Let me tell you.. THAT ruined my day.
Closed source MAY INDEED cost you more - but in the long run, the fact that it RUNS is more important, even if it costs more money.
Period.
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.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
The proper response to RTFM would be for a group of people of who genuinely care about end-users having high quality documentation creating a new type of documentation license that mandates a minimum level of quality for modification of their documentation and bars distribution or linking to of bad documentation. For example, a license like this would ban any modification of the documentation that reduced the number of diagrams to less than three (i.e. converting the document to all-text is strictly prohibted). In addition to this, the license would bar distribution or linking to of HOW-TO's. If someone like Debian distributed all-text documents, they would be barred from linking to or distributing the high-quality documentation.
In essence, the license would be saying "We will place the RTFM'ing bastards on permanent lockout."
I call this license the "Anti User-Hostility Documentation License".
Ergonomica Auctorita Illico!
Rather than argue with your points, I would rather ask a simple question; "Do you now, or have you ever worked as a consultant producing high-availability custom software for business or government agencies who have strict operating system and support requirements?"
I suspect many of the people posting here would answer that with a "No." I also suspect more than a few who could answer it with a "Yes." would disagree with various things I have stated, but they would do it from a position of knowledge others do not posess. This isn't technical knowledge, but rather knowledge of how large organizations (who's core business is not technology) operate.
All I can say is that I honestly wanted to recommend the Open Source option, took a good try at figuring a lifetime cost for it so that I could do so (NOT A TCO! A TCO is different and more comprehensive.) and was surprised by the results. Note that in the end it turned out I couldn't recommend the Open Source option for technical reasons anyway.
Jack William Bell
- -
Are you an SF Fan? Are you a Tru-Fan?
Sometimes going with a closed source vendor can work out great--the last company I worked for bought a proprietary library. We found that their WinNT port was very buggy, so we sent two developers down to their labs and they worked through the source code until they had a fix. Then the vendor gave us a discount because we helped them out.
Othertimes, it doesn't work out so well. Back in 1997 I worked for a company which used a third party, closed source library to decode maps. The vendor stopped supporting the libraries (in fact, I think they went out of business), and we couldn't port our software from Win16 to Win32. It was a real road block. Had we used an open source library, we could have ported the code ourselves.
Presently, I'm working for a company which is using an open source component. We have spent a lot of time debugging the component, since the author no longer supports it. I'm sure we have spent way more than we would have if we had bought a closed source component, but our OS component happens to behave in a way we need and has functionality we couldn't find in other off-the-shelf products.
The long and short of it? Going open source offers flexibility but also may cost you more in development time. The nice thing, though, is that you have access to the code and you can make changes and make ports if necessary.
Yeah, I see your point.
;-)
;-)
I think that a viable business model is here for the taking.
Step 1:
Band together some talented *nix code wranglers.. people with a broad range of skills that can handle any of a couple dozen of the most popular programs.
Step 2:
Offer support contracts for those programs under a "if it's broken, we'll fix it, guaranteed!" scenario. Promise x number of hours turnaround on bug fixes (varying time for varying degree of difficulty) and x number of days for feature requests (which will then be released back to the original developers).
Step 3:
Profit!
This seems like a pretty standard consulting practice style setup.. has anyone been doing this? If not.. maybe we should start it
"To make a mistake is only human; to persist in a mistake is idiotic." Cicero
Suppose you're a large company (fortune 500) -- you probably have at least 2500 desktop/laptops in the field (if not 50000). 2500 * $50 = $125000. Now -- suppose you have several open source products. say 5 -- that's $625000.
Now -- to support these apps you hire say 3 full time employees at the ~$90K range (after benefits that's maybe $135K each if you have a nice benefits package). That's $405000 -- $625000 - $405000 is a savings of $220000.
Ok... this is only first year layout and a major over estimate of support personel needed. In their spare time, these same 3 people, can maintain a good number of servers, develop new custom internal apps, enhance old apps, be subject matter experts available within the company and any number of other tasks. In reality, they'd probably be spending less than %15 of their total time on support of the open source desktop apps. So, that's $60750/yr to support those apps... less than 1/10 of the purchase price.
I don't understand where you get the 1/10th of a Full Time Employee number.
... i.e. $17K for our environment) - I have never called on these, NEVER. The online resources of the user community are far better and far faster than the support calls. Same for Tru64. Nothing beats mailing lists for response time and quality of answer. I have posed the same question to the e-mail list when i've called Compaq support (blame management -- i didn't want to call). The e-mail was sent out after the initial phone call, and I had the answer before the call back.
I keep up with 4 or 5 opensource mailing lists and spend 1/10th of my time doing it. So, maybe a more appropriate amount would be 1/40th of a FTE at 80K/yr -- that's $2K/yr... roughly what you'd spend for your support contract with the other product.
Now -- about that support contract. We have support contracts for NetBackup (20% * purchase price/yr
funny story (sort of):
company i used to work for before i became a teacher needed a specialized accounting program. ran only under dos. this is mind you, back in 1991. since we were in retail, we needed specialized inventory, and a way to track our sales merchandise and the clearance mercahndise versus our regular line stuff. something about amoritization and crap. hell, i dropped accounting in college. go fiugre. so, long about a year into the program, software company folds, but we need some modifications. oh shit. but wait, it gets better.
so, we need to ugrade our systems, and get a whole new line of IBM POS terminals. link to central database. pretty forward looking for this company. hell, we even had a sort of email in 1993. way cool. anyways, we need this data to link into new sales/ordering system. but guess what? can't be done, cause the older systems don't link up, and the data files are impossible to read.
so...about two years later, i'm gone getting teaching credential, and company isn't gotten system/data up to date. not until late 90's does it get resolved. i find out from a friend with company while we were out hunting. anyways, what was the cost...
i don't really know, but, it set back a whole series of migrations and implementations for a few years. no shit. data locked into legacy systems and binary data cost alot. just my story.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
I have used open source products since the late 80s to solve problems for fortune 500 companies. The support issue has not really been a concern. It does however require that the company hire people with clues and not Minesweeper Consultants and Solitair Experts.
Any sharp group of Unix staff will not have trouble supporting Open Source. In the late 80's I implemented the ssc sreadsheet and a communications program similar to a commercial offering. These products were running within a couple of days on several different Unix platforms. Support was a no brainer as well. We did have a complete Unix development team or three around and one guy whipped up some docs that addressed the users typical needs for which there was almost never an additional request for support.
Most corporations have trained support staff on premesis. Larger companies have whole departments and can do a better job of supporting the company with Open Source.
How? Well, let me give you an example. A few years ago a friend who bought one of those all in one office printer/fax/scanner/etc. things. The sales geek claimed that it could work with NT because the geek had only the most superficial understanding of the differenece between W95 & NT. Turns out that many parts of the driver did not work properly. The printer could not be made to reset properly. He called the manufacturer and even sent the printer in for repair (twice)as the sales and support people claimed that "it should work". The manufacturer never did fix the problem and the product always operated marginally. Now the product did not work with Linux but it does now.
Why? Because open source has the best support possible. When the source is available either your
staff can handle the tuning for products that the manufacturer won't properly support or someone on the Net will help.
How? My friend worked with me at a fortune 500 client site and one day I was having a Java on Linux problem. Now Java is not open source but there is a team working on it for Linux. I submitted a question to the right location and when we got back from lunch I had answers. It is typical for me to get multiple responses to a query for a problem with purely open source as well. My friend complained that he has been waiting for answers for weeks on a similar question posed to a commercial vendor.
So there are two issues, adequitely skilled staff, and knowing where to look for answers. I have never found that the commercial product vendors provided support that could out perform the open source community. When asking how to solve a problem it is not unusual to get back multiple responses.
Oh, there is one more issue. The Unix community often acts like something akin to a cult of competence and if approached with a clueless and helpless demeanor they are not the most plesant. If the tech type takes the requisite 15 minutes to read relevant faqs and howtos and then asks for help the support is usually overwhelming.
This is my experience since implementing a variety of open source products since the 80s and Linux since '93.
At this time I am not even interested in dealing with the headaches of of commercial products if I can avoid it. I am only interestd in Open Source related contracts. Remind me to tell you about the time I asked a commercial vendor how to get a security feature working and they were supprised that I needed it as they had not even got their product debugged that far in the lab. Turns out they were playing scheduel chicken and thought we would not need some features claimed when the product was sold. Or the time a multi million dollar project went up on a commercial Unix because they promised kernal based threads by version 8.0 and as far as I can tell they never got beyond Posix Threads. At version 10.0 we went to production anyway with at least a year of additional development to do our own thread safe coding.
When it comes to support from the commercial products or Open Source I will almost always choose the open path. The support is simply better.
I believe you failed to factor in the time spent by staff helping the company providing support. I have rarely seen a support package at $8,000 a year that does not bill for hours (trust me, they will find something billable). In addition, they usually need one of your support staff to help them while fixing any problems. They will also charge for non-support related customizations, the ones your paid staffer would be doing with 1/10 of their time. In short, I do not believe you are factoring in the total cost of the outside support contract. Remember, always read contracts thoroughly.
We have a relatively large development shop. About 600 developers. We spend tons of money on commercial software.
The quality of support we get varies greatly from vendor to vendor.
Almost always you have to recreate the problem in order to gather the needed diagnostics or to be able to test the fix. This takes time. It may be the same for OSS and COTS.
However, more often tha I can count, we have debugged the problem in the vendors code and sent them the fix! Why? We need the fix in a hurray, so we zap our install. We sent them the fix to get it as part of the 'official' code base. Combine that with the previous point and OSS may win.
We had another case where the COTS code was difficult to deal with, sucked CPU, and leaked memory like a sieve. We dumped it and replaced it with an OSS equivalent. It worked like a charm - fast and tight. It has cost us almost nothing to use. If it breaks and can't fix it, we can always revert to the COTS. And we'll be ahead.
Our policy is that we can use OSS where we feel appropriate, but we must obtain an internal owner for ongoing support. We have done well with it so far and will use more.
One thing to watch out for is the licensing obligations with some of the OSS agreements.
This is an excellent set of comments. Your most-likely response from the commercial support gurus 3-4 years from now is that you should really upgrade your software/hardware. So, if the configuration isn't going to be completely static, you should expect the commercial packages to require new purchases 2x over the 10-year life cycle, with things being dodgy during the last year of each licensing term. With commercial software, you're really purchasing a _loan_ of its usage, and the sticker on the box doesn't represent the final cost you'll pay. Good luck.
The initial posting seems to imply that if you
pay for a commercial support contract, then your
internal costs for supporting the product are 0.
Not quite my experience. In most cases I've seen,
when you pay for commercial support, you get answers
with about as much insight as you get on your
average OSS mailing list.
So if you pay 8k/year for your inhouse guy to monitor
the OSS mailing list, this is far better than
paying 2k/year for commercial support, because
you'll still need an inhouse guy (or a contractor)
to stay up-to-date on the product which could
easily amount to the same 8k/year you were trying
to save on.
10 Years is a long time.
;-)
I sold my first commercial support for a GNU/Linux system almost 9 years ago:
http://www.hands.com/100005.png
If they still wanted me to support the versions of software that were installed on those machines, I would, but as it happens in that period they've upgraded from slackware (0.99?? kernel) to Debian all the way through to 3.0.
They've also been privatised and split into three separate companies, two of which still use the grandchildren of these first systems, for which I still provide support.
So, while a national institution like British Coal is now history, we're still around, and still willing to support any version of software our clients wish to use.
Tell me a single proprietary vendor who would make the same claim (about historical support), and I'll send you a cookie
Also, when you phone us, like most Free Software firms, you get to talk to someone that actually knows things.
Call a proprietary vendors support line and you'll generally get to talk to some poor sod who is living the nightmare of a call centre, reading pointless scripts at angry customers. This does not generally do much for your inner harmony, and it almost never fixes the problem.
Debian: GNU/Linux done the Linux way