United States (change)
Shortcuts: Downloads Fedora Red Hat Network
On April 26th 2007, JBoss, a Division of Red Hat, held an IRC chat with JBoss CTO Sacha Labourey. Shaun Connolly, Senior Director, JBoss Product Management moderated the chat. The topics covered included the new JBoss developer products and subscriptions, Exadel and the Red Hat Developer Studio, the new Metamatrix announcement, how Metamatrix relates to Hibernate, and more.
| +sconnolly | Hello everybody, we will start the IRC shortly. |
| +sconnolly | Please note that #108questions is the place for you to submit your questions |
| +sconnolly | Sorry...#108-questions is the place to submit questions |
| +sconnolly | Hello, I am Shaun Connolly; responsible for JBoss products at Red Hat. |
| +sconnolly | Welcome to today's IRC. |
| +sconnolly | I'd like to introduce everyone to Sacha Labourey, JBoss CTO. |
| +sconnolly | Questions or thoughts should be submitted on #108-questions |
| +sconnolly | We will then pick the questions from there and place on #108 for Sacha to address |
| +sconnolly | Today's IRC will be focused on generating discussion around our news announced on Tuesday from a developer and community perspective. |
| +sconnolly | http://www.redhat.com/about/news/prarchive/2007/next.html |
| +sconnolly | Sacha blogged about the news: New Development, Distribution, and Support Model for JBoss |
| +sconnolly | http://blogs.jboss.com/blog/slabourey/2007/04/24/ New+Development%2C+Distribution+and+Support+Model+for+JBoss.txt |
| +sconnolly | And we'd like to hear your perspectives, questions, etc. |
| +sconnolly | So, to get the questions going, let me start with one or two |
| +sconnolly | With the new JBoss.org and JBoss Enterprise Platform split, are you concerned at alienating members of the JBoss community? |
| +slaboure | No, not at all. |
| +slaboure | the reason is that JBoss.org, the "community" side of the house, is very much JBoss as you know it today |
| +slaboure | we are not removing anything |
| +slaboure | we are adding something: a stable branch and a team that will focus on it to bring a great features many enterprises are waiting for: stability and long term commitment. |
| +sconnolly | I understand how it benefits customers, but how is it good for the community; what changes? |
| +slaboure | in the past we had to solve two problems at once: i) innovate and create new features and ii) support customers |
| +slaboure | we had to find a middle ground to make everybody happy |
| +slaboure | as we grow the number of projects, releases, etc. this equation becomes very hard to maintain |
| +slaboure | hence we decided to give more flexibility to both the business and the community |
| +slaboure | community will be able to focus on innovation, new features, new development, etc. without feeling the "pressure" from the business side |
| +slaboure | same for the business: now they can provide long term support on specific platforms. |
| +slaboure | It is really a win-win scenario. |
| +slaboure | And if you don't care about the "stable" branch, just ignore it :) nothing will change for you then. |
| +sconnolly | when will the Exadel code be available on JBoss.org? |
| +slaboure | Sometimes during the Summer. |
| +slaboure | Work as already started at full speed |
| +slaboure | but open sourcing code is a tedious process and it is hard to predict how much time it can take. |
| +slaboure | We already have some experience from when we open sourced the Arjuna Transaction Monitor, so that helps. |
| +sconnolly | Why is Red Hat Developer Studio needed when I can just download the eclipse plug-ins from JBoss.org once they are available? |
| +slaboure | Some people do not want to build their own environment so they can get it pre-package from us |
| +slaboure | (pre-packageD) |
| +slaboure | Most of the time, the more "corporate developers" expect something pre-packaged and don't want to deal with building their own environment, we do that for them. Also, the RHDS subscription provides access to the certified platform bits. And for 99 USD, that's a bargain! ;) |
| +sconnolly | Next Question: in the news this week, the changes for JBoss have been described as "like Fedora"; how much of an influence is the Fedora experience on the JBoss model? |
| +slaboure | We mostly use the "RHEL/Fedora" name as a quick and easy way for people to understand the model. |
| +slaboure | but other than that, while we share the same issues (stable vs. innovation), developing Java middleware is different than building an operating system with hundreeds of external packages. |
| +slaboure | In fact, we could argue that we learned more from RHEL than we did from Fedora |
| +slaboure | i.e. I don't think we had to learn anything in term of "JBoss.org" |
| +slaboure | ;) |
| +slaboure | But we learned a lot from the "productization" processes that RHEL is leveraging and we will leverage them as well |
| +slaboure | Also, one key difference to the RHEL/Fedora model is that the JBoss source code (i.e. all of the JEMS projects) will be available in the same SVN/CVS repositories, at all time, in real-time, etc. |
| +sconnolly | how will we...or are we....following a similar support policy, sla |
| +sconnolly | is our subscription model aligned or different...and if different...how is it different |
| +slaboure | we won't push a snapshot from time to time: the development will follow the exact same process as the "Fedora" (i.e.jboss.org) side of the house. |
| +slaboure | So what will change is that we will now only support the "Enterprise" (i.e. stable branch) of our releases, and this with similar subscription offering (SLA, etc.) as RHEL. |
| +slaboure | By focusing our support teams on well known productized/sanitized codebases, we will be able to offer even better support. |
| +slaboure | Again, as you grow the number of projects you include in your products, the number of minor releases, etc. it leads to a combinatorial explosion that is harder to support: you cannot test all possible mixes. |
| +slaboure | Now, for the "transition period": it is still possible to get a subscription for the 3.x, 4.0.x releases. The new model will only apply to future releases of our enterprise software i.e. enterprise platforms (Application, Portal and SOA) and enterprise frameworks (Drools, jBPM, Hibernate and Seam) |
| +sconnolly | I saw news saying that Metamatrix was kidnapped into OSS. Why the MetaMatrix acquisition? |
| +slaboure | LOL! |
| +slaboure | Speaking of kidnapping, MetaMatrix is a great way to FREE your data. |
| +slaboure | In a typical enterprise environment, database are usually the most difficult software to "move" (i.e. replace, change meta-model, merge, etc.) |
| +slaboure | MetaMatrix permits that kind of change |
| +sconnolly | I've readed on the metamatrix webpage that have several clients in the States, being Red Hat a global company, would need to localize, provide training, etc to metamatrix products... ¿there is a good customer base in EMEA like it seems to have in the States that could benefit from professional services for metamatrix products? |
| +slaboure | Imagine that you have 5 applications executing against a database. Imagine that you need to modify this database for whatever reason: it might be because you have duplicate data silo in your company, or because you want to modify the schema or because you want to a new DB) |
| +slaboure | Each new application you are going to develop against that DB will reinforce that lock-in and further prevent you from making these changes |
| +slaboure | by leveraging MM you can substitute the DB schema with an intermediary "abstract" schema that you can map to whatever backend you have, with a different schema and possibly in multiple different databases. |
| +slaboure | I am not going to list all possibly uses cases, but that is really really powerful |
| +slaboure | MM mostly have customers in the USA and some in Europe |
| +slaboure | we will indeed i18n that software, much like all of our software. That is part of the RHT value :) |
| +sconnolly | elated to future DB freedom... there will be an "oracle compatibility" layer allowing to switch Oracle based products to work on other environments? |
| +slaboure | damned, I had not think about that use case! interesting! ;) |
| +slaboure | more seriously, yes and no. |
| +slaboure | from a schema standpoint, yes, it will definitively help you achieve DB independence (MM uses a DB-neutral SQL language) |
| +slaboure | but if you are using ORCL for other features, like RAC, then MM won't help you there |
| +slaboure | NOTE: Not sure if you are aware of that but by leveraging RHEL5 virtualization+GFS it is possible to get the HA features from RAC (not the load-balancing part) without paying for RAC |
| +slaboure | (just a hint) |
| +sconnolly | Does MM compete with or overlap with Hibernate? |
| +slaboure | no, it doesn't compete with it but nicely complement it |
| +slaboure | you can access MM in a variety of ways, including through JDBC and ODBC drivers |
| +slaboure | which means that MM is transparent from an Hibernate standpoint (including second level cache, etc.) |
| +slaboure | #NAME? |
| +slaboure | and any "legacy" reporting software you might have will see exactly the same schema using the ODBC driver for example. |
| +slaboure | (you can also use an XQuery interface, etc.) |
| +sconnolly | are MM workers enthusiast on joining RH? developing FOSS is a big change of mind for the company, or just would be an extension of the methods they already use for developing? |
| +slaboure | yes, they are very enthusiastic (at least that is what they told us... I need to verify now that you raise that ;) ) It is indeed a change for them and we will make sure to help them through that trip on the JBoss spacecraft. |
| +slaboure | But we had great success in the past |
| +slaboure | Look at JBoss ESB and Mark Little. |
| +sconnolly | My main concern is that Fedora-izing JBoss will leave the original open source flavor - perception is that fedora and RHL are different in many core ways |
| +slaboure | Mark came through the Arjuna DTM acquisition and he is now leading a very vibrant JBoss ESB community and took on leadership of the SOA platform |
| +slaboure | Reality is that unlike RHT for Linux we are NOT Fedora-izing anything: that is the opposite. |
| +slaboure | We ALREADY have Fedora, it is called JBoss.org |
| +slaboure | it is the JBoss you know today. That is not going to change. |
| +slaboure | What we are doing is RHEL-ifying JBoss by creating a stable branch that will go through our 3 engineering steps: sanitization, productization and packaging. |
| +slaboure | This RHEL-ification will provide enterprise with what they are expecting from any software vendor, OSS or not: a stable release with long term support commitment with backward compatible API. |
| +slaboure | On the other hand, the ".org" part of the house will enjoy more flexibility and freedom. |
| +slaboure | I am back |
| +sconnolly | ... but wouldn't JBoss.org benefit from the same steps? Wouldn't you WANT to do that already? |
| +sconnolly | I mean, J2EE and Java EE BENEFIT from stability... why would you WANT the additional flexibility except from the microkernel capability? |
| +slaboure | This move is not "just" about Java EE, it is about the bigger picture: Seam, jBPM, Drools, JBoss Cache, etc. |
| +sconnolly | So all of those techs are getting the same "treatment?" |
| +slaboure | and even for "stable" environments like EE, you still got many parts that can become incompatible: private API (I guess you realized that EE doesn't cover all needs :) ), configuration files, etc. |
| +slaboure | As part of the announcements, we announced the availability of "platforms", that package several of the JEMS products. So, yes, as part of the platforms, these various projects will get RHELified as well. We will provide RHEL-ified version of the enterprise platforms (App, SOA and portal) and Enterprise frameworks (Drools, jBPM, Seam and Hibernate) |
| +sconnolly | I mean, that's a fork, pure and simple, and the mere idea is kinda scary for me as a jboss user |
| +sconnolly | so... a RHEL-ified version of seam would look like... what, compared to the jboss.org version? |
| +slaboure | that's not a fork: it is a branch. You can call it fork if it helps sell more advertisment ;) but it is really a branch. We will not ADD anything to the RHEL-ified version that is not in the JBoss.org version, again, we will REMOVE things that we thing are not stable enough, etc. |
| +slaboure | a RHEL-ified version of Seam would look like something that integrates perfectly with one of the platforms, with a specific version of Hibernate, AS, etc. that would have had gone through extensive testing on that SPECIFIC mix of project versions and that will remain STABLE for a long time i.e. if you want to put that into production and you face a bug, we will not ask you to move to the next release of Seam, we will fix that specific version |
| +slaboure | It is about what you need, for your own enterprise environment. |
| +slaboure | Enterprise customers want stability. Community wants innovation. |
| +sconnolly | so let's talk a bit about the SOA strategy. Why? Why a SOA strategy at all? |
| +slaboure | See http://www.redhat.com/promo/next/ |
| +slaboure | SOA is really a way to migrate to a new architecture. We think we can provide you with a Simpler, Open and more Affordable software offering |
| +slaboure | We want you to encourage you to migrate. |
| +sconnolly | thanks everybody for joining today's IRC. We will post the log on our website within the next day or two |
| +slaboure | Thanks everybody |
| +slaboure | And stay tuned, we have great announcements in the pipe that are coming :) |
| +slaboure | Onward! |