Forgot your password?
typodupeerror

Oracle and Red Hat begin battle for the Enterprise 135

Posted by Hemos
from the the-heat-is-on dept.
Salvance writes "Yahoo News (via ComputerWire) is reporting that Oracle and Red Hat are turning up the heat in the battle over Oracle's new enterprise Linux offering. While Oracle claims they'll be able to offer their 'Unbreakable' version of Red Hat's Linux offering for half the price, Red Hat asserts that all the important security and hardware certifications would be invalidated on Oracle's offering.

At this point, the only thing that's certain is that Red Hat needs to figure out how to keep their large Oracle Enterprise clients on board or risk becoming a takeover target (undoubtably, with Oracle leading the list of potentially bidders)."
This discussion has been archived. No new comments can be posted.

Oracle and Red Hat begin battle for the Enterprise

Comments Filter:
  • Why Red Hat then? (Score:2, Interesting)

    by krico (678909) on Monday October 30, 2006 @10:17AM (#16641317) Homepage Journal
    The main reason for choosing Red Hat as a distribution is usually the "security and hardware certificatations". Oracle should either find a way of provinding that or otherwise use some other distribution. Debian would certainly profit very much if chosen for this ;-)
  • by Znork (31774) on Monday October 30, 2006 @10:33AM (#16641517)
    "but without undertaking any of the major development tasks (only do bugfixes)."

    The value of the support is directly related to the level of development. As a customer, once you are hit by a bug, you'd presumably want to get it fixed, and the closer to the development the support provider is, the better they will be at fixing the bugs.

    Would you pay Oracle for a support contract, only to find out they're not going to fix your bugs, they'll wait until the upstream does it? Or that they'll fix them bug, but the next resync with upstream will reintroduce it? Or even worse bugs, if the upstream produces incompatible fixes?

    Can you even imagine the nightmare of trying to maintain a patch tree while engaged in hostilities towards the upstream? Can you imagine the havoc they could wreck on your patches? Would you volunteer to maintain patches when any upstream change will mean a total reject of your patches, or even worse, subtle changes in variable names and uses that do everything from cause crashes to corrupting data? There's a reason people fork OSS projects.

    From what Ellison spouts it sounds like Oracle wants a free ride and has just failed to notice you cant get a free ride. Either Oracle will have to fork completely, or they'll have to maintain an amicable relationship with Red Hat. Which probably means carrying their own weight. Which means that Red Hat gains as much free patches from Oracle as Oracle does from them.

    "This is not going to be an easy battle for Redhat."

    Oracle offers a subset of Red Hat support at a slight discount. Red Hat offers replacements for much of Oracles stack at a minute fraction of the price. I fail to see why Red Hat would be the one that has anything to be worried about.
  • by RAMMS+EIN (578166) on Monday October 30, 2006 @10:53AM (#16641787) Homepage Journal
    ``It has always seemed relatively obvious to me that most OSS software companies are vulnerable to this type of attack mounted by a large proprietary software vendor. Take the software (which, at the end of the day is where the real value is),''

    I'm not so sure the real value is in the software. People and, especially, companies seem to be willing to pay more for support contracts than for software. They'll even take inferior software over superior software if they can get a support contract that way.

    ``and offer support, but without undertaking any of the major development tasks (only do bugfixes).

    The OSS competitor has two choices: continue to do R&D work on the product, to keep it advancing, and accepting that they can't sell support as cheaply as the "bug-fix only" proprietary vendor, or stop doing R&D themselves, so that they can be cost-competitive. Of course the disadvantage of this approach is that the product quickly falls behind proprietary offerings....''

    The "bug-fix only" vendor has the same problem: if nobody does R&D on the product, eventually, nobody will want to pay even for the support contracts. So they have an incentive to continue the R&D.

    Also, when the product is under the GPL, everyone enhancing it and distributing the enhanced version is required to make the enhancements available to the world, so R&D will continue as long as _someone_ is doing the work. The incentive for doing the work may be other than monetary, and, in fact, a lot of what OSS is today has been done by volunteers.

    ``This is not going to be an easy battle for Redhat. I suspect they are going to have to find a new business model if they are to survive.''

    They can, and do, include proprietary code in their product and charge for that.
  • by sfvg (1019312) on Monday October 30, 2006 @03:02PM (#16645929)
    Sometimes it is all about the money. So Oracle might get a bigger piece of the pie, who cares? In business its all about the ROI and SLA. A few things we know: 1. You will need a database. If the company standard is Oracle or the application is cert'd for Oracle, you will run Oracle. 2. You need support for the entire stack. Who cares where you get support from as long as you can meet your SLA's and ROI. 3. You need an OS to run your database. Why not use Enterprise Linux from Oracle if the database from #1 is cert'd for Enterprise Linux and they can fully support it. Many people are missing the point of Oracle coming out with Unbreakable Linux and Enterprise Linux. If Oracle customers are needing an OS to run Oracle, why not have Oracle support it. No finger pointing between vendors. If Oracle can support Linux cheaper and quicker, the ROI is realized quicker, which keeps the C-Level people happy while meeting the SLA's of the business unit paying the bills. For Oracle they keep more of the pie. Plus with RAC, UBL, and Enterprise Linux, most of the stack is now a comodity. Check out http://www.theciocompanion.com/ [theciocompanion.com] for my other posts on this.

"We learn from history that we learn nothing from history." -- George Bernard Shaw

Working...