Slashdot Mirror
Open Source More Expensive In the Long Run?
"Here are some details for you:
I am currently doing consulting work to create a complex custom search utility for a governmental agency. The first major step was, of course, to select a Search Engine that provides as many of the custom requirement features as possible; thus reducing the amount of custom code and my expensive time. Besides high-end search features my customer also required something that was fast, easily administered and likely to be supported for a very long time. Why the last? Well, the expected lifetime of the new project is ten years and this is not out of line considering that their current system is more than a generation old!
Consider again the environment; this is a government agency and is somewhat resource starved. They have a limited number of staff and the staff must split their time among many different working areas. They must be generalists and do not have time to specialize. Plus there is some turnover, especially among the better skilled staff. These factors lead to a basic requirement that there is someone they can call for support for every product they use, preferably 24 x 7. They also need to know that this support will be available for the entire lifetime of the project -- in this case a full decade.
Now to the chase -- without going into boring details, or names, we were able to locate nearly sixty Search Engines that might be suitable. Most of these were commercial, but some were Open Source. From this list we selected eight that seemed most likely to provide all the capabilities we needed, of which one was Open Source (in fact this was actually two variations of the same project). We then performed detailed paper analyses of these products, comparing features to our requirements list and doing some estimated per-year costs to determine the lifetime costs. From the results of this we selected a smaller number for in-house evaluation and from that we selected the final recommendation.
For the commercial products the vendors could supply us with support costs, often broken down in such a way we could choose our support like a Chinese menu. But for the Open Source products this was not the case. Contacting the maintainers of the Open Source products and asking if anyone provided commercial support was fruitless; in one case the response was downright rude (basically a variation on RTFM) and in the other the response was more helpful, but still could not suggest anything other than being active on the mailing list.
So I had to figure in the cost of one of my customer's IT staff staying active on that list and learning enough about the product to provide in-house support supplemented by the email list. Estimating this at one tenth of an FTE and that FTE at a low $80,000 per year resolved to $8,000 per year. This was nearly three times the cost of the most expensive commercial product support!
When factored in with equal administration costs, adding in training and support (available from these vendors) and other one-time and yearly costs (for such things as licenses), the commercial products were more expensive for the first four to six years of lifetime costs, after which the Open Source product became more expensive. Of course the difference wasn't too great, ranging from 20% to 60% higher in a ten-year lifetime. But it was there nonetheless.
Now my customers are not averse to using an Open Source product. After all, there is no guarantee that even the most established vendor will not fall by the wayside in those ten years. They just want to have a certain comfort level, even if it is illusory. And I must admit that any commercial product will require some time from their IT staff, but because there is 'support' available this is seen as being much less important. Major fixes or changes can be dealt with by hiring consultants like myself, and lesser issues dealt with by calling customer support. They might even be right in this estimation.
My estimates might have other holes as well, but that isn't germane. The selection process is nearly complete now and, in a detailed analysis the Open Source products turned out to be missing a couple of features that would have been showstoppers even had support been available. I want to know what resources I can use to (honestly) avoid this issue the next time I am comparing Open Source to commercial software for a client!"
Open source must be cheaper because you can choose who you buy support from. You're not locked to a single vendor who can extort you; just take the cheapest offer.
wow! how did you ever do a whois on him....it's not like it tells his hostname or ip.
just a thought
Well, here's why open source is still economically sound. As todays software companies start moving to timed software licenses, open source will be around. So in two years you may be writing a check every year to microsoft for the right to use Office. But if microsoft folds then you are out of your entire investment and you have no access to the data you created while using the service.
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.
Chicago2600.net more than a lifestyle, its a survival trait.
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..
---- The Open Source Record Label : : LOCARECORDS.COM
And announce you'd like to set up a long term 24x7 support contract on the project and ask for bids. Vet them properly and I'm sure you'd come away with a more reasonably priced TCO then you've calculated.
"Open source" is a huge expansive field. Some products will be easiers/cheaper to administrate and support, and some will be more difficult. The 'commercial' vendors have an advantage because they are spreading the support costs (all the infrastructure that goes with support as well) across many customers. Taking a DIY approach means most or all of those costs are born in your company, even if it's a small amount.
Shameless plug: My company offers professional PHP support via 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).
creation science book
Comment removed based on user account deletion
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.
11*43+456^2
Open source is not a single thing. The question isn't whether open source is more expensive than closed, it's whether a particular tool is more expensive than another. In your case you found that an open source tool wasn't the way to go. In other cases you are bound to find that it is the way to go. Credit to you for approaching it in an objective manner.
I live ze unknown. I love ze unknown. I am ze unknown.
The problem with these analyses is that it often overlooks how little commercial support really gets you. Esp. if you're looking at very long duration projects with limited resources to pay somebody to support your platform long after everyone else has moved on.
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.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
But don't compare that to general purpose business computing.
You briefly touched on this in your post, but what is the comfort level of the vendors you have found? What are the chances of them falling by the wayside, and being unable or unwilling to provide you with the support you may need. Are they large, and well-established companies, or are they smaller shops that may disappear if times remain tough?
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.
First, this sounds like a turnkey system, once installed. Your estimate of 1/10th of an fte seems a little high; once installed, the search engine shouldn't take 45 minutes a day to maintain.
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.
Microsoft is to software what Budweiser is to beer.
the product you've purchased is no longer supported by the company that created it? Companies come and go, so do software products. I would imagine that you'd be in the same boat regarding support in a couple of years OSS or not. Look at windows 3.1, you think you're going to get usefull support from M$? If you need a timely solution you'll have to track down some expert close to you anyways. And considering how much more OSS uses open standards, finding a usefull 'expert' even in a few years after deployment should be alot easier then trying to deal with the support you'll get from software vendors.
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
Give a hand, not a hand-out.
I think 10% of a FTE at 80K /Year * 10 Years is an over estimate.
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
Open Source Identity Management: FreeIPA.org
I think you're being a little simplistic figuring out the support costs.
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.
Its good to see someone doing a complete cost analysis, but I have a question. Why would you need to have someone lurking in the boards for the next eight years?
I can see being heavily involved on the boards during development. I can see it too if you're doing a feature upgrade that involves upgrading the engine or using new capabilities of it. However, if they're really currently running a system that's a generation old, I'm guessing that that system is rather poorly suupported today. I'm also guessing that it doesn't need much support.. development ended several years ago. Maintenance support is much less than integration and first deployment.
At some point, all products reach end-of-life and require personalized support. Fortunately, by the time that happens, the products that use them have been deployed so long that they're either replaced or the customers have been happy with the stability and feature-level and don't want to touch it. There are still some holdouts that are sticking with their favorite 24x80 text editor on DOS simply because, "It ain't broke!"
Instead of $8000/yr for the next eight years, I'd use a logarithmic scale that tapers down rapidly as the bugs are hammered out in the version you're using and active development shifts on to the newer versions. There will simply be less and less things for your support engineer to watch the boards for.
`` 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."
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
I think I see a trend here. Maybe for them it really would be easier to muzzle the entire internet than to produce p
In the long run, you can't buy support from a company that doesn't exist.
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.
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.
I know you think you are /.'s head iconoclast, but you know as well anyone that MS has NO interest in encouranging crossplatform compatibility in ANY document formats, outside of enough lipservice to fill out the RFP acronym checklist of the day. The *default* save format (i.e. the one that 99% of the user base will use), while possibly being XML based, will no doubt be encumbered by very onerous NDA and licensing restrictions.
.txt from day one, and nobody uses it.
.html from Word is also an option rarely used, and when it IS used, horribly broken, unreadable .html is invariably the result.
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.
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.
And after 6 years. Does any vendor provides you any guarantee that they will be there supporting the product?
And if they're not there or they don't support the product anymore, will they open-source they code so you can find some kind of independent support?
I think the fact that the expected lifetime of the system is that long is just one more reason to go for open source !!!!
Where does the TCO stop? When you buy another version or upgraded product? Basically does you W95 TCO stop when you upgraded to W2K which has its own TCO? Why would you not add the TCO's of both into a Total TCO of keeping your computers running over the years? This is something to consider when using open source. Two or three years done the road you can modify or add to your existing software to keep the software going and support your existing needs, you will not have to throw away package A and start over with package B. If you upgrade often your support costs may be less because more people are currently using it but your software costs go up (supply and demand). If you hold on to an application longer your costs will go up for support as less people are using it in the end but you will pay much less overall in software costs. Open source would allow you to keep an application going with third party support that does not have to be from any one vendor or from in house, seems to me this would make open source cheaper the longer it is used. Maybe not so cheap if you have a full time programmer on your pay roll to make a few changes to a package once a year but how does that?
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.
Bad boys rape our young girls but Violet gives willingly.
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
This is simply a result of thousands of schools foolishly believing that teaching people how to use a browser, word processor and spreadsheet are computer literacy. De-evolution in action.
Democrats and Republicans only disagree about how to enslave you
I've heard tell of similar problems with a friend's setup. If your network requires a non-standard (defined however MS want it to be) configuration, good luck on the support end. Make sure you factor in all the time trying to find a consultant who can even come close helping solve your problem into your cost estimates. One urgent problem that actually was the result of a bug of MS (according to the docs, it could be done) took a month to find one guy versed enough to even attempt a fix.
MS' response... find someone and figure it out (no code mind you). Trial and error and multiple consultants. Whereas at least you could fix the bug with the proper consultant and the source code.
Why would it take 48 minutes per day every working day to maintain software?
I'm responsible for the installation of a suite of OSS applications and I barely spend any time on maintenance. Once the installation is complete and the initial configuration completed, there is almost nothing to do until a problem appears. At that point I may need to do some research. The only other maintainence might be every few months to may check for a new release.
In what way is this any different than a commercial product?
I work as an IT consultant and have worked extensively on both proprietary and Open Source software solutions. I have found in most cases OSS beats proprietary on costs hands down.
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.
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.
See what I've been reading.
50 years ago, many (if not most - if not all) large companies employed their own staff as accountants, engineers, chemists, project managers, etc, etc. This meant that the company always had direct access to the specialists who built The Thing, if The Thing ever stopped working.
Today few, if any, large companies (and probably fewer small companies as well) have this specialist knowledge in-house - consultants are employed to design the tricky stuff, and the work is farmed out to other "specialist" companies.
So today, there is a division of knowledge - your company knows what it wants, a consultant works out how to do it, while a third party provides a partial solution. Add in the localisations needed to get the third party solution to fit in with your existing processes, probably with a combination of your own (precious few) expert staff, and a few more contractors.
So where does this leave today's company? Utterly dependant on external consultants, who usually vanish once they stop being paid, and third party companies of varying quality.
My personal experience, of helping a small ISP grow into a corporate, is to rely on your own staff as much as possible. Information is hard to gain, but a lot easier to pick up through implementing the project yourself. When it comes to your first support call, you'll be glad that YOUR people spent the time learning the details of YOUR implementation.
More than once, this has been the difference between six months in call centre biffo, and a five minute response from THE expert on the other side of the world.
Regards
With each breath in, a flower somewhere opens; with each breath out, a flower withers away. In between lies beauty.
Yeah, because after all, we wouldn't want to hire employees and stimulate the economy! We'd rather get support from one company that oversubs their support to about a billion to one. Riiiight.
I just wasted your mod points! HA!
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...
Never forget that MS *WILL* force you to keep replacing your entire set of MS software one way or another every couple years or so, in essence having to repurchase all of both the software and the CALs again and again and again. They have demonstrated this behaviour repeatedly in the past 6+ years.
Software costs big no matter whether you go open source or closed source. With open source you have to have your own knowledgeable (expensive) staff, but you get to control your own destiny. With closed source you can get by with cheap point-n-click monkeys but the software vendor herds you in the direction THEY want you to go... which is straight to their feeding trough.
- 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?
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'?
Life Insurance in Canada
Let's suppose you go out a customizable, supported commercial software system. Further, let's assume the implementation is a wild success.
.......
... "Oh yeah I remember, we upgrade."...
Let's suppose you want to build on your prior success and repeat it. You bring in a second vendor and explain that the *NEW* system you are about to purchase must interface with the old system. The vendor offers to create an interface for a nominal charge. Let's assume this is a wild success.
Life is great, all your systems are stable, customized and interfaced. Remember, that no system is an island and has to join the enterprise sooner or later.
--- Time Passes ----
You are walking down the hall with a bounce in your step and head to your mailbox box, where you find a letter from the first vendor. The letter explains that your current product, which is running so well has been deprecated and will be desupported at the end of the year. You think, no problem, we'll just upgrade.
A few days later you get a similar letter from the second vendor, the dreaded "DESUPPORT NOTICE". Ok, now your starting to sweat, your world is in need of upgrading and then, you remember the interface that ties both successful system together.
You go back to your office and fumble for business cards and try to contact the sales guys who sold you this stuff, however the area codes are now different and either none of the sales guys still work at the same company or have been transferred to another territory. This prevents customers from forming long term relationships with salemen. Why do they do this??? I don't know.
You finally find the new sales reps and setup meetings. They explain that the product has changed and so has the licensing. They also explain you will need to upgrade your hardware, O/S, and backend database for the new verion to work. As for the interface that ties the two togehter, that becomes a major problem and the source of many meetings. Finally, you get a quote and the cost to upgrade the interface is astronomical.
Now you are stuck. You can't just upgrade one half. You are deprecated and desupported, but still have to pay for support or you will have to rebuy the software if you ever upgrade. Vendors will typically refuse you upgrades if you let support lapse and will make you repurchase it all over again.
Your options are to:
1. rewrite the interface inhouse
2. pay the ransom
3. don't upgrade
4. reimplement both systems all over again with new products and this time add language to the contract about the interface and upgrades
How many people has this happened to?
Raise your hand high in the air. Yes, I see you!
One of the MANY, MANY, MANY things I like about OSS is that I can go at my own pace. No one is putting a gun to my head saying, UPGRADE OR DIE!
If I create dependencies, I make sure I can upgrade one half at a time, instead of multvendor "BIG BANG" upgrades/implementations. Ask Hershey how much their "BIG BANG" multivendor SAP implementation cost them.
When you buy commercial software, you get on the upgrade treadmill and you have NO CONTROL. Also, when you run into a bug and call support, the answer is ALWAYS, "You need to upgrade to the next version". My answer is "No, I am paying for support, so fix the DARN BUG" and they drag their feet and eventually mail me a "Desupport Notice".
Now, let's talk about customizations and backward compatibility. OSS, especially PERL has AMAZING backward compatibility which is NOT found in most commercial products. I've taken large PERL web applications and moved them forward in time about 5 years and they ALL WORKED! Try that with Microsoft Visual Whatever or Java. I get so sick of reading, this function/feature/method was deprecated in version x.1 and of course you are installing x.2
I don't know what you are developing, so it is hard to give specific advice, but remember to use the right tool for the job, get training, and decide how fast you are willing to upgrade before you plunk down money with a vendor, since staying one release in front of being desupported will be part of your new job description.
Sometimes I joke with my team and ask, "What is it we do again????"
So instead of spending all my time reading mail lists and developing new useful stuff, I can spend my valuable time upgrading and utilizing the support resources I pay for, since I am going to need them when I hit a bump in the upgrade process. Also, vendors will gladly sell you "upgrade consulting" services, but won't actually do the upgrade for you, they just consult you know.
Good Luck!
The problem is, someone still have to do in-house maintenance of the project. If he is receiving support from the vendor he still has to do his job, and this does not translate into any significant saving of employee's time compared to him learning about the product and getting support from mailing lists. Purely theoretical "time saving" of 48 minutes per day for a person who has to work on the project anyway means nothing -- and most likely negated by the quality of information available.
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.
Contrary to the popular belief, there indeed is no God.
What the article shows is that: - there's no easy or tried and tested formula for comparing support "cost" and support "quality/effectiveness" of commercial vs. open source offerings - businesses currently have a model for software purchasing and support which it is not easy to make OSS fit. And it takes time and effort to change business practices and models The responses present some good arguments: - OSS can provide a much safer, much more cost effective option - not all OSS projects are safe though, it depends on how committed and active their community is - proving this has to be done on a case by case basis - OSS is like all other software. It needs good hackers to support it. So whatever support you think you're buying or getting - look at the quality of the people who are delivering it. -- RobW