% fortune -ae paul murphy

Red Hat's business model

I got an interesting email from a student at Columbia recently. He wanted my opinions on six issues related to Red Hat's business model and long term prospects. I thought the questions interesting, but unfortunately I don't have the answers.

More precisely I have opinions on most of these things, but if there's one thing more certain than death and taxes it's that unresearched opinions tend to be wrong. With that in mind, I thought I'd buck the questions to you - and please feel free to contact me directly if what you want to say shouldn't appear in a public talkback forum.

Here are his questions (numbered 1 through 6) with my unthought through reactions interspersed.

  1. What value added services does Red Hat really offer? Red Hat does not have any proprietary technology and they do not have a deep support organization -- the company basically compiles and updates a linux distribution which others distribute and provide first level support (IBM, HP, Dell). So, my first question would be: how much power does Red Hat have in these relationships with the OEMs? Will the OEMs simply steal all the margin on the product from Red Hat?

    That's actually three questions: first, what does Red Hat really do? Its primary function is to act as an interface between the Linux technical community and people who believe that "support" has to be contractual and paid for. All its other functions - packaging, some customization, some development contributions, forums, on-line and call center support, and so on - derive from its role in interfacing reality to the expectations of previous generation IT managers.

    Second: Red Hat has very little power over its OEMs and what it does have derives from legal issues affecting those OEMs, not its own products or services. IBM, for example, cannot now push a Linux distribution of its own because its deep pockets would encourage lawsuits over code use.

    Third, no: since IBM needs to keep Red Hat in business, they'll protect Red Hat's margins and the other OEMs will be forced to deal on Red Hat's terms if they want to get to the IBM/Red Hat customer base.

  2. How large do you think the installed base of linux on x86 machines can get -- assuming we are at about 20% right now? Will Windows users migrate to Linux distributions?

    I think we'll eventually see Microsoft migrate to either Linux or BSD based Unix as their own attempts at a true network OS flounder. Meanwhile, x86 user defections from Windows Servers to Linux should continue, albeit at a slower rate than we've seen so far.

  3. How far down the Unix on RISC to x86 migration do you think we are and do you think this migration will continue? How powerful do you think Sun's move to put Solaris on x86 is? Do you think Sun will be able to grab back customers who migrated from Solaris to Linux on x86?

    First, I think x86 is technically dead with everyone (except Apple!) migrating to PowerPC (IBM, Microsoft, Nintendo, Sony), SPARC (Sun, Fujitsu), or the scrap heap of history (HP).

    Second, Yes, developers are moving to opensolaris and the CDD license in droves - people who two years ago saw Linux as their future now see Solaris continuing as their main development environment with compilation for Linux a marketing, not a technical, decision.

  4. Have you noticed any trends on the x86 OS pricing? Is Windows pricing coming down? Is Red Hat and Suse pricing coming down?

    Yes, and No. Nominal prices are coming down, but long term agreements and premium services are driving actual costs as measured by checks written up.

  5. What other key questions should I be asking about Red Hat's Business future?

    What happens the day after SCO wins and/or IBM settles.

  6. Is there anyone else who you would suggest that I talk to about these sorts of questions?

    Yes, many of my regular blog readers know more about Red Hat than I do.


Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.