Paying for software and hardware support is hardly a new concept. But I'm sick and tired of ponying up for support contracts on certain products when the only time I ever use that support is to download bug fixes. Some of those contracts are pricey, and refusing them would free up money for more pressing matters, but there's simply no realistic way to do that.
In short, I really don't want to pay vendors to fix their own mistakes, but that seems to be the "value proposition" in more and more areas of IT.
[ Get expert advice on the hottest trend in IT with Paul Venezia's Server Virtualization Deep Dive special report. | Stay up to date on the lighter side of tech with InfoWorld's Notes from the Underground newsletter. ]
To take a recent example, I had a storage array suddenly decide it didn't want to serve CIFS clients. It went from functioning normally to causing big problems in an instant. The CIFS service wouldn't restart and wouldn't stop, leaving the box stuck in that state. Other protocols were functional, but the only remedy was to reboot the entire unit, causing problems for the NFS and iSCSI clients. After the reboot, all was well once more, but the threat loomed that this could happen again at any time.
This particular array had a few other issues, such as the fact that statistics weren't being retained, and some additional minor oddities. These were all problems caused by the array firmware itself, not the configuration.
I contacted the vendor, since this array was new and had a three-year hardware support agreement. I described the problems and was told that unless I purchased a software support agreement, I was out of luck. I didn't need hand-holding to configure anything, I hadn't broken anything, and there were obviously significant bugs, but I was on the hook to pay to find out if these problems would be addressed in upcoming software releases -- or to get any further information or troubleshooting steps. That's just crazy.
Non-IT products rarely subject you to this sort of blackmail. If you buy a refrigerator and the circuitry that controls the internal thermostat goes haywire, the manufacturer will fix or replace it at no cost if it's still under warranty. If a car develops internal computer problems that cause it to, say, suddenly accelerate, a recall ensues and you get it fixed. For free.
But when a critical piece of IT hardware or software succumbs to coding defects, in most cases the end-user must shell out to have the problem corrected.
In fact, few industries have such long-suffering customers. When computers suddenly go poof, people might get upset, but there's a sense of resignation underlying it all, as if to say, "Oh well, what do you expect?" I've seen users go to amazing lengths to work around problems caused by software bugs, implicitly accepting that this is how it must be. In IT, we may be a bit more knowledgeable about what constitutes a bug and what constitutes a feature (or lack thereof), but we don't hold our vendors' feet to the fire nearly as much as we should.
If there are major feature additions in a new firmware release, then I might expect to pay for the privilege of installing and using it. If there are major bug fixes in a new firmware release, I shouldn't have to pay a dime for it. Nor should I have to pay a dime to contact support about problems caused by the product. If I screw something up and I need support to help me fix it, I should have to pay for that. If they screw something up and I need them to help me fix it, that should be free.
Hardware and software vendors have had it far too easy with the status quo, and this inertia is difficult to overcome. It's especially difficult because so many companies continue to pay beaucoup bucks to their vendors, because the threat of downtime -- no matter what the cause -- is frightening. Unless more IT directors start holding vendors accountable for their own mistakes, don't expect that to change any time soon.
This story, "It's not a bug, it's a feature -- and you'll pay either way," was originally published at InfoWorld.com. Read more of Paul Venezia's The Deep End blog at InfoWorld.com.