Conversation with JBoss' Labourey on new Red Hat/JBoss strategy

Discussions

News: Conversation with JBoss' Labourey on new Red Hat/JBoss strategy

  1. Sacha Labourey was on a hosted IRC chat recently, addressing questions about JBoss' acquisition of MetaMatrix, their new SOA strategy, the partnership with Exadel, and the "RHEL-ification of JBoss," by creating a "stable branch that will go through [three] engineering steps: sanitization, productization and packaging." Here's part of the chat, slightly reordered to provide continuity. Sacha is "slaboure," and the moderator asking the questions is Shaun Connolly, "sconnolly," who posted questions from users in near real-time:
    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. 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. 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. sconnolly:So all of those techs are getting the same "treatment?" 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:so... a RHEL-ified version of seam would look like... what, compared to the jboss.org version? sconnolly:I mean, [this is] a fork, pure and simple, and the mere idea is kinda scary for me as a jboss user 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.
    What do you think? Do you have any questions you'd like to have seen asked?
  2. 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.
    Translation: RH has no idea what to do with this tool they have overpaid for and whose high-priest they've lost, so they go the "tried" route - the one they've used so many times... incidentally, it is also the one that has failed so many times, but who counts :)
  3. ... so they go the "tried" route - the one they've used so many times... incidentally, it is also the one that has failed so many times, but who counts :)
    Have you ever talked to someone who has to operate a J2EE application in production. Try to make them update the app server, or even try to make them upgrade the JVM. You will be surprised! What version of the JDK is WebSphere running on again? :-)
  4. doh! that's a low blow. everyone knows Websphere is always behind all the other ejb containers when it comes to supporting the newest specs. heck, a lot of people are still using websphere4. peter
  5. What version of the JDK is WebSphere running on again? :-)
    Exactly the point - RHEL will try to make a WebSphere out of what was 10 times better to begin with... Sad. On another topic - those who fear the upgrade of JVM and/or app. server happen to be the same folks who preach the "don't touch it if it works" mantra. I happen to be in the continuous refactoring / agile development camp.
  6. Exactly the point - RHEL will try to make a WebSphere out of what was 10 times better to begin with... Sad.
    Irakli, I am not sure you properly understand what we are announcing. This is NOT about "trying to make" ANOTHER application server. This is about the SAME codebase that will go through ADDITIONAL productization/packaging steps for our enterprise customers, so that we can better support them. If you do not want to use that "specialized" version of the AS, fine, keep using the other one, nothing is changing on that front. Onward, Sacha
  7. Exactly the point - RHEL will try to make a WebSphere out of what was 10 times better to begin with... Sad.


    Irakli,

    I am not sure you properly understand what we are announcing.

    This is NOT about "trying to make" ANOTHER application server. This is about the SAME codebase that will go through ADDITIONAL productization/packaging steps for our enterprise customers, so that we can better support them.

    If you do not want to use that "specialized" version of the AS, fine, keep using the other one, nothing is changing on that front.

    Onward,


    Sacha
    Sacha, in case it did not come across clearly - I am bitter because I am huge fan of JBoss and would hate it to become another WebSphere - not as in code-base but as in - monstrous, inflexible, usual low-grade corporate crap driven by the perceptions of clueless managers, rather than knowledge of engineers. Application server is a rare product that is "from developers, for developers". Developers can not be bullshitted as easily and therefore it needs a lot of care. I am sure JBoss old-timers like you do get it, not so sure about - RedHat folks. You are talking about "ADDITIONAL productization/packaging" and it smells bad, to be honest. JBoss is an open-source product. Dare I remind the mantra of open-source? "Release early, release often". If RedHat gets it - what happened to RedHat Enterprise Application Suite? I am talking about the code they purchased from Arsdigita and that died without ever seeing the light of day? If I understand correctly, RedHat does, what it intends to do with JBoss, with the whole EL/Fedora thing, right? Does it really work? Just because sales did not drop much, does not mean it does. RedHat is still strong in the enterprise linux arena, only due to its distribution channels. Every other major server vendor (HP, Dell etc.) has all its hardware tested with RH Linux, and most of the time offer it with RHEL preinstalled. That is why most people use it. Otherwise, I personally would definitely go with Debian or Ubuntu and never look at RH twice. I can assure you, many users feel the same. So it is not the model that works but the distribution channel, in case of RHEL. What about JBoss? Well, JBoss is not an operating system. You do not need to test hardware with it and make sure all drivers work, so the threat of substitutes is way higher. I am just afraid that with the short-sighted approach RedHat will burry JBoss or make it much more inferior. Again - release often, release fast. JBoss did not have any stability issues the way it was. RH is trying to pull a marketing trick and IMHO it is going to bite back. It's no Linux.
  8. On the other side of the coin. What happens if you work at a large institution, which has an official 5 year cycle process. By that I mean, a release has to be in production for 4-5 years before it goes through an upgrade. Large corporations are huge beasts and have lots of red tape. Getting the approval and process ready to do a massive production upgrade isn't a trivial task. of course small companies don't have these kinds of long drawn out processes that suck up months and years of developer's life. Maybe RedHat's main customers are the large corps which have kinds of processes? Just a thought. peter
  9. Every other major server vendor (HP, Dell etc.) has all its hardware tested with RH Linux, and most of the time offer it with RHEL preinstalled. That is why most people use it. Otherwise, I personally would definitely go with Debian or Ubuntu and never look at RH twice. I can assure you, many users feel the same.
    More proof that developers know shit about operations. If you have the resources to roll your own distro, you can hardly even call it "Debian" anymore. It's perhaps Debian-ish, but not the same. If you have the resources, you probably have enough machines and your own OS test and development team. If you have the resources, you probably also have people on staff that are smart enough to say, "Wow, what a stupid idea. Why pay extra for what RedHat already does? Why pay for RedHat support when we have a decent IT department? We can just use CentOS, with all of the same patches and stability of RHEL. Why use an unstable, unsupported, bleeding edge, unproven hacker/hobbyist OS when we have [perhaps] millions of dollars on the line?" Enterprise is not your bedroom PC that you can install compiz on for some fluffy windows decorations. Also, if you're worried about a stable, supported JBoss falling behind, just use the community version. OMG!
  10. More proof that developers know shit about operations. ... Why use an unstable, unsupported, bleeding edge, unproven hacker/hobbyist OS when we have [perhaps] millions of dollars on the line?" Enterprise is not your bedroom PC that you can install compiz on for some fluffy windows decorations.
    If developers know "shit" about ops, who do you associate yourself with? I have a bad feeling you think you are one of those know-it-all "architects" that put themselves above both developers and ops and spend a good portion of their day crawling forums like TSS ;) I just love to see how when people run out of the arguments they fall back to, old-and-tried "enterprise" something blah-blah. Unfortunately (for them) we all know what the reality is. The reality is that open-source was always about "compiz in bedrooms". Where do you think JBoss started and grew? Or Linux? Sendmail, Apache... should I continue? In the hallways of big-ass corporations? Sorry to disappoint you. When million dollars are on stake you need people who know how to extract the most juice out of bleeding edge innovations and, trust me - they will, indeed, test their own, custom setup. They will test the crap out of it - to be more precise. It's exactly small and short-sighted shops that are naive enough to trust RedHat's "stable" releases and suffice with it.
  11. so they go the "tried" route - the one they've used so many times... incidentally, it is also the one that has failed so many times, but who counts :)
    Red Hat's Linux model works, at least for them. They are a public company with significant revenue and profit. It will be interesting to see how it translates in practice for JBoss.
    whose high-priest they've lost
    Would be interesting to know if this is something that could have happened while Marc Fleury was still at JBoss/Red Hat. Of course not just Marc but the other architects of the former JBoss model (the VCs, Rob Bearden, Brad Murdoch and other executives) are now long gone, so it's not surprising that Red Hat are moving to something that is more familir to them.
  12. Re: App Server Models[ Go to top ]

    It is evident from the announcement that JBoss' practices of bringing everything to market will be adjusted for just 'necessary' product-lines, that allow customers to focus on core areas of deployment, while continuing the availability of development against all other product-lines. This should benefit everyone but WebLogic and WebSphere product teams, as Red Hat makes JBoss even more formidable in the go-to-market, sales environment... The app server market seems to continue unabated, even in the face of the open source mantra of hollowing-out licenses revenue, thus allowing JBoss to grow in a competitive and over-invested environment. In a sense, there is not less money to be made from app servers, just a different type of money to be made by 'controlling' customer accounts in deployment scenarios. Anyone can infiltrate a development environment, but it takes a tested enterprise vendor to make significant in-roads in deployment... The model for JBoss/Red Hat is one of footprint growth through simplicity of implementation model, by giving away the license revenue, in exchange for the partnership/support/maintenance revenue. It is not surprising to see this make inroads on BEA and IBM's market share for a variety of reasons, but mainly because they are doing reference architectures for deployment scenarios that are close to home for WebLogic and WebSphere implementations... It is expected that finally, JBoss will be able to "bait-and-switch" customers who have adhered to the J2EE model of portability across app server platforms, and are looking for either a more economical choice (vis-a-vis WebLogic) or a more-focused choice (vis-a-vis WebSphere)...it would appear that the first salvo in to the destruction of the app server duopoly market will not have been fired by Oracle but by Red Hat, as JBoss lays out its strategy for deployment, not just development models...
  13. From a technology front, this is a very good move. I've been involved in JBoss since 2002 and perhaps the only major criticism I have is that from a developer standpoint it always seemed like a bit of a moving target. Granted the target was always moving forward (unlike other containers... remember Weblogic 7?), but the fact that it was community driven and had so many passionate heads working on it meant that in some cases the resolutions arrived at came at the expense of some consistency across what may have otherwise been maintenance releases. Most people (including our team) just dealt with it. Perhaps the best example of this is in JMX object names for the internal MBeans of the app sever. Various maintenance releases would do seemingly innocent things such as changing capitalization of the MBean name from one release to another. Again, fairly trivial stuff, but stuff I'm confident will be dealt with more efficiently by this new model. -javier http://www.hyperic.com