Quote:
That's merely because the NASDAQ is willing to pay HP to help solve their problems...If NASDAQ wants to pay me $1000/hour to do the same work.


The issue is that NASDAQ likely wouldn't be willing to pay just you for a support incident. Big companies feel much more conformable with another company providing them support then they do from just a person. Red Hat had done decently realizing that there indeed was money in the Linux services market.

Had big companies like HP (and many others, I'm just using an example I know well) not picked up Linux like they had, it wouldn't have the corporate penetration it has today. Simply put, corporations are not willing to deal with something so far on the fringe that they have to rely heavily on a search engine and source code to answer the question of why the tc3 networking module caused an SMP server to lock solid.

I like many things about Linux and the community around it. I also dislike quite a few things about Linux and the community around it. And the sad fact is that if I come into a point in time where I have to recommend a Unix solution, it's doubtful I could ever recommend something like Gentoo or Debian simply for the lack of a professional support provider. While I dislike RedHat, I'd likely push more towards them, or towards Novell with SuSE, as they not only offer a complete solution on the Linux software side, but they also provide excellent support contracts.

HP's support contracts in the Linux space make sense for one big reason though. If a company has Linux running on an HP product, the engineers they contact for support can resolve any issue. If it's hardware, the proper resources are located to address the issue. If it is software, and not an HP provided driver, we have paths to get the support needed out of RedHat or Novell if it goes beyond the expertise of the local software team.


Anyhow, to try and put this back on topic a bit while keeping the Linux side, the open source nature of Linux doesn't mean that a Linux program is going to spout out potentially more useful error messages then a closed source program on Windows. It's more a matter of the developer and how much effort they actually put into creating useful errors. If the error dialog is mostly hex gibberish, and the source code has little to no comments, the average IT support person is going to be stuck with the same problem as he would dealing with error 0x102939 on Windows. Poor documentation hurts on either side, and pure source code doesn't count as documentation in my book looking at it from an IT workers prospective.


Edited by drakino (10/09/2005 06:23)