This week, we announced a partnership with eXo – creator of the Open Source eXo platform. This strategic agreement allows us to integrate and distribute each others’ technology thus providing a mutual competitive advantage. This is no doubt good for both company’s products but I think the important point is that JBoss is 1. willing to do this and; 2. able to do this.
Taking the first point – “we’re willing to do this”. I think it shows a level of maturity in our organization that stands us apart from some of our Open Source competitors. The realization that not everything needs to be invented here; that there are smart people outside JBoss as well. There’s a tendency – call it NIH Syndrome, Professional Pride – to want to own and control everything; that’s true for every engineering and product company I’ve ever worked for. When taken too far – that can be at add odds with Open Source and diminishes some of its advantage.
Taking the second point further - “we’re able to do this”. Our business model is still pretty unique – we put less value on the bits and more on the whole experience. Control of the technology is less of a competitive advantage than some of our competitors because we have more to offer than the bits.
While proprietary software has some advantages – they’re all based on the premise that your technology is better than your competitors and keeping it hidden maintains some kind of advantage. This can only really be true half the time.
Red Hat has the knowledge and experience that allows us to collaborate, allows us to integrate and support technology that we don’t outright control. We’re also confident in ourselves, our brand and our business strategy – and that allows us to see the act of ‘enriching’ other technology (like Apache, OpenJDK, GWT, eXo, etc.) as a way to grow our footprint, capabilities and potential rather than as a competitive faux-pas.
Some more info on the agreement from eXo : About The eXo Partnership
From the “release early and often” files :
JBoss Messaging 2.0 beta is out. According to JBM lead, Tim Fox – New features include, performance, performance, performance, flexible clustering, seamless high-availability, large message support. See Tim’s announcement for details.
Thomas Diesler has some thoughts on how the JBoss Microcontainer could fully implement the OSGi spec. It will be interesting to see the results of this and it will be a great example of the power and flexibility of the JBoss architecture. JBossOSGi 1.0.0 Beta2 was released last week.
If you are eager to try out Eclipse 3.5 / Galileo and want to explor the upcoming features in JBoss Tools / JBDS you now can – JBoss Tools 3.1.0.M1 is available. See what’s new and noteworthy.
The recently released Seam 2.1.2 includes improved support for JAX-RS (RESTful web services) – more details here.
Finally, we have a free online seminar tomorrow (June 10th) at 9am EDT, 3pm CEST which covers Web Beans (JSR-299 / JCDI – Java Contexts and Dependency Injection). More details here.
As expected, JavaOne was interesting. For the first time in 12 years I actually attended more than a couple of sessions; but that isn’t why it was interesting. It was interesting because we witnessed the ceremonial passing of the Java One torch from Sun to Oracle and a fairly public goodbye from Schwartz and McNealy.
By all standards it was a pretty lightly attended Java One – I expected it to be a lot lighter given the economy, the uncertainty around Java and the Bacon Fever – so I was actually pleasantly surprised. Outside of Sun itself – I think JBoss was probably the largest software vendor on the pavilion floor – that says something.
Despite the low attendance overall – we had very solid attendance at our mini-theatre sessions – I think ours was one of the few booths that drew a crowd (without having to give stuff away) – so all in all it was a good show for us.
I’d be very surprised if this wasn’t the the last Java One; and as the crews started dismantling the pavilion – I felt like I should be trying to rip down a sign or banner – some memento to remind me of the fun times I’ve had at Java One over the years.
A lot of people were questioning the future of Java at the show (as usual) but I still firmly believe it’s going to be safe enough for the next 20 or 30 years – more than long enough for most of us. I don’t think Oracle will do anything stupid; though given the size and complexity of Sun I think they’re bound to make mistakes – it’s up to us to tell them when they do and to help resolve them.
As anyone who knows Java One – it’s about the people you meet – not the content. And so it is with Java – it’s about the people / community / ecosystem – at the end of the day – no single company has really owned Java for a long time.
Update : My pictures and Marek Goldmann’s pictures on Flickr.
Earlier this week we announced a couple of things. First, a change in our platform strategy, second some new products to implement that strategy. We felt we had to give that strategy a name and “Open Choice”, while unoriginal, best illustrated what we’re doing. And what we’re doing is expanding our support to include Open Source technologies beyond what we’ve typically supported and beyond the JBoss constellation.
This is a reaction to a) customer demand; and b) the realization that not all the cool stuff is created by JBoss. What we’re also doing is reacting to market demand. Java EE, while hugely successful is not the only game in town any more.
We want to ensure that our customers get to choose whatever frameworks, languages, development models they want without causing major disruption for the operations people who have to manage the applications for the other 90% of the application lifecyle (ie. outside development). We also want to remove the risk of deploying new developer oriented tech. by providing a stable, consistent operational footprint (JBoss) to run the resulting apps.
Note – I normally don’t use Job Trends data in isolation to make serious decisions, but it’s convenient and lazy way to find what keywords are trending.
So yes, this is a reactive move; we’re reacting to customer demand and market pressure – we’re really not reacting to anything that Spring Source is doing. I’ll post another blog explaining what we’re including in our Web Framework Kit and why; but Spring Framework is included for much the same reason as struts – they’re mature technologies and both are very widely deployed :
It’s no secret that a big chunk of our business comes from our much larger but less nimble competitors and we have to ensure that migration is a simple and low risk proposition.
As the chart shows (if you have any faith in the data) – Spring Framework usage is fairly evenly distributed across the Java container landscape. By making JBoss a better place to run Spring (among other things) – I believe that we can change this landscape dramatically.
This really isn’t about Spring Source – in fact we don’t even compete with Spring Source. Our sights are set much higher.