InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Red Hat splits JBoss development tree, acquires MetaMatrix

Posted by Rob Thornton on Apr 24, 2007

Sections
Operations & Infrastructure,
Enterprise Architecture,
Development,
Architecture & Design
Topics
Java ,
Acquisitions ,
Application Servers
Tags
MetaMatrix ,
RedHat ,
JBoss

Red Hat made two big announcements today at a press conference about their middleware strategy. First, they're separating JBoss into two branches, similar to what they did with Red Hat Enterprise Linux and Fedora. Secondly, they have acquired all the assets of MetaMatrix, provider of federated data services and metadata management to boost their SOA offerings.

Splitting the development branches of JBoss will result in JBoss.org housing the community branch and redhat.com/jboss holding the enterprise branch. Dennis Byron was at the press conference and believes it was motivated by JBoss not providing the expected revenue boost. Red Hat will only be supporting the enterprise branch, but they will support that for seven years. Sacha Labourey explains the split and how it will function, including the differences from the RHEL / Fedora split:

While this new development, distribution and support model looks and smells a lot like the good old RHEL/Fedora model applied to Red Hat's Linux distribution, it is not exactly the same. While the rules are the same with regard to the binaries, the JBoss source code will remain public and accessible during the complete Enterprise lifecycle activity, not just for specific release snapshots.

The second announcement was the acquisition of all of the assets of MetaMatrix. Some questions about the acquisition are answered by Red Hat, including that the motivation was to build out their SOA stack. The addition of MetaMatrix's assets will allow them to better support data-intensive workloads. The MetaMatrix products will be integrated into the JBoss line and while initially be available only via subscription, will be open-sourced eventually.

We recommend by A A Posted
Hardly surprising by Rod Johnson Posted
Re: Hardly surprising by douglas dooley Posted
Re: Hardly surprising by Rod Johnson Posted
Re: Hardly surprising by douglas dooley Posted
Re: Hardly surprising by Rod Johnson Posted
Why Red Hat Split Up jboss Community and the Productization Group by Dennis Byron Posted
  1. Back to top

    We recommend

    by A A

    If someone want to know what will happen with this Jboss split, just look at RHEL and Fedora ... Fedora is for community and it is not recommended for enterprise.
    May be we'd better think about creating "enterprise Community" and "community Community" !

  2. Back to top

    Hardly surprising

    by Rod Johnson

    Hardly surprising, as Red Hat have been successful with the Fedora/RHEL model in their bread and butter Linux space. It's perhaps surprising it took so long for this change to happen. It's also probably significant that, now Marc Fleury has left and Rob Bearden, Bob Bickel, Brad Murdoch and other key execs at JBoss Group are long gone (as well as the VCs, who contributed a lot to the strategy), the architects of the original JBoss model are no longer with Red Hat.

  3. Back to top

    Why Red Hat Split Up jboss Community and the Productization Group

    by Dennis Byron

    Rob, thanks for the reference to my blog.

    Just FYI, I did not mean to imply that Red Hat specifically made this organizational change because the revenue numbers were lower than expected, only that it updated its overall JBoss strategy for that reason. Probably more important in terms of getting the numbers where they want them is the announcement of the stack integration and the new development tools.

    Dennis

  4. Back to top

    Re: Hardly surprising

    by douglas dooley

    What is significant is that JBoss continues to be core to the Red Hat value proposition and the announcement supports the initial attempt to make JBoss the default middleware layer for Linux. I wonder how much will this limit the attempts to make it cross-OS, such as Longhorn and Solaris-next, with so much of the resources being put in to support models that are conducive to the Red Hat business model of Linux-only.

    I wonder what this means for the app server market in general, as more of the 'owners' of OS platforms come out with tightly integrated or at least strategicly integrated app server platforms. I guess WebSphere will continue to be all-purpose, but if you're a Red Hat customer, and new to app servers, what would you buy JBoss or WebLogic? If you're a Solaris customer, and new to app servers, what would you buy Glassfish or WebLogic?

    It makes one wonder where the oxygen comes from for certain vendors...

  5. Back to top

    Re: Hardly surprising

    by Rod Johnson

    Historically there has been very little linkage between app server choice and OS--witness the ubiquity of Solaris and the relatively low market share of Sun app servers in the past. Now Glassfish probably will get traction, but that's because it's a good product, not because it comes from the OS vendor.

    Being that dependent on one vendor isn't necessarily good, either. Microsoft is always likely to win that battle, anyway: they can provide the OS, the app server, the language, tools and database as well.

    I wonder how much will this limit the attempts to make it cross-OS, such as Longhorn and Solaris-next, with so much of the resources being put in to support models that are conducive to the Red Hat business model of Linux-only.

    I wouldn't expect it to limit JBoss on other platforms. It would be a grave mistake to do so.

  6. Back to top

    Re: Hardly surprising

    by douglas dooley

    The infamous one-throat-to-choke is a bit over-the-top as euphimsms go, but it does become a reality for corporations that have heavily invested in production sites. And don't tell Oracle that this model won't work, because they just spent $25B to prove that consolidation, and that one line of support is the best allotment of resources will be the prevailing model.

    I would argue that in order to begin any process of innovation, that you first need to standardize your infrastructure, and begin simplifying your IT environment, which is exactly what Red Hat, Sun, IBM, and Oracle are betting on, although I don't see OC4J to be sufficient for this excercise which is why they need to buy BEA, and BEA needs to sell to ORCL in order to be considered in enterprise-wide deployments.

    JBoss recognized the writing on the wall, not that they could not scale for developers, which they can do via jboss.org, but how they would scale for enterprise support. I am not convinced that BEA, and I am sorry to say, Interface 21/Spring, can scale to take-on enterprise deployments without a parent with relationships and expertise with Fortune 2000 companies.

  7. Back to top

    Re: Hardly surprising

    by Rod Johnson

    I am not convinced that BEA, and I am sorry to say, Interface 21/Spring, can scale to take-on enterprise deployments without a parent with relationships and expertise with Fortune 2000 companies.

    Are you saying that BEA does not has relationships and expertise with Fortune 2000 companies?? WebLogic has long been one of the market leaders in the enterprise space. And BEA's product line is broadening.

    As for Interface21, we have dozens of Fortune 2000 clients with many large Spring deployments. Including nearly all of the world's top 10 banks. No, we do not claim to satisfy every IT need across an organization: just that we offer the best solutions for what we do, and understand the need to integrate with solutions from other vendors. We are not convinced that a one stop shop is in the best interests of customers, in any case.

    There can never be a one stop shop in large enterprises. For example, most of our large customers use .NET extensively, as well as Java.

Educational Content

Jesper Boeg on Priming Kanban

In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.