Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Linux Business Red Hat Software Linux

Red Hat Nears $1 Billion In Revenues, Closing Door On Clones 201

darthcamaro writes "Red Hat is almost at its goal of being the first pure-play open source vendor to hit $1 billion in Revenues. Red Hat reported its fiscal 2011 revenues this week which hit $909 million. Going forward, Red Hat has already taken steps to protect its business by changing the way it packages the Red Hat Enterprise Linux 6 kernel, making it harder for Oracle to clone. 'We are the top commercial contributor to most of the components of the Linux kernel and we think we have a lot of value and we want to make sure that, that value is recognized,' Red Hat CEO Jim Whitehurst said. 'In terms of competition, I don't think we necessarily saw anything different from before but I'd say better to close the barn door before the horses leave than afterwards.'"
This discussion has been archived. No new comments can be posted.

Red Hat Nears $1 Billion In Revenues, Closing Door On Clones

Comments Filter:
  • by Anonymous Coward on Thursday March 24, 2011 @07:29PM (#35606394)

    CentOS and Scientific Linux are still workable, it's the "enhanced clones" like Oracle and Novell that are cherrypicking RHEL's best customers and not giving back to the open source community with development in open source filesystems, X, authentication, and genuine hardware support that are messing up the business.

    It's just too bad CentOS has lost its way with one of its developers, Johnny Hughes, telling people to not let the door hit them in the ass on the way out if they don't like how late everything is and then ignoring attempts to help. I just switched to Scientific Linux and and am quite happy.

  • Re:Oh no... (Score:5, Informative)

    by Enderandrew ( 866215 ) <enderandrew&gmail,com> on Thursday March 24, 2011 @07:30PM (#35606406) Homepage Journal

    CentOS is fine, because they're a 100% clone of Red Hat. Red Hat is putting their kernel patches together instead of separate. If you wanted to pick and choose which ones you used and make something different, it would be *slightly* more difficult. But considerate the last release was broken out. You know what they were starting with. Take a diff of the new patchset against the old one, and you should have an idea of what they've changed or added.

  • by mister_playboy ( 1474163 ) on Thursday March 24, 2011 @07:33PM (#35606460)

    Had you clicked on the link, you would know the GP is a troll who has been posting goatse links on throwaway accounts.

    UID over 2 million + link to blog.com = troll.

  • by MrClever ( 70766 ) on Thursday March 24, 2011 @07:37PM (#35606498) Homepage
    Under the GPL, my understanding is that RedHat need to make the source code available. This then allows CentOS to grab the source (RPMs) and re-badge/recompile it into a new distribution. So I don't think this distro is going away any time soon.
  • by petermgreen ( 876956 ) <plugwash@nOSpam.p10link.net> on Thursday March 24, 2011 @07:38PM (#35606504) Homepage

    Straight clones should still be possible as long as redhat complies with the GPL, the main things their changes to kernel packaging will do it

    1: make it harder for unrelated distros (e.g. debian) to pigyback of redhats long term support work for kernel releases
    2: make it harder for anyone else to provide high quality support for redhats patched kernels by making it much harder for them to answer the question when something goes wrong of "what did redhat change and why".

  • by F.Ultra ( 1673484 ) on Thursday March 24, 2011 @07:40PM (#35606524)
    It means exactly nothing for CentOS. CentOS clones the RH kernel 100% anyways and is not interested in the individual patches. This is only to stop Oracle from selling support contracts for Red Hat installations. So it has exactly nothing to do with cloning and everything to do with support (in order to support RH systems, Oracle would need to know which patches RH has and more importantly: why).
  • by ustolemyname ( 1301665 ) on Thursday March 24, 2011 @07:52PM (#35606632)
    I'm confused. How on earth do you think Novell is cloning RHEL? They are a significant contributer to linux, 3rd from the top [networkworld.com], and non-trivial user ecosystem (they supplied the devs who got alot of the new AMD graphics stuff going, as I recall.) Big contributers to KDE and libre office. If they contribute less then redhat, that would only be because they have less staff (I think... at least the suse part of them does, for sure).

    Suse is as different from RHEL as debian is. Yes, they both use rpms. That's about it.
  • by h4rr4r ( 612664 ) on Thursday March 24, 2011 @07:54PM (#35606648)

    RedHat employs Kernel devs, their patches go directly into upstream. This is for patches that will never make it into upstream for that kernel. Basically all the stuff RedHat backports to the old crusty kernels they use.

  • by kmdrtako ( 1971832 ) on Thursday March 24, 2011 @08:05PM (#35606754)

    ...fewer of their patches will be incorporated upstream, so they have to spend more work porting them into each new release; they'll have less community review and bugfixes in their patches; and they're going to alienate the community.

    I guess it's not well known, even though it's not a secret. Red Hat pushes their fixes upstream first. After, and only after, they are accepted upstream are they then incorporated into the RHEL kernel.

  • Scientific Linux 6 (Score:5, Informative)

    by KainX ( 13349 ) <mejNO@SPAMeterm.org> on Thursday March 24, 2011 @08:24PM (#35606920) Homepage

    Scientific Linux 6 is already out. See http://ftp1.scientificlinux.org/linux/scientific/6.0/x86_64/os/sl-release-notes-6.0.html [scientificlinux.org] for their detailed release notes. If there was any doubt in your mind that the direct rebuild projects are unaffected by this move, there shouldn't be any longer.

    It's pretty clear they're trying very hard this time around to stay in lock-step with upstream (what they call TUV and what CentOS calls PNAELV) and add fewer packages into the mix directly. They're also funded to do this work full-time by the US government, and since many universities and national labs rely on SL, it's not going away any time soon.

    If you've never tried it before, I encourage you to do so. To quote the old tagline, it's already ready already.

  • by seifried ( 12921 ) on Thursday March 24, 2011 @08:29PM (#35606976) Homepage
    http://lwn.net/Articles/222773/ [lwn.net]. Red Hat plays very well with others. Part of the problem is the logistics, with Git and new Kernel development you're looking at literally thousands of source code patches (which would make for a completely unwieldy SPEC file) because Red Hat back ports stuff to keep a stable Kernel in the Enterprise Linux..
  • by larry bagina ( 561269 ) on Thursday March 24, 2011 @08:46PM (#35607102) Journal
    oracle is funding btrfs development.
  • by Anonymous Coward on Thursday March 24, 2011 @09:25PM (#35607302)

    It wont be a problem because all the patches/fixes end up in git form upstream first, before they even hit a shipping RHEL kernel. Because of this, there is no confusion. I don't think you even use Red Hat Enterprise Linux as a product as you can't pick and choose patches and still remain in support for that modified package. You may as well just build upstream and port back those security fixes you need, which you can do because the fixes are pushed there first.

    If this is the case, and I'm just imagining out loud, you don't use a Red Hat product or understand what they offer.

  • by doomy ( 7461 ) on Thursday March 24, 2011 @09:50PM (#35607400) Homepage Journal

    Straight clones should still be possible as long as redhat complies with the GPL, the main things their changes to kernel packaging will do it

    1: make it harder for unrelated distros (e.g. debian) to pigyback of redhats long term support work for kernel releases 2: make it harder for anyone else to provide high quality support for redhats patched kernels by making it much harder for them to answer the question when something goes wrong of "what did redhat change and why".

    Debian does not use Redhat kernels. Two different distributions, packing systems and philosophies.

  • If you round off their 2010 income numbers, subscription income totals to $639 million (85.3%), and training service income totals to $110 million (14.6%). That is all on page 40 of their 2010 Annual SEC (10-K) filing [redhat.com]. The subscriptions had a 93% profit margin, and the training had a 36% profit margin this year. Which makes sense, I imagine training services cost quite a bit, you would probably have equipment and training material costs, as well as trainer's salaries. Then, at least some of the time, there would be travel and hotel costs incurred for the trainers themselves, anytime they are training groups.

    According to page 48 of the same report, they spent $272 on sales and marketing, which the fancy training mailer pamphlets would fall under. However, that would also include expenses from sponsoring Open Source conferences under the same line item (its not all wasted on those fancy pamphlets).

    Research and Development I imagine covers salaries for Kernel and subsystem developers. R&D costs total $148 million. Administrative costs were $104 million. According to the 10-K report, they have 3,000 employees globally.

    Total operating expense for 2010 was $534 million, once you have tacked on taxes the Net income comes to $87 million.

    There is a lot of boring stuff in SEC filings, most always something interesting to learn from them though. If you really want to find out what a company is all about, there are some interesting details, a lot of it is in there. It explains in brief detail what each line item in the Balance Sheets and Income Statements actually mean in mostly plain English. Plus, the executive summary gives you some insight into their management's frame of mind, business model, and strategies.

The moon is made of green cheese. -- John Heywood

Working...