Slashdot Mirror


Open Source More Expensive In the Long Run?

Jack William Bell asks: "Could the PHBs possibly be right on this one? A recent evaluation I performed of competing commercial and Open Source products yielded the surprising result that the Open Source products were more expensive (in terms of lifetime costs) over a long term than many of the commercial offerings! Why? Basically this mostly revolves around higher support costs for Open Source products where no commercial support is available (unlike, say, Linux where you can purchase support from Red Hat, etc). This particular case might also be a result of one special set of requirements and environment and a similar evaluation for a different set of requirements and environment might yield a different outcome. But, nonetheless I found the experience instructive and I would like to ask two questions of the Slashdot readership: Firstly, is Open Source usually more expensive when all lifetime costs are factored in? And, secondly, 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? There might be a viable business model here!"

"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!"

28 of 571 comments (clear)

  1. One benefit by cdf12345 · · Score: 5, Insightful

    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. Re:One benefit by tmark · · Score: 5, Insightful

      With open source if the devo team quits, folds, or stops supporting their software you still have all the information to continue to use and improve the software you're using.

      This argument presupposes that companies want or are able to support the staff necessary to "continue to use and improve the software you're using". Most do not.

      Most companies out there would prefer to take their chances on Microsoft's long term viability then they would on taking the chance that some Open Source project is going to continue to be actively developed. Why ? Because the costs associated with the (miniscule) chances of a Microsoft going under and abandoning (say) Office users whole-hog are very small compared to the costs associated with having to take on a developer or three to maintain some open-sourced program whose chances of dropping off the radar screen or having its developers lose interest are much, much higher.

    2. Re:One benefit by Kevin+Stevens · · Score: 5, Insightful

      Open source has alternatives for more than just Office and windows. Lets say we download a piece of software that converts html to pdf or something like that. I would say the cost of a piece of closed source software would be about $50 for that. Now lets say you go to sourceforge, and get the same thing. ok, you saved $50. Oh but wait there is only a source version, I have to compile it. Doh. There is a dependency issue. I have to go find some library on the net. Ok found it. Doh. It wont work/compile with XP/Gcc Version whatever. Doh. The guys who wrote the software are not supporting it anymore and have moved on to other projects. Doh. John in sales has no idea to change the source code so that he can put a watermark on each page. He sends it to Mark on IT who then spends a few hours looking at and changing the code. Oh wait. weve spent alot of tine looking at this thing. Mark in IT's time alone was equivalent to more than $50.

      This is obviously dramatized a bit, but still. The argument that open source is open and can be changed is very misleading. Any programmer time is exremely expensive. If you fix that bug yourself, it will almost definitely cost you more than that program off the shelf.

      I went on some tangents, but it is clear that open source CAN cost more than off the shelf software, and has similar pitfalls to off the shelf software.

    3. Re:One benefit by pmz · · Score: 4, Insightful

      Regardless of cost, Open Source software is inherently safe from volatility among commercial vendors like Microsoft. Open Source software is, by definition, fully documented and non-proprietary. Yes, source code does count as documentation, because it can be used to understand things like binary data formats when printed manuals are not available. The source code can save your ass, given that you'd be completely out of luck trying to interpret proprietary data. Yes, it may be inconvienient, but, at least, you aren't bound by the testicles to Microsoft's whims about forward and backward compatibility, licensing, planned obselesence, etc.

      Documentation created today should be readable tomorrow and ten years from now. Is that true of Microsoft Word or Powerpoint? Now, how about text, LaTeX, and Open Office? I do believe that Word is the most dangerous file format invented...do you know how many companies have all their documentation in Office formats? Wouldn't they feel safer knowing that their documentation isn't fundamentally bound to one company's products? Unfortunately, they don't think about such things. Perhaps that is darwinism on a large scale.

    4. Re:One benefit by BeBoxer · · Score: 5, Insightful

      Actually, how many 10 year old products does Microsoft support? Note, I'm not asking how about current versions of 10 year old product lines. How many 10 year old versions of anything does Microsoft support? My guess is the answer is zero. Zilch. Nada. In fact, this is true of almost all companies.

      In the commerical software world, you cannot use the same product for 10 years. You will purchase upgrades, and you will purchase new hardware to run those upgrades if you want support. Why? Because any company that doesn't make you do that will be bankrupt in 10 years.

      Depending on what you're doing, the support issue can fall either way. If you want to set up a dedicated system which you want to just sit and run doing the same job for 10 years, I'd argue that open source is probably the right tool for the job. On the other hand, if by "support" you mean a continuous stream of upgrades and feature improvements (whether you want them or not), than a commercial product might make more sense.

      Since in this case, it sounds like what's being spec'ed is just something that needs to sit and work for 10 years open source is the perfect fit. I suspect that after a couple of years of stable operation, the ongoing support costs for the open source solution would drop to near zero.

    5. Re:One benefit by BlackSol · · Score: 4, Informative

      Hence why there are so many people that bash Microsoft.

      However there are long running commercial product lines, all fed by yearly support costs.

      Look at AIX, HP Unix, OS/390, and AS/400 software packages as specific examples, sometimes there are upgrades available but often not. Computer Associates and IBM are famous for long support contracts.

      There are manufacturing applications that are still running on OLD VAX systems that are still actively supported by their creators.

      --
      $sig=$1 if($brain =~ /idea\s+(.*)/i);
    6. Re:One benefit by DunbarTheInept · · Score: 4, Interesting

      If you think the benefit of changable code that open source advocates claim is purely based on in-house people making the changes, you aren't thinking it through. So long as SOMEONE SOMEWHERE makes that
      change you can gain from it. Over time this tends toward programs that the user population wants to use. The big problem most open source programs have is that their audience is typically tech-saavy people only, and therefore the changes that get made are driven by the needs of the tech-saavy only. It's not that the developers are unable to meet the needs of the less tech-saavy - it's that they have no incentive to.

      And that's why the most successful Open Source software is that software that tends to have a tech-saavy userbase ANYWAY regardless of whether it was Open Source or not. For example, syadmin tools, programming language compilers, dynamic web servers (not just serving static pages, but running programs on the server), ascii text editors, and so on.

      The other place Open Source software does very well is in an embedded device where the user never deals directly with the software anyway.

      The only way closed source software has saved ME time is that when it says something cannot be done, I tend to believe it more, so I don't waste much time TRYING to get it to work. I just accept that it's hopeless and move on.

      --

      Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.

    7. Re:One benefit by DunbarTheInept · · Score: 5, Funny
      In fact, you can probably count the amount of "successful" OSS projects on 1 hand.
      1. Apache
      2. XFree86
      3. Linux kernel
      4. FreeBSD kernel
      5. Gnome
      Damn, I ran out of fingers. Let's try the other hand.
      1. KDE
      2. Mozilla
      3. ReiserFS
      4. The TCP/IP stack itself, typically implemented in most OS'es off of BSD's source, including even Windows.
      5. RCS and CVS
      Okay, Hold on, let me take my shoes off. Sorry about the smell...
      1. This little piggy runs DNS Bind
      2. This little piggy firewalls with Drawbridge
      3. This little piggy edits text with vim
      4. This little piggy edits text with emacs
      5. This little piggy runs sendmail (yeah, it sucks compared to newer mail daemons, but it most certainly counts as "successful".)
      Now the other foot:
      1. This little piggy uses gcc.
      2. This little piggy uses Perl.
      3. This little piggy uses bash or tcsh.
      4. This little piggy uses Python.
      5. And This little piggy uses Slashcode to claim Open Source projects aren't very successful.
      Okay, I'd better stop. I've almost run out of appendages and you really don't want me to use the twenty-first one.
      --

      Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.

  2. Costing is a black art! by locarecords.com · · Score: 5, Insightful
    The trouble is that you have bought lots of proprietary software assumptions to the party. For instance you assume that you will have the same sorts of issues whereas the Open Source varient will:

    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
  3. Go to the mailing list ... by burgburgburg · · Score: 5, Insightful

    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.

  4. Re:In the long run by cornjones · · Score: 4, Insightful

    Not if there is no support. Very few OSS projects have real support. that is one of the things pointed out in the parent post, nobody will support it. That is fine if you are going to have a person dedicated to becoming an expert in the product but that costs alot of money.

    some pay software is actually the best choice. Granted, not always... I am reminded of a time when a large publishing company I worked for was reluctant to use a whole set of Perl scripts we developed unless they could "buy" Perl. I told them to send a couple hundred bucks to larry but that didn't fly.

  5. What Support? by TamMan2000 · · Score: 4, Informative

    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...
  6. Open Source Is Not a Monolithic Thing by hondo77 · · Score: 4, Insightful

    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.
  7. What does commercial support really get you? by coyote-san · · Score: 5, Insightful

    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
  8. Can be by MrChuck · · Score: 4, Interesting
    Sure, it can be.
    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.

  9. Comfort level of vendors by tsetem · · Score: 4, Insightful

    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.

  10. Try getting support from commercial vendors! by teamhasnoi · · Score: 4, Informative
    We use SCO Unix at my work - The company who sold this system to us back in 95? has now moved to Windows. No more support, paid or otherwise.

    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?

  11. Faulty Logic by Tony · · Score: 5, Insightful

    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.
  12. What does 'support' really mean? by cmeans · · Score: 5, Insightful
    My problem is with the word 'support'. The author seems to realize that 'support' can mean different things, and isn't necessarily going to solve the problem the client is having.

    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

  13. Ten year lifetimes and proprietary apps by JoeBuck · · Score: 4, Insightful

    You claim that it's a requirement that this system would have at least a ten-year lifetime. Did you get commitments from the software vendors that they would support their product for ten years, or help you transition to a replacement product? Companies regularly terminate unprofitable products, and in some cases they withdraw timed license keys, with the effect of causing deployed systems in the field to cease to work.

    If not, then the only option for you that you can be certain of maintaining over a ten-year life is the open source option.

  14. OSS phone support by Tablizer · · Score: 5, Funny

    "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."

  15. Two modest points... by sphealey · · Score: 5, Insightful
    I am not trying to sway the humble reader in one direction or the other, but I would like to add two modest points.

    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

  16. Monetarily more expensive perhaps... by LoRider · · Score: 4, Funny

    but how much is your soul worth?

    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 .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."

    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
  17. Re:In the long run by dup_account · · Score: 5, Insightful

    I have 6 people working for us right now, and another company that is providing support for a product that they didn't develop. It is easy and cheap to find people willing and quailified to give support.

    Be careful not to get sucked into the level of support that commerical companies offer. They'll offer the world up front, but you'll have problems as time goes on. Don't forget the forced upgrades to the software and OS to keep the support going.

    Give the commerical guys a call with a "tough" question, or a It's down and we need it up and have no clue as to what to do. See how they respond. I bet you'll be surprised (unless they know you are shopping, but even then)

  18. Re:In the long run by pokeyburro · · Score: 5, Insightful

    I think you just inadvertently pointed out the key. SourceForge. Or, more generally, an active OS support community. If our valiant government consultant picks an open source package from J. Random Basement Boob, he may very well end up screwing himself.

    From my reading of his explanation, he seemed intent on getting commercial support for the software, open source or not. I admit it's valid to want to pay for some assurance that if the software breaks, someone will be on hand to at least try to fix the problem. The OS movement doesn't seem to address this as much as it could; a lot of legit software mechanics could offer their services here.

    The OS idea puts more stress on the fact that OS software is less likely to break because of peerage. Your support isn't supposed to have to be commercial; instead, if the software breaks, it's likely already been fixed by someone else, and you need merely get a patch from the same place you got the software. Compare this with commercial software, where you likely have to submit a bug to the company, and wait for the next version to come out, which you must pay for.

    It's when your problem is not fixed, that you'll ever have a non-zero cost for OS software. The idea here is to either get your on-staff programmer to fix it, in which case it's already been budgeted - and yeah, I know in this case there isn't an on-staff programmer available - or ask for help from the community, in which case you likely spend some time waiting, and maybe feeling a little out of control.

    In conclusion, it seems wise when selecting OS software to look at how "live" its support community is. SourceForge, for instance, has a nice way of telling this. Meanwhile, again, it's by all means proper to want commercial support for OS software, particularly if its vital to keep it running 24/7. If it's not as vital, and you can't or won't budget for an in-staff code wrangler, I would suggest something a bit less costly than full support - something to bail you out of that rare case of having to wait for a fix to a bug no one had seen yet. Anyone seen OS software insurance yet?

    --
    Lately democracy seems to be based on the skybox, the Happy Meal box, the X-box, and the idiot box.
  19. The closed debate: by HamNRye · · Score: 5, Informative

    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

  20. You picked an extreme example, let me do that too by weave · · Score: 5, Insightful
    My organization was approached by Microsoft to scrap our Linux mail server serving 17,000 students and staff and move to Exchange. Even with the deeply discounted educational pricing for Exchange CALs, we were looking at a licensing cost of over $100,000 a year to do this. Plus, if that's not enough, instead of doing mail on one dual-processor linux box with 4 gigs of RAM, I'd have to buy several equivalent boxes to spread the exchange load over as well as buy (their recommendation) enterprise server and do clustering. If that's not enough, the Unix mail server runs pretty much by itself with someone having to stroke it once in a blue moon with one hand while eating their lunch with the other hand. If I moved to Exchange, I'd have to send a few techs I have out to training for all the microsoft administration knowledge, or fire them and go hire me a few MCSEs.

    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...

  21. Re:In the long run by walt-sjc · · Score: 4, Informative

    There are VERY FEW commercial software companies that support a particular app for more 5 years. 5 years is a LIFETIME. Win98 is EOL and it's only 4 years old. Ditto for NT4 which was still being sold 2 years ago, and support is for the most part GONE.

    With OSS, you can basically support it forever, porting to new architectures, adding enhancements, fixing bugs, whatever. You just can't do that with comercial closed-source software.

    The problem with code-escrow of commercial code is that you won't know how bad the code is until you NEED it. You may find that it's unmaintainable. Not an issue with OSS, where you know what you are getting into right up front. There are also other problems with code escrow but it usually is dependant on the terms of the contract.

    I developed an application / custom hardware sold to utility companies about 8 years ago that is still in use. That code has had about 6 different maintainers since I left, and they hacked the code to shit, lost backups, etc. leaving my former clients in the lurch. We did offer code escrow, since the utilities end up using this stuff for 20 years or so, but not all the utilities took us up on the offer (since we charged extra for it.) Some of the equipment we replaced was over 50 years old. If I was doing this again, I would have pushed to just give the code to the utility up front. It just ain't right what happened to them. If they had the code, they could have hired someone to port to more modern hardware (it was PC based) or even a different OS (the code was designed to be very portable.) The code was useless to anyone that didn't have the custom hardware.

    Bottom line is that comercial support is USELESS if your needs are long-term, and the company can't / won't support it long-term.

    OSS give you freedom. It's hard to put a dollar figure on freedom. Some say that it's priceless.