Support Issues

Support Issues

I want to shift to support for a minute. Paul, if I make a bet on Linux, do I also have to make a bet on the long-term viability of Red Hat?

CORMIER: Is that a question?


CORMIER: If you make a bet on Red Hat Linux, you will obviously have to make a bet on the long-term viability of Red Hat, but not to the extent you would with proprietary software. In my opinion, Red Hat is in the best position to give the best support for our operating system. But down the road, if another vendor could do a better a job at supporting Red Hat Linux, they have the source code available to do that.

Jason, is Microsoft's shared source initiative an acknowledgement that in supporting software, the open path is better? That giving customers a peek at the code helps them fix bugs more quickly?

MATUSOW: First off, there are many different models that make up the software ecosystem. And so to say that any one model is dominant over another would be a mistake. I think we've learned from open source, particularly in the nature of community and how we can better work with customers, and so the shared source program we put forward is a way for any software vendor to be able to share source codes and still own its intellectual property. We're working on customer and partner benefits rather than dealing with the philosophical battle of whether or not you are "open." So we've been sharing source code with enterprise customers, systems integrators, governments and academic institutions, and that's just for the Windows code base. We're certainly taking lessons from the open source community as it relates to working with our customers, but we are most certainly not open-sourcing Windows.

ROBBINS: There are a couple of old CIO curmudgeons who are likely to resist anything new. Their notion of support is not so much vendor-oriented as it is in-house expert-oriented. With open source, there needs to be an individual or a team that's fluent with and dedicated 24x7 to the support of your open source platform and application. Up until maybe 12 months ago, that was not seen as a risk factor for most of these CIOs, because their staffs like new technology. And you want to keep your staff motivated. However, they've all lost a lot of head count, including expertise in this area. And so it's reminded them that when you have in-house dependencies and you hit a recessionary cycle, you could be forced to trim staff and lose the person providing the support for this platform that you have customized wildly out of necessity.

YATKO: In some ways I totally agree with you, but if this is a strategic operating system for your enterprise, a big mistake would be to put very few people on it. You have to have teams of people that understand the operating system. You have to treat it as you would any other operating system. The risks of this operating system over any other should be exactly the same, and you need to treat it as such.

MATUSOW: One of the interesting things we've heard from our customers as we've gone out sharing source code was a strong desire for us not to share the source directly with them but rather with system integrators, because they would prefer to work with those companies and allow those companies to have that intimate knowledge rather than bringing it in-house.

YATKO: When you start looking at staff being reduced, you start wondering about server consolidation. And, again, when you're getting those price performance benefits, you can start reducing any number of RISC boxes into these more commoditized hardware solutions that need only one person instead of 10. So when you're reducing staff, this is an even more important solution to look at.

This article was originally published on 06-14-2002
eWeek eWeek

Have the latest technology news and resources emailed to you everyday.