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."
Get the independent advice and expertise you need to support a virtual workforce.
The increase in Linux popularity has increased the frequency and sophistication of malware attacks. Read this 2 page white paper now to learn how you can protect your Linux environment with real-time protection that is certified by all major Linux vendors.
Download now »
Ensuring acceptable application delivery will become even more difficult over the next few years. As a result, IT organizations need to ensure that the approach that they take to resolving the current application delivery challenges can scale to support the emerging challenges. This handbook elaborates on the key tasks associated with planning, optimization, management and control and provides decision criteria to help IT organizations choose appropriate solutions.
Download now »
A common misconception is that mid-range storage requirements are dramatically different than that of a larger enterprise. Mid-range storage users may require less capacity, but they have similar functionality and management requirements. This ESG paper examines mid-range storage needs and reviews a new solution that adjusts size while retaining value, performance and functionality.
Download now »
Recommend This
