Reader Voices: Paying for Bugs

With the vista of a new version of Windows before us, it’s a good time to continue one of our favorites discussion topics here. Namely, who pays for support when the problem is a software defect? That’s become an even trickier question now that the old “it’s not a bug, it’s a feature” software support mantra has been replaced by “it’s not a bug fix, it’s a critical security update.”

A recent story about paid support led to a debate about when customers should have to pay for getting software fixed. One software developer described what seemed like a fairly reasonable policy his company employs. “My company has a policy of not charging for support issues that were caused by a bug in our program. A problem that often arises is who determines whether it is a bug or a user error. Our policy says that this is up to us because users often try to ascribe their errors as bugs in our software. By the way, if we later determine that a call we charged for is actually a bug, we will refund the charge. Also, we give 60 days of free support with every purchase and 30 days with each upgrade. After that they pay by the call or purchase a support contract. We also do not charge if we cannot come up with a solution.”

But several readers retorted that they aren’t entirely comfortable leaving it up to the software company to define what is and isn’t a bug. “Yeah, but how common is it that you actually admit that something is a bug?” another reader wondered. “Saying it’s a feature instead is not exactly unknown in the industry. Microsoft is notorious for it, for one.”

Another reader tried to come up with a clear rule on when customers should pay for support. “My personal opinion is that beyond a minimum amount of free support — for every program at retail — companies should charge for incidents that don’t involve bugs, including security holes, and/or items in the manual/online help. Personally, if a company charges you for a support call where you found a bug, tell the support person that you intend to dispute the charge for the support call — assuming he doesn’t agree to waive the charge. If enough people do this en masse, then companies would rethink their ‘charge no matter what’ support policies.”

That comment prompted a number of readers to ponder whether a security hole is or is not a bug. “Some would say that a bug is when a program is doing something it is not designed to do, or is not doing something it was supposed to do,” one reader wrote. “Many companies still treat security as an afterthought, if they think of it at all. If a security issue is there because security was never even considered, then it’s not really a bug. It’s a design flaw or a failure to design for security. But to be a bug, they would need to have intended that it be secure.”

And what about software that seems to be an eternal beta and never a finished product?

“Personally, I find it inexcusable that any money has to change hands to give support for an unfinished product that was being sold to customers as if it was a final product,” another reader wrote. “Today’s product life cycle goes something like this: sell Alpha, patch, patch, patch, sell Beta, patch, patch, patch, RC1, RC2, 1.0, end-of-viable-life-cycle, patch, patch, patch. Any support after they start selling the product for money, but before it reaches an actual release version should be not-for-charge. You think I want to pay you for the privilege of Beta testing your product and pay you for the privilege of reporting a problem? You should be paying me.”

So what do you think? Where does the software publisher’s responsibility for fixing its bugs — or security holes — for free end? Post your comments on my website or write me at Foster@gripe2ed.com.

Read and post comments about this story here.