Red Hat splits JBoss development tree, acquires MetaMatrix

by Rob Thornton on Apr 24, 2007 |

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.

Related Editorial

Impact of Java EE Frameworks on the Structural Quality of Applications

From Killer Apps to App Killers: The Devastating Effect of Architecturally Complex Defects

Cluster-Wide Caching & Scaling for the Cloud - A Look Inside Resin 4.0

Faster PHP Through Java

Free Book: Graph Databases (by O'Reilly) - Download Now

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

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

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" !

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.

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

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...

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.

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.

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.