Here at Anchor, we’re often asked to install commercially-supported software products by our customers. Most commonly, it’s Linux distributions, but hosting control panels, app servers, and various other pieces of paraphenalia all get the treatment fairly regularly.
The internal opinion on the subject is that most commercial support agreements for software aren’t worth the paper they’re written on (a problem made much worse by the fact that you can’t wipe your backside on an e-mail). A recently-concluded saga with a certain prominent North American vendor of Linux distributions has done nothing but reinforce this opinion, to the point that a rant is the only way to deal with the insanity.
In March 2006, we got a problem report from a customer that an aspect of our hosting services was not operating correctly. We investigated, and determined that the problem was that the vendor-provided webserver was crashing. Since this system was covered by a support agreement, we lodged a bug report with the vendor.
The log for this report in the vendor’s bug tracker reads like a primer for “how not to provide tech support 101″, with various people from the vendor commenting on the issue and asking for information that had already been provided, and generally tripping over each other to dodge and weave and avoid investigating and fixing the problem.
We also enjoyed the repeated use of a wonderful stalling tactic: demanding the provision of a large (> 650MB) dump of system information before investigating the problem. In addition to the practical problems of uploading a CD’s worth of data over Australian-grade ADSL uplinks to a flaky FTP server on the other side of the world, this dump contained various customer confidential information, which made it a gamble to upload. It also contained nothing of actual use in diagnosing the problem. (I know for a fact that the info dump was unnecessary, because the problem was eventually fixed — by us — without needing anything in that file, but instead entirely using the information we originally provided).
Overall, the entire bug report documented a thoroughly unhelpful exchange, spanning several months, with the guy on our side of the keyboard getting obviously more and more frustrated as the weeks went by. I wasn’t involved in the original bug at all, but even I got worked up reading over the log.
Eventually, in July 2006, we gave up on the vendor, worked out a very ugly and kludgy workaround ourselves, and closed the bug in disgust, hoping that the problem would never rear it’s ugly head ever again. It did, repeatedly, but each time the kludge was folded, mutilated, and spindled some more to provide further relief, because the idea of going back to the vendor was just too horrible to contemplate.
Things remained in this state of critical stability until a couple of weeks ago, when the problem once again became the focus of our attention. The difference this time was that this time the bug report landed on my desk, and I was flush with success after finding another Apache segfault bug (this one a security vulnerability) late last year. I figured I could dive in and find the bug.
It turned out to not be quite so easy as the previous one, but after about two and a half days of digging and poking, I did manage to unearth the source of the bug. It was, as it turns out, entirely due to a coding mistake in the vendor-provided webserver, and it was entirely diagnosable with the data that was originally provided in our bug report of 2006.
Things took an ugly turn at this point, though. Despite the vendor having expressed no interest in finding and fixing the bug in their software, I decided to send the patch to them, in the interests of being a good OSS citizen. Their reaction was utterly incomprehensible:
- Despite being told in the original message that “the attached patch fixes the problem”, they asked “I would like to know if the patch you have uploaded solves your issue” — like I’d upload a known-broken patch, and say it fixes the problem. Sheesh.
- They again asked for the gigantic system info dump, which we’d previously told them we couldn’t provide.
- They also claimed that, since the OS release in question would be going out of support in around 6 months time, it would be very unlikely that a patched release of the webserver would be forthcoming.
So, in other words, if you’re running a commercially-supported software product, for which you’ve paid quite a considerable sum of money, you can expect that the “supported period” will be shorter than your contract promises, you’ll be given the runaround, the vendor will do anything they can to avoid having to actually do anything, you’ll be asked idiotic questions that anyone with a fundamental grasp of the English language would be able to answer from the existing bug log, and even when you do the vendor’s job for them and fix the problem yourself, they’ll still persist in jerking you around. And somehow, somehow, that’s better than saving the money and just being able to fix problems yourself, when and how you need to?
Sorry, but screw that for a game of skittles. I’m not against paying people for assistance, but if I pay you for assistance, I’d really appreciate it if I actually got some.
I’m having trouble recalling a situation in which I’ve actually gotten a consistently good experience out of a software support organisation. This isn’t an isolated incident — it seems like every time a problem is reported in a piece of commercially-supported software, the relevant vendor deems it more cost-effective to avoid the issue rather than fix it. That this seems to actually work (since people still keep paying for “support” when they don’t get any) is a sad indictment on consumers of IT services, while the fact that nearly all commercial software vendors are willing to screw their customers over is a horrible, soul-destroying realisation.
While the plural of anecdote isn’t data, my experiences, and that of the rest of the Anchor staff, really only suggest one thing: software “support” contracts aren’t really worth an awful lot, in the absence of real, strong performance guarantees. (Why nobody will give you an effective performance guarantee is left as an exercise for the reader.)
That isn’t to say that paying for software is never recommended. If the software you want to run is a commercial product, then there’s only one option — pay for it. Copyright infringement isn’t cool. Personally, I’ve not been the least bit interested in a commercial software product — other than Wii games — in the last 10 years, but I’m weird. Other people have differing opinions on the subject.
However, when you’re making the decision to buy a commercial software product, bear in mind that all you’re paying for, in practice, is the right to use the software. Any support services you are promised are unlikely to be of any value whatsoever. In fact, if the software product isn’t Open Source, then it’s value is actually lower, because nobody except the vendor can fix problems you come across — and the chances are that the vendor will not fix the problem for you. Ouch.
This might sound like a weird statement coming from a company that makes some of it’s revenue from servicing software. While we’re a hosting company, it doesn’t take very long for some customers to get out of their depth and need some specialist assistance in getting something running on their server, and we’ve got the expertise on-staff to help with those of things — for a suitable fee.
The difference between what Anchor does and what most software companies do is that we’re not selling software, just expertise. We also have no ability to lock you into using a particular piece of software or service, and hence if we don’t provide a good service, there is nothing stopping you from going to someone else next time. That tends to keep us on our toes.
But that doesn’t mean that our support level couldn’t decrease in the future, so it’s important that our customers don’t accept bad service — from us, but also from anyone else.
Everyone, both customer and service provider, needs to have high standards, and demand those high standards from their suppliers and customers. There’s way too much laissez faire in the IT industry.
