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