To read all comments associated with this story, please click here.
While I see your point, this sentiment is, in part, a reflection of the corporate habit of "passing the buck." There always needs to be someone to blame if something goes wrong, and no, it's never _my_ fault.
The problem is that sometimes computer hardware/software just can't do what you want it to do, or it fails because of something you directly or indirectly told it to do, and no realistic level of support can fix this. If you need a new third-party application, and it doesn't run on your platform, there's not much support can do. If your server crashes and loses data, there's not much that anyone can do.
If you can't figure out how to configure iptables, support can help. But the concept of this limited-time guarantee is a false sense of self-assurance. There are plenty of independent consultants (for example) who would be willing to charge an hourly rate to help you configure iptables. For many customers, this would be a more cost effective service model.
Who, you ask, can you call if this guy's iptables configuration lets through some malicious packets? Unless you can track down the origin of the packets, then nobody.
CIOs: Stop passing the buck, start taking responsibility. I know it's tough to sit behind your desk in your fancy suit and realize that your mistakes can cost your company millions of dollars. That's why you're a CIO, and that's why you get paid more than most people in your company. Deal with it.
Several decades ago, when companies ran on ink and paper, you didn't call Hearst Paper when you had problems managing your data. You cracked down on management and designed better document handling procedures. You took responsibility for your own infrastructure. Why is it any different with digital infrastructure?
While I see your point, this sentiment is, in part, a reflection of the corporate habit of "passing the buck." There always needs to be someone to blame if something goes wrong, and no, it's never _my_ fault.
Nonsense. If one guy installs a operating system at work with which no-one else is familiar, and the system falls over while he's on his holidays, the company is screwed.
If he gets sick, and a problem occurs, the company is screwed.
If he leaved without preparing appropriate handover documentation, the company is screwed.
Add to that the difficulty of hiring quality admins with Linux knowledge (they're rare and they're not cheap) and it's perfectly reasonable from a management perspective to ensure that there is always a Plan B, which in this case is third-party support.
And I might add that several decades ago people were using calculating machines (some from IBM and HP in fact), and it was common for people to pay IBM and HP and others to provide operators in case anything went wrong, or even just to service the machines every now and again to make sure nothing would go wrong. It's exactly the same principle, and it's been a common part of business for at least a century and probably more.
Edited 2006-08-14 23:27






Member since:
2005-08-12
When I was a Network Admin, I tried every possible way to get Linux into our Enterprise. Our CIO always balked saying, "Who do we call if you get over your head" and now that I own a business, I can see his point.
This is great news because now once cost savings/ROI and other sellers tools are realized, the CIO's hear "Oh yeah, and you can call us directly for support."