Sacha Labourey IRC Chat Log

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 Sacha blogged about the news: New Development, Distribution, and Support Model for JBoss
+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 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, 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
+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 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 ""
+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 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" ( 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
+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 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 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 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
+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!