Open Source More Expensive In the Long Run? 736
"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!"
Generalizations not appropriate (Score:5, Insightful)
The thing is, each analysis is going to be different because no two scenarios are the same. Any blanket statement that OSS is cheaper or OSS is more expensive is necessarily incorrect.
Re:Generalizations not appropriate (Score:2, Insightful)
Re:Generalizations not appropriate (Score:5, Funny)
Nice generalization about generalizations.
Re:Generalizations not appropriate (Score:5, Insightful)
#1. To compare a on staff expert to a "support" contact is a crime. The on staff expert will be constantly physically available, adding features and fixing bugs, as well as working as an internal evangelist for his/her pet project. You will get massively better support from a expert on staff, and he will be honestly accessable to everyone at the company/agency.
#2. What is your plan if the company you purchased from goes belly-up? Refuses to support the next version of XYZ, or generally ignores you. If you read your contract carefully, you will realize you can do _nothing_ except go to another product. With open-source, you have the right to modify and "grow" the product as you see fit, and that right can never be taken away. If you need to make a change, at least you have a chance.
You said "They just want to have a certain comfort level, even if it is illusory.", and that is exactly what you need to avoid. It is a lie. Read the EULAs and agreements, most companies offer no support, have no liability and have the right to take back their software at any time.
The problem is we are not attacking the problem (misunderstanding of what rights a company has based on buying software and signing the EULA), we are attacking a symptom.
You have to attack the "illusionary comfort level", because it is just that, illusionary. You can't let them go on believing thier own lies, it makes the entire process you went thru to find the best value for a product a total fraud because of incorrect assumptions.
Re:Generalizations not appropriate (Score:3, Interesting)
You said
Now I've had my share of bad experiences with support, but I still think in this case external support is the best way. Please bare in mind I'm assuming the vendor provides real support, and isn't some 20 person software shop that has one of the developers on-call.
Your staff member will go home at the end of the day. Are they going top be on-call 24 hours a day? Are they ever going to go on holiday, or get sick? A professional support offering will have some one to answer the phone 24 hours a day, and will have enough staff to make sure one of them will always call you back.
Your second point is valid. The support provider might not be there next year. The product could be sold, and the new owner might want to charge 30% more for support (happened to a former employer). But if you have support in house, what do you do when you 'expert' finds another job? You have to either find some one with experience in that product, or train someone up. In the mean time, you have zero-zip-nada support.
Professional support is like insurance. Most of the time you pay a lot more then you ever get back, but its there when you need it. That is why companies pay a fortune for support, and a reason why RedHat is popular with business.
And that the key, they are going to pay for support. In the case I mentioned above, about the product that was sold, one company charged 15% of the purchase price per year for support and maintenance. The company that bought the product charged 20%. For that you get free upgrades, and the right to ring up and have some one help you with problems you might have with the product. They won't be able to write a patch on the spot, but the person you are talking to knows the product very well, and you can ring them ANY TIME of the day or night.
The think that stood out in my mind when reading this article is how little they thought the support would cost them. I would expect the support cost to be a lot more then 10% of a FTE, I mean, that's like 4 hours a week!
Re:Generalizations not appropriate (Score:3, Insightful)
I don't know where you pull you experience from (sounds like big hardware venders), but the world of software tends to be nightmarish for support.
No one who is any good (at damn near anything) wants to be phone tech support, no one, and even fewer good people are willing to work in the middle of the night, and even if they were willing too, they would expect ALOT of money.
I would kill to have access to the actual developer in a 20 person development house. I promise you I would get much better support than "Vat" from India, or "Chung" from S. Korea, who work at large phone answer centers that take hundreds of calls for hundreds of products.
I stand by my initial points.
Re:Generalizations not appropriate (Score:3, Interesting)
Funny you mention that... I work for a company that greatly resembles that scenario. And I'm the "developer on call" for nearly all of our products 90% of the time. Our customers are always amazed at the level of support they get for their money. In fact more than once I've supported other vendors products because of unresolved issues on their end.
Re:Generalizations not appropriate (Score:5, Insightful)
The thing is, each analysis is going to be different because no two scenarios are the same. Any blanket statement that OSS is cheaper or OSS is more expensive is necessarily incorrect.
Excellent point.
Another point to keep in mind: for your $8,000 a year, you'll get (well, not for the first 6 months; but eventually) an expert in the product who has access to the source code and so will be better equipped to track down problems. Odds are that most of those support contracts will not provide you with an easy contact to someone with that kind of expertise (certainly I doubt most hell desk support personnel who work for closed source software vendors have access to the code, let alone can understand it).
Re:Generalizations not appropriate (Score:5, Interesting)
Obviously this varies from company to company. And of course there are plenty of Open Source programmers who may do this for you for a fee.
The point is though, as the original poster pointed out, you can't generalize. When investigating commercial software you really ought to find out about their bug support. Find out if the programmers who developed it still are with the company. Ask for other customers you can contact for feedback on how the company responded to bugs. Many commercial companies, especially in these economic times, will bend over backwards to accomodate *reasonable* requests. If you are a large contract they may even be willing to do some custom work for you.
The problem with a lot of Open Source software is that it may take longer to get up to speed on it. Typically you may find it difficult to find consultants who are familiar with the software. Likewise the authors of the Open Source software will typically have day jobs to pay their bills and are unable to deal with technical questions in a reasonable time frame.
If you think you'll need a lot of help you ought to contact a consulting group and then use what they use. (You're paying them for their technical expertise) If you do it yourself, then factor the learning curve into your costs. However with some larger companies (i.e. Verity or the like for text indexing) you may not get the hand holding you need, adding to your costs. On the other hand if you work with a consultant then a lot of that disappears.
The ultimate point is that there is no simple answer. It depends upon what software you are using and what you are trying to achieve with it. In some cases Open Source is vastly superior. Generally if there are a few O'Reiley books on the software, you should be OK. There will likely be answers there and on the net. If not. . . Well think through carefully what all the hidden costs actually are.
Re:Generalizations not appropriate (Score:3, Interesting)
Just to provide an isolated data point, last year I was involved in a project that required myself and a colleague to use a certain piece of network management software. The product had already been selected by the client, so it was a case of "Just make it work."
One critical requirement was the ability to process a certain amount of billing data within a 24 hour period. The software, running on a test server, couldn't get through the volume of data fast enough. The vendor told us that we need a faster box/one with more CPUs. We were suspicious.
In the end, we managed to reverse engineer the software to the point where we realised it was written single threaded, and so unless we could find a vendor making roughly a 9.5GigHz SPARC chip, the software couldn't process the data. It took two separate phone conferences with the development team to convince them that their software couldn't do what they said it could.
I agree with all the other statements that essentially advocate using the right tool for the job. And remember, if something doesn't break, you won't need support.
Re:Generalizations not appropriate (Score:3, Interesting)
And when he leaves, you've another 6-month window while another developer gets up to speed, then when she leaves...
If I'm a sprocket wrangler then by business is wrangling sprockets, not maintaining software. Having someone on staff whose job it is to maintain a piece of infrastructure technology makes about as much sense as keeping a cement mixer around just in case you need to repair the parking lot. One of the fundamentals of a modern economy is specialization; software specialists write and maintain software, sprocket wranglers wrangle sprockets.
Not to mention that Sprocket Wranglers, Inc are not going to spend their time and money to develop and distribute GNU/Sprocket for free because it would simply be used by tbeir competitors, Acme Wrangled Sprockets!
Open Source can be useful for things that work the same everywhere, like SMTP transports for example, but it cannot be used for any software that people use to run their businesses.
Good point, but generalizations still dominate (Score:4, Insightful)
Usually, the answer to this depends (in a completely predictable fashion) on who you ask. Ask Microsoft (to pick an example at random), and the answer is "Yes, absolutely". Ask an Open Source advocate, and the answer is "No, absolutely not".
The parent comment makes an excellent point: neither of these extremes can possibly be correct in every case, so there's no need to get all worked up over this or that example in which one or the other turns out to be cheaper. The fact that you're able to choose between alternatives based on their total cost is a Good Thing. (It's not an ability that everyone necessarily wants you to have, but I won't pick a random example of a company that might not want you to have that choice.)
Re:Generalizations not appropriate (Score:3, Insightful)
This is trivially true. However, a particular case can be an indicator of the general state of affairs. Especially if, to take this case as an example, the difference between lifetime costs for an open source system and a proprietary appears large. Also, general principles can sometimes be seen to be at work, and they might lead one to, rightfully, believe that extrapolation is appropriate.
An analogy might drive this point home. Say that you have founded a dot-com. You intend to make money by having advertisers. However, it soon becomes obvious that this will not work, and you have to close up shop. Now, from this single example, is it reasonable to draw the conclusion that a revenue model based entirely on advertising is usually flawed? If you think it through, you might realize why an ad based revenue model usually doesn't cut it, and then it is fair to assume that things might be similar with all ad based dot-coms. Thus you can generalize from one case only. In the same vein, if the results are clear enough, it could be argued that it is reasonable to draw the same conclusion in the case of open vs. proprietary, i.e. open source is usually more expensive in the long run, because the running costs of open source are so much greater than the initial cost of proprietary software. And this is likely to be true with most systems.
The thing is, each analysis is going to be different because no two scenarios are the same.
This is true. But if no two cases being exactly alike would prevent us from formulating hypothesises of general states of affairs there wouldn't have been much progress in anything ever. This is not an argument.
Any blanket statement that OSS is cheaper or OSS is more expensive is necessarily incorrect.
It could not possibly be necessarily incorrect, as it could be true. Potentially incorrect, yes, but not necessarily.
Note that I'm not saying OSS is more expensive. I'm just pointing out that if anyone's making blanket statements, it's you. Why in such a hurry, and why so angry? Did someone step on your toes?
Re:Generalizations not appropriate (Score:3, Funny)
Software not free as in beer! News at 11. (Score:4, Insightful)
Of course there are cost implied by any software. Saying that Linux is free doesn't mean it didn't cost anything to produce. And if you need customization of free software (or open source, or whatever you call it), well you are going to have to invest efforts and/or money into it.
Re:Software not free as in beer! News at 11. (Score:5, Insightful)
Exactly, and this is how open source can become more expensive than closed source. Here's an example from a project I am doing. It will be a hardware and software combo, we ship it as a unit so we can define the entire platform. We have a off-the-shelf mobo from a major overseas vendor. Everything works fine with Windows. However, we wanted to use Linux. None of the distros have a set of drivers that work reliably with this set of hardware. Sure, we could pay some driver gurus, or we could build the product on Windows. Looking at the cost analysis, we either pay someone for Linux driver work up front and wait for it to be done, or we ship now with Windows and pay Microsoft the same money over time. The installment plan is looking pretty good.
It would be great if hardware vendors placed Linux drivers high on their priority list but right now they don't. That alone places Linux at a disadvantage.
One benefit (Score:5, Insightful)
With open source if the devo team quits, folds, or stops supporting their software you still have all the information to continue to use and improve the software you're using.
I don't believe that makes open source more expensive, I believe it makes it more flexible.
Re: (Score:3, Insightful)
Assuming it is legal to read their "open formats" (Score:3, Insightful)
Word had the capablity of saving as
Exporting
Portable, open, unlicenced "save as xml" will no doubt be an option, but one that NO Office user will use, either out of ignorance, or out of frustration that the output is either hopelessly munged/unreadable, or simply isn't representative of the actual document's formatting.
Re:One benefit (Score:3, Insightful)
It is likely that Microsoft's XML-format files will, in fact, be proprietary in nature. Remember, XML does not imply open, but, instead, it implies structured. Microsoft can use a proprietary DTD along with binary encoded data in between tags to make the Office 11 format no better than any current or past Office file format.
Re:One benefit (Score:3, Insightful)
Sigh.
I really wish people would get a clue about XML.
The following is valid (more or less...enough to make the point) XML:
Now if you think you can write a filter that can translate the above or something like it into a useable document without inside information, you're welcome to try. But you'll have no more success than you would if you were trying to reverse engineer the current Word format.
The fact that a document is in XML doesn't mean shit, and I wish people would get that through their heads.
Re:One benefit (Score:5, Insightful)
This argument presupposes that companies want or are able to support the staff necessary to "continue to use and improve the software you're using". Most do not.
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. Why ? Because the costs associated with the (miniscule) chances of a Microsoft going under and abandoning (say) Office users whole-hog are very small compared to the costs associated with having to take on a developer or three to maintain some open-sourced program whose chances of dropping off the radar screen or having its developers lose interest are much, much higher.
Re:One benefit (Score:5, Insightful)
In the commerical software world, you cannot use the same product for 10 years. You will purchase upgrades, and you will purchase new hardware to run those upgrades if you want support. Why? Because any company that doesn't make you do that will be bankrupt in 10 years.
Depending on what you're doing, the support issue can fall either way. If you want to set up a dedicated system which you want to just sit and run doing the same job for 10 years, I'd argue that open source is probably the right tool for the job. On the other hand, if by "support" you mean a continuous stream of upgrades and feature improvements (whether you want them or not), than a commercial product might make more sense.
Since in this case, it sounds like what's being spec'ed is just something that needs to sit and work for 10 years open source is the perfect fit. I suspect that after a couple of years of stable operation, the ongoing support costs for the open source solution would drop to near zero.
Re:One benefit (Score:4, Informative)
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.
Re:One benefit (Score:3, Informative)
"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.
Re:One benefit (Score:3, Insightful)
Bzzt. FUD alert. Who, exactly, is moving to temporary software licenses? It's common practice in the commercial world for vendors to issue temporary software licenses until the customer has paid in full-- when you're selling $500,000 cuts of software, it's common for the customer to choose the installment plan-- but at that point, the customer gets a permanent hardware or software license key.
So where do you get the idea that "todays [sic] software companies" are starting to move to temporary licenses? Microsoft has never sold software with a temporary license. Under Licensing 6.0, companies can choose to accept a mandatory upgrade agreement in order to keep up-front costs down, but you can still buy a permanent license for any Microsoft product if you want it.
With open source if the devo team quits, folds, or stops supporting their software you still have all the information to continue to use and improve the software you're using.
Technically that's true, but most companies would not exercise that option. If their open source software vendor-- or guy in his garage, or whatever-- closed up shop, they'd either keep using the software without any support at all, or they'd choose different software. The burden of having to basically start an in-house software engineering group to maintain and modify an abandoned open-source program is pretty unreasonable for most companies.
Re:One benefit (Score:5, Insightful)
This is obviously dramatized a bit, but still. The argument that open source is open and can be changed is very misleading. Any programmer time is exremely expensive. If you fix that bug yourself, it will almost definitely cost you more than that program off the shelf.
I went on some tangents, but it is clear that open source CAN cost more than off the shelf software, and has similar pitfalls to off the shelf software.
Re:One benefit (Score:3, Funny)
Re:One benefit (Score:4, Insightful)
Documentation created today should be readable tomorrow and ten years from now. Is that true of Microsoft Word or Powerpoint? Now, how about text, LaTeX, and Open Office? I do believe that Word is the most dangerous file format invented...do you know how many companies have all their documentation in Office formats? Wouldn't they feel safer knowing that their documentation isn't fundamentally bound to one company's products? Unfortunately, they don't think about such things. Perhaps that is darwinism on a large scale.
Re:One benefit (Score:3, Interesting)
Re:One benefit (Score:4, Interesting)
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.
Re:One benefit (Score:5, Funny)
- Apache
- XFree86
- Linux kernel
- FreeBSD kernel
- Gnome
Damn, I ran out of fingers. Let's try the other hand.- KDE
- Mozilla
- ReiserFS
- The TCP/IP stack itself, typically implemented in most OS'es off of BSD's source, including even Windows.
- RCS and CVS
Okay, Hold on, let me take my shoes off. Sorry about the smell...- This little piggy runs DNS Bind
- This little piggy firewalls with Drawbridge
- This little piggy edits text with vim
- This little piggy edits text with emacs
- This little piggy runs sendmail (yeah, it sucks compared to newer mail daemons, but it most certainly counts as "successful".)
Now the other foot:- This little piggy uses gcc.
- This little piggy uses Perl.
- This little piggy uses bash or tcsh.
- This little piggy uses Python.
- And This little piggy uses Slashcode to claim Open Source projects aren't very successful.
Okay, I'd better stop. I've almost run out of appendages and you really don't want me to use the twenty-first one.Time (Score:5, Insightful)
Also, unless you spring for one of the higher levels of commercial support where they actually do it for you, you're still going to have to have someone to actual make whatever changes the support people recommend. So on top of the support contract cost, you'll have a time cost as well.
Re:FTE is? (Score:3, Insightful)
Its all Relative (Score:4, Insightful)
My Answersly (Score:3, Funny)
Secondly, there are many people availablely for open source consulting (or consultingly, dependingly on your area). A simplely google search could have told you that. Er, ly.
Doesn't take into account the company stability (Score:5, Insightful)
If you have the code, though, you can guarantee that your costs will never rise, because you can maintain a knowledge of the system yourself, and do your own maintenance when nobody else is available to do it for you.
That alone burned us a couple of times - closed-source products dried up and we couldn't get them expanded to work with new products, like our help desk system that would only work with MS SQL Server 6.5, not 7 or 2000. The company (cough)McAfee(/cough) stopped supporting it, and the ownership costs started to skyrocket - we had to maintain a separate SQL server for it, had to manage its backup & restores separately, etc - and we figured out we'd be better off building our own or using an open-source version.
Now, we don't worry about what happens to the company that owns the code, because it's freely available. It's hard to put a price tag on that until you've been burned.
Re:Doesn't take into account the company stability (Score:5, Insightful)
How's that? Has your staff been active in understanding the source code? If not, then there is a ramp up period while you get familiar enough with the system to be able to make substantive changes to it. Not to mention the inevitable mistakes that will be made along the way. There is most definitely a cost associated this. Picking up a software project always incurs an increased cost, whether it's an OS project that got abandoned, or an internal project that has to shift over to the "maintenence" group who has never seem it before.
Re:Doesn't take into account the company stability (Score:5, Insightful)
That's a huge understatement - we've actually made so many improvements that it's hardly recognizable from the original code.
Not to mention the inevitable mistakes that will be made along the way.
If you're implying that closed-source products don't have mistakes, I've got a McAfee license to sell you.
Re:Doesn't take into account the company stability (Score:3, Insightful)
Out of curiosity, have you had to do any major merges with the main project? Or were you able to merge back into the project tree?
If you're implying that closed-source products don't have mistakes
How is that? What did I say that implied that? Is simply saying that one tends to make mistakes dealing initially with code you don't fully understand somehow saying that proprietary software is bug free? How did that leap come about, or is this more of the "yer either for us or genst us" attitude?
BTW, your right about McAfee, one of the biggest pieces-o-crap ever to run on a microprocessor. No matter how many times the IT nazi's installed it on my old computer at work, I'd just simply uninstall it after they left my desk (and I'd tell them just that before they even bother to install it, again). But then again, I think that almost all major *nix OS's are bloated pieces-o-junk (just referring to the bloat, not the functionality) as well, from a software design/implementation point of view. So take it for what it's worth.
Ramp up Re:Doesn't take into account the company (Score:3, Informative)
And getting bugs fixed in a commercial product varies from 'if they feel the have to' to 'impossible'. With open source you have the source code, and you may be able to fix it yourself.
Costing is a black art! (Score:5, Insightful)
1. Be more stable and contain less bugs in the long run
2. Cost less in terms of licensing etc
3. Have projectable license costs. ie Nil. Whereas who knows how much Micro$oft will charge you in a couple of years.
4. Gain from *not* having to upgrade due to it no longer being supported. Proprietary software forces you to upgrade and infact is built into their model. If you don't buy they go bankrupt
5. Allows you to *gain* from quick bug fixes, security patches and the like
This seems like a typical TCO attack on Open Source which needs to be carefully assessed in a research setting where the differences can be clearly ascertained between proprietary and Open Source software..
Go to the mailing list ... (Score:5, Insightful)
"It depends" (Score:3, Insightful)
Shameless plug: My company offers professional PHP support via phphelpdesk.com [phphelpdesk.com] (PHP itself and most of the packages around PHP, including Apache, MySQL, etc) as well as hands-on training courses. There are other companies that provide similar services for other languages (probably more for Java than PHP, for example).
What are the lifetime figures used ? (Score:3, Informative)
OSS Myths, Volume III (Score:3, Troll)
It's time for that myth to die.
Companies are in business to make money. Linux was and continues to be front page news--people know about it. So, while this article may get hundreds of yelling and screaming "point of fact" replies, it seems that many companies have tried OSS software (or at least costed it) and have come to the same conclusions--in the long run, it's at least as expensive as commercial equivalents.
And I'm coming at it from a number of standpoint standpoints:
remember the old saying:
"It's only free software if your time is not worth anything."
Amortization is key (Score:3, Insightful)
First off, on an annual basis 1/10th of an FTE is probably excessively high. That's 4 hours a week devoted to being the support guy for this OSS product by reading mailing lists and maybe doing a little patching. When new releases are deployed or new security bugs found or whatnot, you *might spend* 4-8 hours that week, but I bet most weeks and even most years it takes far less time. Another thing to consider is that some of this time spent supporting (and learning to support) a peice of OSS can be amortized with the costs of supporting other software. In other words, once you get one guy trained in the workings of the OSS world (where to find FAQs, how to address people on technical mailing lists, simple source patching, etc), he can apply those skills across the board. Proactive support in the form of watching for new bugs and security reports gets clumped together by BugTraq et al.
If I were in your position of making the support cost analysis, I'd probably put it at more like 2 hours/week on average the first year, and dropping to 1 hour/week on average the remaining years. This should place it around the same $$ as the commercial options. This is assuming this is the only OSS around. If the same department picks up a few more OSS support tasks, they can lump them into this one guy and drive his cost per peice of OSS even lower.
Perhaps rather than a new business model, large companies should create new positions called "OSS Support Engineer", and hire linuxy geeks who know this world to sit in and be their in-house mediator between their developers/admin and the mailing lists and authors of the OSS.
What Support? (Score:4, Informative)
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.
Open Source Is Not a Monolithic Thing (Score:4, Insightful)
What does commercial support really get you? (Score:5, Insightful)
Let's set the way back machine back about the same number of years, let's say to 1994. You develop an application and buy hardware....
Your Linux solution is running a pre-1.0 kernel on a box that runs under 100Mhz. If you need to recompile it to work on new hardware and OS when your old system bites it, you can.
Your Windows solution is running on Windows 3.1. Good luck getting support for it. If you are willing to pay for a whole new development cycle, you reinvented it for Windows 95. Good luck getting support for it. Ditto your upgrade to NT4, which also required all new hardware.
The cold hard truth is that when you're looking at a long window, you MUST have FULL source or you're hosed. At some point you're going to need to run on hardware that's no longer being made, or your hardware will require some driver that you can't get without upgrading your OS, etc.
Who Needs Support? (Score:3, Interesting)
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?
Re:Who Needs Support? (Score:3, Interesting)
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?
When you use OSS you don't need to wonder how the software works. Everything it does is spelled out in the source for you. Even with poor or no documentation a good coder can still review the code and understand how it works. That same good coder can then add any features you might need.
So, as you say, you shouldn't need support when you have the source available if you have someone on staff who can read and understand the code. However, like any good coder, you can get stuck, even with the source code on hand. It helps to have someone else to bounce ideas off and I find it really helps when designing new features. I tend to think of lots of different ways to implement new ideas and but have trouble deciding on which is the most 'correct' route to take.
And during those times I call on support. Be they other programmers on staff with me, programmers I used to work with but still keep in contact with, those weird coders I 'met' online, or even that kid who delivers our pizza. Just like your tech support hotline staff they may not know the product I'm working on very well. But their experience in coding or even their common sense might be all I need to get back on course.
So, I tend to use support all the time. Even if I did find some of that support via google groups with some good investigation and troubleshooting skills. It's just not commercial support, which is probably your point anyways.
Can be (Score:4, Interesting)
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.
Comfort level of vendors (Score:4, Insightful)
Have you also factored in support contracts, and that products purchased, may be EOL'd, and force upgrades to continue being supported. These forced upgrades could then have a trickle-down effect of increased license costs, licensing changes, and increased hardware costs (new servers).
Not to sound to OSS Zealot-like, but by having the source code, you own it for the life of your project. With a third-party vendor, you are ate the mercy of the vendor's support staff, and development.
I'd say take a closer look on support costs, licensing upgrades, and the products being EOL'd and forcing upgrades.
Try getting support from commercial vendors! (Score:4, Informative)
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?
Faulty Logic (Score:5, Insightful)
But, in any case, if they have an employee who can shoulder the burden of maintaining this product without adversely impacting that employee's performance, then internal support costs nothing at all. Plus, there are very few commercial products that are guaranteed support for even a few years, let alone 10. Sure, support this year is available at a reasonable cost; but there's a good possibility any random company will go out of business within the next ten years, or they may drop support for that product.
With open/free software, you have the chance to maintain the product yourself, long after the original producer has dropped support.
Re:Faulty Logic (Score:3, Insightful)
Also, you are going to need someone at your site supporting the software anyway. You can't just call commercial support, leave a message that it's broke, and have it be magically fixed the next day. You have to call the support line, explain the problem, go through troubleshooting with a technician who didn't actually write the software, and then apply the fix or wait for an upgrade and install it.
It may take a little time at first for a staff member to become familiar with an open source project, but he will then be able to fix the problem in as much time or less than he will spend on the phone.
I don't actively contribute code to any open source projects, but I once found a bug in some open source software I was using. I had never looked at the source before but was able to verify that it wasn't a known issue, find the bug, fix it, test it, and send a patch to the maintainer in about an hour. You wouldn't believe how grateful that guy sounded to get a patch instead of a complaint from a user. I'm sure he would have been helpful if I had further questions. If it had been a commercial product I would have spent that hour on the phone, only to be told that it would be fixed in the next service pack.
Bottom line is, don't overestimate what you actually get when you pay for "support".
Economy of Scale: Support (Score:3, Informative)
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.
And what happens when... (Score:3, Insightful)
What does 'support' really mean? (Score:5, Insightful)
Too many times we've paid for support from a vendor, only to discover that the problem(s) we've encountered are beyond their ability/desire to resolve...and we've been stuck with a useless product...
At least if the product was OpenSourced we'd have the option of subcontracting the fix to a thirdparty rather than having to dump it and find something else.
24x7 Tech Support just means they'll answer your call...not that they'll fix the problem.
Just my 0.02c
Finding Good OSS support (Score:3, Interesting)
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...
Let me guess... (Score:3, Funny)
Different estimation (Score:3, Insightful)
Try this instead
Learn the product comletely. 1 FTE * 2 Weeks 2 weeks = 2/50 (roughly) so 80K/25 or 3.2K one time. Ignore installation customization, since you will have to do that for any product. Assume four major crisis the first year where that person spends 2-3 days dealing. 80 hours / 2000 (roughly 2000 working hours per year) or 4% again of 80K $3200. Subtract from that the time this same person would spend on the phone with the support staff, etc etc and I think I'd be willing to shave that estimate down by a day at least, so say $3000. So your up front costs are 6 Grand. Assuming that crisis moving forward are less frequent, say one weeks worth a year, your year total will be $1500. So you are looking at a total cost under 20,000. or 2000 year
Mistake... (Score:3, Insightful)
You're figuring on 1/10 of a full-time engineer to support the search engine. Do you think that with a commercial product that you can devote NO engineers? Even with a commercial product somebody has to keep tabs on things. Even when you buy support, the support engineers don't typically call you and remind you of bugs or do any of the work.
You'll need to dedicate time to the product regardless, and in some cases more time to commercial products.
Open Source Support (Score:3, Insightful)
Hmm. I guess someone is either making a lotta of money in this down economy (& doesn't know anyone scrounging for work), or is still in high school & has never wanted for toys.
I'd suggest that you try a few mailing lists or look at a couple of websites. There are lots of folks out there who are both skilled & looking for work, & who would be more than happy to offer you a quote.
``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!"
Well, figure again that if you have any kind of enterprise-level software running, someone will have to spend some time monitoring the relevant mailling lists, periodically checking web sites for patches, et cetera. 0.1 FTE works out to being 4 hours a week . . . which seems to me twice as long as it would need. But whether you buy something from Microsoft, Oracle, Sun or download & install an Open Source solution, this constant amount of research needs to be done.
Expecting the support arm of any company to do all of this is foolish. While they will have access to resources you won't have (defect databases, source code), from my experience unless you pay a lot more than $8,000/year the support you'll get from them won't be much better -- & may be worse -- than what you get from the mailling list run by the users.
And if you pay a consultant with the expectation that she/he will do all of this & none of your staff, all you are doing is allowing someone to acquire job security at your expense.
You're going to have to allocate the FTE for maintaining this project no matter which way you go. And you'll have to convince your bosses of this fact.
Geoff
Two points (Score:3, Interesting)
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?
Ten year lifetimes and proprietary apps (Score:4, Insightful)
You claim that it's a requirement that this system would have at least a ten-year lifetime. Did you get commitments from the software vendors that they would support their product for ten years, or help you transition to a replacement product? Companies regularly terminate unprofitable products, and in some cases they withdraw timed license keys, with the effect of causing deployed systems in the field to cease to work.
If not, then the only option for you that you can be certain of maintaining over a ten-year life is the open source option.
OSS phone support (Score:5, Funny)
Its True! (Score:3, Funny)
Too sensitive to initial conditions (Score:3, Interesting)
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.
TCO or support costs? (Score:3, Insightful)
What is Omnipage Pro up to now? version 12 or something. To maintain those "cheaper" support costs you have to keep buying the newest version.
Two modest points... (Score:5, Insightful)
First, what is the probability that the commercial vendor will still be in business, supporting the version of the product that you want to use, in 5 years? 10 years? 15 years? Vendors typically have an end-of-life schedule and forced upgrades for products. Going through an upgrade, particularly an unwanted upgrade, can be just as expensive as re-writing the product from scratch.
There are a few very large systems vendors that have been in business for a long time and will commit to supporting any version of a product. Typically such contracts carry price tags that increase at least to the power of 1.5 per year. At least. Used to work for a company that paid for support on a 1950s vintage application (in the 1990s!). The cost was a significant percentage of their total revenue.
However, there is also one very large system vendor that has a habit of buying marginally successful software vendors, milking their support contracts for three years, then terminating the product. Do you have guarantees that won't happen?
Second, you make it sound as if when a problem occurs with the commercial product, you pop a punch card in a slot and *bam* a solution appears.
In fact, handling the vendor/support relationship on complex commercial products is an art and can easily become more than a full-time position. Software vendors have to be managed in much the same way that pre-teen children do: encourage them, praise them, lead them toward answers but don't do their homework, pick up their laundry off the floor, and discipline if and only if necessary. That is not an easy job, and one that generally takes a lot of time (again - just like children). Finally - what does your client do when the vendor just refuses to fix a problem? Which they will, eventually: "Sorry. Working as designed. Submit an enhancement request.". What now?
sPh
Ignorance (Computer Illiteracy) is Expensive (Score:3, Insightful)
Personal Experience (Score:3, Interesting)
- Software I know inside and out
- Software I know little about.
Software I have played with and know I can support with little to no problem. That a given for any IT person, open source or commercial software. I don't need the community support or commercial support. The knowledge is all there. Admittedly this is most likely less then 1% of the open source projects in the world. But I can make that 1% sing symphonies. So those projects are cheap, easy to setup, and usually just a download away.Now there is the software I don't know a rat's ass about. New and different software that can do things my old packages just can't. The software maybe well documented but you will run into problems that just aren't in the documentation. Since it's open source I don't have a tech support number to call and cry to. At best I have a user group that I have to keep hitting refresh on and hope someone answers my question sometime this year or a barely used IRC channel with abusive RTFM 'experts' flamers. So I would have one hell of a learning curve on that project and a ton of man hours.
Also factor in the fact that the average IT career last about 3-4 years. What will your company do after you leave? Someone else will have to start the whole learning process all over as well as you own personalizations. Even if you get one of those "Less than 1%'er" the still have to learn how you think.
Commercial software always has at least a certain amount of dedicated support staff as well as a community who uses that software. I'm not trying to sway anyone to commercial or open software. I use a mix of both. There are the facts as I see 'em.
This rant was brought to you by Open Office 1.01.
RTFM is a legit reponse (Score:3, Interesting)
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
Monetarily more expensive perhaps... (Score:4, Funny)
Soon we will rid the world of all commercial software and open source zealots will rule the land.
"In breaking news today October 2, 2010 Mr. Stallman the leader of our free but not as in beer society has decided that we will be required by law to refer to him as GNU/Stallman. For those who fail to do so will be required to attend a course on proper acronym usage and application and could be fined up $5000.
In other news Bill Gates is still trying to figure out how Microsoft could have lost $40 billion dollars. Rumor has it that a Stallmanite hacked the
A gunshot rings through the news studio as a Stallmanite assasinates the subversive news anchor for his obvious attempt to tarnish the good name of our leader GNU/Stallman.
Viva GNU/Stallman
The author answers: "Why 10%?" (Score:3, Informative)
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
Re:The author answers: "Why 10%?" (Score:3, Insightful)
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).
So, let's say that when there is a new guy assigned to support, or whenever there is a problem, doing support eats up the entire 40 hour week. That seems a little high, but it's plausible. So, there must be either a new guy or a problem every 10 weeks to get to the 0.1 FTE. That's NOT plausible.
My guess is that once things get going, there won't be any troubles from one year to the next. When there is a problem, it will probably be along the lines of: ``How do we get this old turkey to work with our new Whizz-Bang 5000?'', and that sort of problem is likely to be expensive, whether you've gone proprietary or libre. With a Libre software solution, it is likely to be solvable. With a proprietary solution, the vendor's reply is likely to be: ``You don't. Replace your reliable old system with our new, proprietary, Gouge-You-Deeper product.'' There goes your 10-year minimum lifespan.
My guess is that the in-house costs for support are going to be about the same either way you go. Someone is going to have to be up to speed and able to ask the right questions if things go sour, no matter what the license and no matter what you pay for outside support.
I supspect that if you offer money to the developers, you will find one or more of them would be happy to contract to be available to fix problems as they arise. If you can't make arrangements with a developer, anyone who cares to spend some time learning the program can do the same job for you. You will be able to negotiate mutually beneficial terms if you go this route. If you get support from a proprietary vendor, you won't. You'll find yourself paying a lot for a little, until they decide to raise support prices and make you buy a new product. I've seen this done.
Re:The author answers: "Why 10%?" (Score:3, Interesting)
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
Apps without support? (Score:3)
For all of the major apps, you can purchase support at competitive prices, which is much better than the built-in monopoly support you get when you buy proprietary software.
If you don't have support for a particular piece of software with which you need help, you can hire a guro at competitive prices. Again, cheaper than the monopolistic support you get with proprietary products.
You are charged for support for proprietary products. Its either built into the cost of the software, or you pay extra for it and its built into the cost of the software. The money it takes to hire techs doesn't come out of thin air. Either you're paying for it somehow, or the company is subsidizing it with another revenue source. I.e., a software company subsiziding support for a minor product from revenues from a major killer app. Either way, you're paying. And you're paying in what is effectively a monopolistic market, since no one other than the company can provide adequate support for products, as you need the source code and familiarity with it to offer acceptable support.
With OSS and FS software, you get support at competitive rates, not monopolistic rates. Overall, its cheaper. You're also likely to get better support, as these guys aren't bound by idiotic "return to the default before you proceed" mandates. Have you ever called up MS for support on Windows? Here's how it goes:
"Oh, you're having problems with X...what did you install last? Ok, uninstall it. Still doesn't work, ok, do A, B, C, D, E, F, G. Still doesn't work? Well, our agreement states that that's all I can do for you. The only thing I can do for you now is have you uninstall the entire program and reinstall it. You'll have to download updates over again. Oh, you reinstalled it and it still doesn't work? Well, I'm not authorized to help you any further. The only thing I can do is guide you through reinstalling your operating system, since there must be somthing wrong with it."
This is the kind of crap support you get from proprietary vendors. Whenever I've called up a proprietary software vendor or an OEM for support, I've never gotten anything that I didn't already know...they just read from instruction books. If, on the other hand, you pay for support in a compeitive market, you get it firstly at a better price. Secondly, you also get better support, as no one could get away with doing that crap. In other words, you get a real software problem solver (guru), not someone who flunked out of Computer Science and is now doing a job which is the computational equivalent of "do you want fries with that?"
Also, when considering the cost of proprietary software, you should also consider the costs of intellectual property problems, and dealing with the BSA. If the BSA even accuses you of something, you're going to lose millions trying to defend against that accusation. It'll cost you alot of money to try to be compliant with BSA standards. And it'll cost you many millions more if you have to reach an agreement with the BSA for compensation because you misplaced some paperwork.
A few incorrect assumptions (Score:3, Insightful)
I believe the original poster makes some incorrect assumptions.
1) It is simply not the case that you will get anywhere close to 10 years support from a vendor for a particular product.
Even enterprise level software vendors only support their software for a relatively short time span. Microsoft and Oracle are two examples of this. Neither of them support software for more than a few years and then expect that their customers upgrade to the latest version. Often at significant cost. Today 10 year lifespan for software is not realistic except for perhaps custom solutions. 5 years is even pushing it. This also assumes the company is still around. Vegas has better odds than that of a 10 year old IT product company making it.
After the 3 to 4 year typical window the customer will probably have tohandle all support issues themselves, or upgrade.
So while the poster assumes that costs will stay static for the commerical solution in fact they will go up over time. In addition the closed proprietary nature of the commercial solutions will often make migration that much more difficult and costly.
This speaks to one of the other major cost saving advantages to OSS, adherence to standards. Commerical software vendors will tend to make "proprietary" changes, or roll their own to lock in customers (AKA competitive advantage), or as a result of them just being too lazy to work with community.
2) Percentage of FTE and lack of additional costs to support commercial products. There seemed to be an idea that you can compare 1:1 the time to support the OSS solution to the money spent on commercial support. This is simply not realistic. You cannot assume that by paying vendor X $5000 dollars that you will not have any costs over an above this $5000 for supporting the system.
Someone at the customer still has to recognize the issue, call the vendor, wait on hold, submit their question, wait for an answer, apply the patch if one exists, or implement the work around. This all takes time which all costs money.
Not that the support process is that much different with OSS, except perhaps that the problems more often actually get fixed, rather than having to wait till service pack 12 that should address that problem, and allow you to discover the next one, which will be fixed in service pack 13. This happens all too often, and with products from major fortune 10 IT vendors with onsite support personnel. Comparable OS products simply do not have these issues for a variety of reasons too numerous to mention here.
3) I also question the 4 hours a week effort required to stay current with the OSS product. I manage multiple open source systems in addition to my consulting work and I expend less than 4 hours a month in supporting them. This includes adding new users, applying security patches, and fixes problems in the extremely rare case they occur.
Someone else posted that the advantage with open source is that you control your destiny. This is absolutely correct. You can install, support, change, upgrade and manage the system to your preference in a way that makes the most sense for your organization. Over the long run this will save you money as you can effectively plan you upgrade cycles around publicly available OSS information regarding new versions and features.
The original poster should perhaps modify their assumptions based on real world experience with OSS solutions and the actual support requirements. I think they would find that overall the costs are much less for many solutions.
A follow-up question might be a description of OSS successes and their ongoing support requirements.
Employees (Score:3, Insightful)
The closed debate: (Score:5, Informative)
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
1/10th of a FTE? Support contracts? (Score:3, Interesting)
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
You picked an extreme example, let me do that too (Score:5, Insightful)
So, I think there are cases to illustrate whatever point one is trying to make. Sure, in your case open source may be more expensive, but that doesn't mean it's always going to be the case and anyone who dismisses a solution on any platform without doing a careful cost/benefit analysis of all factors, shouldn't be a decision maker.
Disclaimer: Yeah, I know exchange does more than just mail... but those applicable functions we nned that exchange does is handled by other server apps we run as well...
This has not been my experience (Score:3, Interesting)
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.
My experience with TeX, PkZip, etc (Score:3)
It is certianly cheaper and easier to buy integrated as opposed to cobble a solution together yourself. What happens is when the integration becomes unstuck.
When I bought XTREE 2.5, it came with integrated zip integration. This allowed one to look inside and work with zip files as if they were directories. Of course PKZIP 2 then came out with a new format, which xtree could not deal with.
When I bought ZTree, it used external versions of these programs. So the unpacker for zip files in ztree is pkzip2 itself, not some some internal routine. So while ztree knows about zip and rar and cab files, actually opening these means that unzip, unrar, uncab must be available.
The are advantages and disadvantages to both approaches. If I go for Norton Commander or FC/2, then Norton Commander has *its* set of inbuilt conversions, while FC/2 uses the same set of utilities that Ztree uses.
Of course, it goes on and on. Word + Windows is a more expensive deal than WP5.1, but the printer drivers live in Windows, not WP5.1, and so Word will have printer drivers long after WP 5.1. Also, Excel can share the same printer drivers and fonts, whereas Lotus has a different printer-driver. Up goes bloat, up goes cost, down goes upgrade-costs.
The net effect is that it initially costs more to buy and install a component system, against an integrated package, but the long term maintenance is less, if it is done properly.
While it is more expensive, both in time and money, to do things in peices, the results are infinitely more flexiable. This may suit the home hacker, but for most office workers, this flexiability adds confusion, rather than confort.
Each process costs more, depending on what you choose to value.
Points missed in the original article (Score:3, Insightful)
- Does the support estimate for the commercial product include the %FTE on your end?
- Up-front vs. incremental costs
- Risks of closed-source
Not that I'm denying that an open-source product must have lower TCO than a commercial project. After all, if you're the only developer/user, your economy of scale is zero. So, obviously, there needs to be some critical mass of user/developer interest before open source support costs start to really drop. Eventually, you end up with apache, etc. where you can get commercial support, etc.In my experience, getting something useful out of vendor support had been a monumentous task. You call up (wait on hold), bluster and technobabble at the first line tech until you get upgraded. Then educate the second-level tech until they have some inkling of what your problem is. They go away and talk to an engineer for between 2 hrs and 2 days. They email you back with the wrong answer. Repeat several times, until your problem gets fixed. This is a significant amount of employee time. Additionally, since your employee doesn't deeply understand the solution, so it isn't well-documented. If you've got an on-staff expert, this whole thing happens in 2 days tops, and you have an opportunity to collect the exact specifics of the problem.
This, of course, doesn't apply if your support contract says that they'll fly out an expert if your situation isn't resolved in under 24 hrs.
The up-front costs of the open-source product are vastly lower than the closed-source, in almost every new-developemnt case. So, what if you took your last 5 years of open-source support budget (presumably this is pretty close to the up-front cost of the commercial solution?) and stuck it in 5-year CDs. Well, at current rates, that's another 10 grand when the CDs mature. No mention if this study took this into account.
These are not insignificant! What is the chance that your product will receive good support 10 years from now? Will the company even be in business? How's Corel doing these days? Remember when WordPerfect was king? Remember WordPerfect Corporation? They sold WP to Novell, who sold it to Corel. How's that for stability? Will One Trick Pony Search Engines, Inc. be around in 10 years? Lots of other posters have brough this up, but this is just unavoidable. Does your service contract specify that you get to choose what version they're supporting? What's your recourse if they refuse to support the version you're using? What recourse do you have if they go belly-up?
Poor Assumptions (Score:3, Insightful)
You've made a couple of fundamental flaws in your assumptions.
For your commercial support, you know you are paying $XX per year. That's a fixed hard cost. You're now comparing that to saying your local support person is going to spend one full day every two weeks doing nothing but reading the lists. Maybe for the first six months, but in year 10? No way.
The primary difference is that you ALWAYS pay the commericial vendor even if the knowledge base doesn't change. Conversely, if you have experienced support staff doing your own support then you only have the _possibility_ of having to pay for training (no updates to the software, what's the tech doing spending a day on the forums?). Figure out a number for the probability of needing to get updated on the software and multiply it times your $8,000, it should drop dramatically. Year 3; spend a generous 2 full weeks training on the product, your costs are halved for the opensource product.
In addition you are comparing hard costs against soft costs. They are not the same. In fact by using external support for commercial products you are adding costs. By using existing support staff's time you haven't added any hard costs. PHB translation: no additional money coming fromtheir budget, no hard dollars leaving the building.
Now factor in the costs of needing to do some custom work in year 5 with a vendor who's no longer in business (and you forget to count in the cost of an escrow service right?). Probably saved some cash there as well.
Ultimately I don't see how an open source product over a long period of time is going to be anywhere near as expensive as a commericial product. If your spin predicts that it will be more expensive, it's time to start asking "how much is it worth to 'own' the code, be able to use whatever vendor we like, only pay if we use their services, and not be dependent upon a vendor's existence in 2/5/10 years'?
The analysis is flawed (Score:3, Insightful)
The analysis would be valid if it was similarly priced "end-user" product that did not require the user to be familiar with concepts and have skills necessary to use mailing lists and documentation, however search engine is not in this category.
10 years... (Score:3, Interesting)
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.
Re:In the long run (Score:4, Insightful)
some pay software is actually the best choice. Granted, not always... I am reminded of a time when a large publishing company I worked for was reluctant to use a whole set of Perl scripts we developed unless they could "buy" Perl. I told them to send a couple hundred bucks to larry but that didn't fly.
Re:In the long run (Score:3, Insightful)
When this is weighed into the equation, I'm pretty sure the TCO changes in favour of OSS.
Re:In the long run (Score:3, Insightful)
While you can look at a SourceForge based project page and see that there is no "company" backing the software, I bet if you had a problem, that one of the 9 developers listed on that same project page would be more than willing to help you out for the price of a large pizza... or even for free if the problem was small enough.
It will take a while for the PHB's to get past the "if it doesn't cost $5000, then it must be crap" mentality, but it *will* happen. Most likely because if you look around you, some of the people you see that are hip deep in the community of free and open source software developers are the next generation of PHBs!
Re:In the long run (Score:5, Insightful)
From my reading of his explanation, he seemed intent on getting commercial support for the software, open source or not. I admit it's valid to want to pay for some assurance that if the software breaks, someone will be on hand to at least try to fix the problem. The OS movement doesn't seem to address this as much as it could; a lot of legit software mechanics could offer their services here.
The OS idea puts more stress on the fact that OS software is less likely to break because of peerage. Your support isn't supposed to have to be commercial; instead, if the software breaks, it's likely already been fixed by someone else, and you need merely get a patch from the same place you got the software. Compare this with commercial software, where you likely have to submit a bug to the company, and wait for the next version to come out, which you must pay for.
It's when your problem is not fixed, that you'll ever have a non-zero cost for OS software. The idea here is to either get your on-staff programmer to fix it, in which case it's already been budgeted - and yeah, I know in this case there isn't an on-staff programmer available - or ask for help from the community, in which case you likely spend some time waiting, and maybe feeling a little out of control.
In conclusion, it seems wise when selecting OS software to look at how "live" its support community is. SourceForge, for instance, has a nice way of telling this. Meanwhile, again, it's by all means proper to want commercial support for OS software, particularly if its vital to keep it running 24/7. If it's not as vital, and you can't or won't budget for an in-staff code wrangler, I would suggest something a bit less costly than full support - something to bail you out of that rare case of having to wait for a fix to a bug no one had seen yet. Anyone seen OS software insurance yet?
Re:In the long run (Score:3, Interesting)
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
Re:In the long run (Score:4, Informative)
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.
You missed the point (Score:3, Insightful)
If you read his essay, he already concedes that projects like Linux are exempt, because you can buy support from someone like Red Hat.
He is talking about the more userland side of things that tend not to have companies behind them.
Sure you can say RTFS, but that is why the support costs are high, you have to hire a consultant or a full time programmer to RTFS of each new project you use. He takes time to read the source, then debug the source, instead of calling a company for an update that exists because several customers have already had the same complaint.
Re:In the long run (Score:5, Insightful)
Be careful not to get sucked into the level of support that commerical companies offer. They'll offer the world up front, but you'll have problems as time goes on. Don't forget the forced upgrades to the software and OS to keep the support going.
Give the commerical guys a call with a "tough" question, or a It's down and we need it up and have no clue as to what to do. See how they respond. I bet you'll be surprised (unless they know you are shopping, but even then)
Re:The entire universe ?? (Score:3, Insightful)
Another poster also made a similar point that no-one can learn all the different Open Source products. But you don't have to know the universe to support it!
My thought was this; advertize that you will provide support for any Open Source (or even commercial) software for a fee. Someone contacts you and says 'How about thiscrappything'. You take a look at thiscrappything and say sure! It will cost you $2500 per year plus $150 an incident plus consulting fees (if appropriate). Less if you only need support during weekdays.
Prospective customer then says no or yes. If yes you sign a contract and proceed to learn all about thiscrappything, afterwards providing support for thiscrappything at a reduced rate to new customers because you already know it.
Why can't that business model work?
Jack William Bell