What Is Fair Technical Support From a Manufacturer?

VincenzoRomano asks: "One year ago, I decided to buy some 'enterprise grade' firewalls, in order to replace the old ones used by a former ISP. Before buying, I did a bit of a survey. I browsed the product 'data sheets' from the manufacturer web sites, and in some cases, asked for more details by email. I finally choose a top product, that had been on the market for a year and a half, from a very well known and reputable company. The product showed a number of issues as soon as it was unpacked and put to work, that you would not expect from something 'enterprise grade', like not being able to keep a VPN up and running for more than a few minutes, or doing bad IP routing on our LAN. I've spent the last year to make the equipment working, accordingly to both their data sheets and the features expected from an 'enterprise grade' product. Important issues are still open while the technical support is actually relying on my own stuff and setup, and on my personal availability in order to do troubleshooting, firmware beta testing and other experiments. I've finally decided that the product was far from being ready to market or even usable for beta testers, and have requested some kind of compensation for all the job I had to do. What's your opinion about such a behavior in a company? Is it fair?"

Comments

Welcome to IT?

[EveryNickIsTaken]

What you're describing was fairly commonplace back in 1994-1997 when I was helping start up a regional ISP. To a certain extent, it was "neat" that we were finding bugs in brand new routers (Cisco + Bay were the usual culprits). Of course, it was a pain in the ass that it'd typically take hours, days, or weeks to realize that the hardware/software was bugged.

As technology has progressed, things certainly have gotten better. Regardless, you need to realize that "shit breaking" is part of IT. Don't like it? Leave the field.

Re:Welcome to IT?

[Sobrique]

Sadly so. Almost any product out there has bugs. If you're lucky, the really sucky ones are already gone. But only if you're lucky. I have memories of a NAS upgrade, that resulted in 8 TB of 'possibly corrupt' data, over long enough interval that just restoring a 'known good' backup just wasn't an option.

I'm afraid it's normal that 'new toys' have problems. Your only way of really avoiding, or at least migating this is to stay one release behind the latest and greatest. You've got good odds that by the time the 'next release' is finished, most of the real killer gotchas will have been found.

In part, it's laziness in testing. In part, it's the simple fact that it's definitely non-trivial to exhaustively test something in teh kind of intensive environment you see in the 'real world'. Things like race conditions typically don't occur often enough to be noticed in testing, but will start to crop up often enough to be a real problem in the real world.

Acceptable? No, not really. Fairly commonplace? Hell yeah.

Don't trust any .0 release. Don't trust anything that's sold to you as the 'newest and feature laden'. Ask yourself if you _really_ need that totally new and cool (and therefore almost certainly not properly tested) feature, or if actually, a revision or two back would do what you need.

With the best will in the world, a test environment will never really compete with a couple of hundred thousand people using it, for finding 'problems'.

You will almost certainly find that the EULA also includes a get out clause for exactly this kind of behaviour.

Re:Welcome to IT?

[stu72]

All great advice but try telling that to customers.

People buy IT products on features, not reliablity or usability. If you stop developing new features to focus on reliablity, your customers will, in short order, abandon you for the guy pumping out feature after feature, however buggy.

I'm not saying this is rational, but it's how non-IT (and some IT) people make IT buying decisions, and that drives the industry.

Re:Welcome to IT?

[gregmac]

You may be first to market but if you do a really sloppy job of it, then word will spread and you can forget about getting big contracts in the future. One word: Microsoft.

Re:Welcome to IT?

[Eagleartoo]

I really wish I had mod points right now because you stole what I was going to say =) . Releasing a product that has to continually be patched because of it's verbosity is not my idea of a good product. When I switched to apple the only time it really screwed up is when I did something that taxed the system, and the software that was built in was like the AM/FM radio in your car. You turn it on and it works. What you are seeing in the bugginess of new hardware/software is simply greed. There hasn't been a better computer since unix.

Re:Welcome to IT?

[raddan]

Firewalls have been around long enough where I simply wouldn't accept this nowadays. I put up with proprietary firewalls for years that were purchased before I was hired here. They were purchased because they had long feature lists and snappy GUIs. But in practice, they were garbage. Their state tables were small, so they often dropped connections. Their VPN implementations were buggy (in fact, a 'factory authorized field consultant' from this one particular company said that no one *really* knew how their IPSec stack worked; I know he was saying this to me in order to give me that "I'm on your side, buddy" kind of feeling, but it made me immediately lose faith in their product). Often the GUIs did not display the proper state of the machine. To add insult to injury, our paid support contract did not include 'premium' features such as access to their tech info library, where you would find out what error IDs actually meant.

After one particularly bad episode with the firewall, where we were required to replace a failing hard drive, we started looking for something new. That hard drive was a standard 2.5 inch Hitachi 40 GB-- but they charged us $500 for the "authorized" part so we wouldn't void our warranty. If they're going to charge you $500 for a part that should cost $100, fuck the warranty, man!

After evaluating our options, we settled on OpenBSD's PF. Several linux firewalls were considered as well, but we went with BSD because we were more familiar with it. We've been extremely pleased with our choice. PF gets better and better with each release, it is highly flexible and customizable, and the rule syntax was easy to learn. We have features that would cost us an arm and a leg in their proprietary counterparts (VPN, dynamic rulesets, firewall failover, and so on), and we can build it on commodity hardware. There's a huge community that has given us technical and moral support, and documentation is freely available. These are full computers, too, so if we need to write a custom monitor or report, piece of cake! And the savings in time and money have been enormous.

And this taught us an extremely valuable lesson-- don't be afraid of the learning curve of applications that don't use a GUI. The fact is, sometimes the problem space is complicated, and a text interface often handles that complexity better than a GUI. Sure, there's a higher nmemonic load, but we work with these machine every day, so we got used to it. You'd have to give me a really good argument at this point to get me to switch over.

Obligatory MS slam

[Jimbo God of Unix]

To be quite honest, this has been my personal experience with MS software. I've also had problems with various open source software, but at least with OSSs you don't necessarily expect it to be usable "out of the box" and sometimes requires a little fiddling. But with MS stuff you're paying real money for it.

James

Re:It was your decision to purchase

[Aladrin]

On top of all that, he either totally ignored all the bad reviews for the product, or there were none. If there were no reviews at all, that's a sign in itself, and can be considered a bad review.

So let's assume that mysterious, but very apparently very popular firewall X did indeed have a ton of good reviews. Doesn't that pretty much leave him as an edge-case? Someone who is either using the product as it was not intended, or so incompetent that nothing the company can do will straighten the problem out? The company is probably relying on his 'availability' to troubleshoot because they cannot replicate the problem in their labs.