Mark Little

JBossAS 7 is coming!

Posted by Mark Little Jun 4, 2011

Unless you've had your head in the sand for the past 18 months then you can't fail to have noticed the releases of JBossAS 6 and then the move through various betas of AS 7. Well we are on the final leg of what at times has seemed like a marathon and at others like a sprint. The team, which includes the various individual project teams, productisation teams, docs and QE, have been working flat out and I can tell you all that once we are finished with the EAP 6 release we will party!


But when AS 7 finally comes out why should you be bothered, especially if you're a user of one of our current releases? There are many reasons and some of them you would probably expect us, or any vendor, about to release the next shiny new product to talk about. So I could talk about the significant performance improvements we've made across a range of projects, such as HornetQ, JBossTS and Hibernate. I could also mention the reduction in runtime footprint that enables us to run the application server on a plug computer. Of course you probably already know about the rapid boot time and additions to our eclipse tool suite that make it one of the top Eclipse downloads. And you may have experienced first hand the developer-oriented features such as the new logging or streamlined build processes. So I'm not going to mention any of those things!


Instead I'm going to concentrate on a few of my personal favourites as well as those of the rest of the JBoss team. So in no specific order, here are 10 things you really need to know about JBossAS 7:


1: full and web profile implementation of Java Enterprise Edition 6. Of course we've been heading in this direction for a while, with previews in JBossAS 5 and a web profile in JBossAS 6, but this time we'll complete that journey and in style! Implementing EE6 is a challenge that only some vendors can match, but implementing it in a way that really shows the full power and flexibility of the standard is a far better and meaningful approach! Several of the key components within our application server have either been rewritten or updated to become best of breed, such as HornetQ, RESTEasy or Infinispan, or were best of breed to start with, such as JBossTS, Web Services or JGroups. If the whole is greater than or equal to the sum of its individual parts then this isn't just any old EE6 implementation, it's the best EE6 implementation!


2: a core part of EE6 and one of it's greatest improvements over previous versions, is CDI. This is a specification which we lead and drove through the JCP and where we also provide the reference implementation, Weld. The specification grew out of our experiences with Seam as well as various legacy frameworks that rely on XML for bindings. CDI makes the development of complex applications straightforward because it hides all of the complexities of non-functional capabilities such as transactions and security. And importantly it does this through annotations, so that you develop using POJOs, which is far more natural for Java developers than early 21st century techniques!


3: a new modular services container replacing the JBossAS 5 & 6 microcontainer. Now before you roll your eyes and move on to the next item, I know better than most that modular containers have been around for a long time. The original Bluestone Total-E-Server/HP-AS was one of the first implementations and we even created a JSR called the Core Services Framework to try to standardise on this type of architectural approach. And JBoss has had a couple of goes at this too. But this time we went back to basics, with the Modular Services Container, and wrote new algorithms for checking module/service dependencies at deploy and run time, such that only the services you need are loaded and started, and when no longer needed unloaded. You no longer have to trim your deployment to get a minimal memory footprint and start time: we give you them out of the box, and if you add your own services later to create new "profiles" then you can be sure that you'll always get the optimal configurations because the container will enforce that for you. As I've said several times over the past year or so, this is very much a SOA-like approach.


4: no more classloader hell! In conjunction with the MSC redesign, the team also took the opportunity to rewrite the book on how classloaders work. Now how you use classloaders, what type of classloader to use and when, are much more carefully defined. The modular approach makes the scoping of classloaders easier and more narrowly defined, helping to avoid conflicts: now you have to explicitly allow deployed services and applications to see and use dependencies. Oh and as a result of this rearchitecture you'll also see a performance improvement as the application server no longer scans the classpath every time a new class is loaded.


5: testable by design. Over the years we've learnt a lot about testing our projects in isolation and in conjunction with each other. Of course we use Hudson/Jenkins and we also inherited the Distributed Test Framework. But it wasn't really until the development of JBossAS 6 & 7 that we had the need to make sure that they were implemented from the ground up with testability in mind. As a result we have Arquillian which is being implemented in lock step with JBossAS 7 and also proving to be a hit in it's own right. In fact the combination of JBossAS and Arquillian offer an environment that is unparalleled in it's simplicity and power. Factor in other projects, such as Byteman, that allow for far more complex testing, such as fault injection, and you have an environment that will produce the most tested implementation yet.


6: configuration and domain management has been improved significantly. Gone are the days when you had N different configuration files for the M different components within the application server. Now there will be only one! And changing configurations is much better supported through a shell (command line) and programmatically, with both fully synchronised. If you've used Un*x shells then you'll find familiarity with the shell, with tab completion and an extensive suite of commands, which allow you to monitor and manage the application server as well as applications that are deployed on it. But beyond making managing a single instance easier, we've gone much further with clusters. Manual updates of changes to individual cluster members, often an error prone approach, have been replaced with the new domain manager, which automates the process using a master/slave or coordinator/cohort mechanism.


7: RESTful services and interfaces throughout. Of course with the adoption of JAX-RS as part of EE6, REST is now as well supported and available to application developers as Web Services. But that's not the same thing as having core parts of the application server available through REST. In JBossAS 7 we've now got projects such as HornetQ, Infinispan and management, exposing REST interfaces. And other work is being driven through the RESTEasy project as REST-Star, including transactions and security.


8: OSGi has evolved a lot over the years from its narrowly scope beginning. These days it seems that everyone is either looking to implement OSGi containers or develop their applications using OSGi bundles. A while back we announced that we would support OSGi on EAP 5 and beyond, but that we would not be using one of the containers already available. The reasons for supporting OSGi are fairly obvious, including the fact that it has become a de facto standard and we want to continue our mission of portability of applications (plus for some scenarios, such as SOA, a bundle is a very natural choice for deploying a service). But why not use one of the existing implementations? Well for a start we've got our own excellent container implementation. But realistically we want to support a range of models, so we don't want to rule anything out at this point. And our OSGi implementation on the new JBossAS7 container has improved the support significantly.


9: multiple language support. Ok, not quite a feature of JBossAS 7, but because we've made sure that we focus on developers and what they want, we've opened up a whole range of use cases that were rather difficult to do previously. So projects like TorqueBox, which offer Ruby users access to enterprise capabilities, have been able to spring up on JBossAS 6 & 7. And other projects, such as Infinispan, are finding calls for integration with, say, Scala on the rise. This is great, because it helps to showcase JBossEverywhere once again!


10: We've been sure to make the architecture of the application server cloud-friendly, so that it's the perfect substrate for an enterprise Java PaaS (and through indirection and abstraction techniques such as those employed by TorqueBox, for a much wider choice of languages as well.) Of course it's going to be a number of years before the Java Enterprise Edition standard really tackles the cloud through EE7 and EE8, but we are already pushing that envelope. If you're interested in seeing how the future of PaaS will unfold then you can get a glimpse of that by watching JBossAS 7 and beyond.


So there you go. 10 things that make JBossAS 7 stand out from its predecessors and the competition. Hopefully when you try it out you'll agree with some of these and maybe come up with some of your own (some things we may take for granted might be significant improvements in your life.) Over the next few weeks you'll see and hear more from us on AS7. And maybe, just maybe, I'll get a chance to make some more bigger announcements soon!

Mark Little

The Future of Middleware

Posted by Mark Little Jun 3, 2011

There's a special event being organised as part of Middleware 2011 called the Future of Middleware Event (FOME). I've been asked to contribute to the event and associated paper/book. It's an honour to be able to contribute to this along with others such as Doug Schmidt and Steve Vinoski (both friends I've known for a long time and who have had a significant impact on middleware over the years). It's also very relevant given everything else that I've been talking about recently. I'm looking forward to it because it'll be a great showcase for some of the things we're going to be working on over the coming years, as well as some of the things we've been doing recently!

Now that the dust has settled on JBossWorld and we've started to talk about JBossEverywhere, it's time to announce a few things that you should expect to see and be able to contribute to over the coming months and years. I want to write some of these pieces regularly to give everyone an idea of where we are going. Maybe at some point we'll create a JBossEverywhere project so there'll be the usual forums for people to use.


If you recall, one of the aims behind JBossEverywhere is to enable our projects and platforms to run on arbitrary devices. However, that is a relatively straightforward thing to achieve, at least with many of our projects. The ultimate aim is to design and implement an infrastructure that can support an application across a wide variety of environment, ranging from embedded devices through to the mainframe. To achieve this we'll be looking back as well as forward in terms of research and development. Approaches such as disconnected operation and dynamic adaptability from the 80's and 90's, genetic algorithms and event driven architectures from the past decade, and highly asynchronous distributed systems as well as the continuing rise of REST from the last few years and into the next, will be instrumental in the evolution of JBoss. But at the heart of what we will be developing will be core technologies such as JBoss Modules.


Now you may ask "will we be using <fill in the blank> as it stands?" For instance "will we be using HornetQ/JMS as it stands?" There's no stock answer that can be used, except "maybe". If you look at JMS, I think it has several deficiencies as far as Java EE goes, but it's definitely good enough. However, I don't believe it is the right API for a truly asynchronous message-oriented infrastructure. But that doesn't mean our implementation, HornetQ in this case, isn't right for that infrastructure. We've been very lucky over the years and all of our projects that support standard APIs such as JMS, JTA or JPA, tend to have far more flexible and versatile APIs under the covers. We may decide to use some of these APIs as they are, or we could provide more layers on top.


From the perspective of the implementation language, we'll obviously be concentrating on Java, but others such as Ruby, Ceylon and Scala will definitely play a role. We live in a time where multiple languages within an environment or application are the norm and to ignore that fact is either silly or arrogant. I like to think we are neither! So if you are not into Java, that doesn't mean you can't contribute. Quite the contrary: we need you more than most!


There are many questions that remain unanswered at the moment, and just as many that remain unasked. We don't have the answer to them all. I don't have the answers to them all (yet). But the fun bit is a combination of asking them and then searching for those answers. (Understanding the questions that you need to ask is often as informative as finding the answers to them.) But one question I've been asking myself for a few years is: precisely what is the abstraction we're trying to get? Well in a past life I did some work on distributed operating systems, where the abstraction presented to users was of a single, logical OS even if it spanned an arbitrary number of physical nodes/machines. (Let's ignore the facts that hiding distribution is often not the right thing to do!) This is the kind of abstraction I think makes sense for JBossEverywhere: the abstraction of a single logical middleware layer, even if it spans an arbitrary number of machines of an arbitrary type, e.g., mobile, mainframe or laptop. Domain specific APIs, such as Java EE, layer on top of this, adding or hiding capabilities where necessary. Because of course whatever we develop has to continue to be used within our EE suite of projects and platforms.


So does this mean, for example, that you can expect to see JBossAS running on natively on, say, an Android device? Well I really don't see why not, from a technical perspective. And I'd love to see it happen, as it's a logical extension of some things I started (and implemented) almost 2 decades ago! But this will be a long R&D process and the journey will be as interesting and innovative as the end results. And I'm loving the times that I can grab to put more flesh on to the bones of this goal: ubiquitous jboss!


I hope you are as excited by this as I am. How many other middleware vendors offer you the opportunity to get involved and shape the next generation? Most of them will simply say this is how it's going to be, like it or not. But that's not how we operate!

Every now and then I get asked to explain the differences between our projects and platforms. It's getting less and less these days, as most people now understand it. However, it does come up and it's worth repeating here. I was going to launch into my explanation, which is well rehearsed by now, but then someone reminded me that Rich Sharples did a great job of this last year on his own blog. If you're at all unsure about the differences between our projects and our platforms, then take a look.


However, there is one thing that I want to emphasise about this "split": everything we do in our platform work goes into the "upstream" open source projects. We don't keep anything back from the communities that help to create the projects. As Rich explains, our productisation processes push the project code through a set of very stringent processes, e.g., qualifying against a range of database drives, hardware platforms and operating systems, to which the communities may not have access or the time. Yes, it can take weeks or months for us to iterate through our processes to create the necessary quality, fixing code, applying updates that we, or the community, didn't realise were necessary originally, etc.


But once we're done and we are sure that the resultant product can be released, we make sure that the changes go back into the project source repositories. Of course it may not make sense for us to put them back into the trunk of the project, e.g., the project may have moved on to a new major release. And code changes the productisation engineers make often go back into the code for the community projects as soon as they happen, especially if they are major functionality bugs or security issues. Disenfranchising our open source communities is not something we've ever done, or considered and it's not something that we're going to start now!


Our platforms benefit from our community work. Our communities benefit from the platforms too. So what is the benefit of the support contract that Rich mentioned? Well, as he says, using EAP as an example:


"JBoss EAP is supported for 7 years and with every additional minor or micro release we further improve the performance, security and stability of the Enterprise Platform. We’ve now released 2 micro and one minor release of JBoss EAP – that’s about 150 top-level issues in total. While the issue rate will slow over time – we’ll still be in a position to fix issues and respond to new security threats in 2016.

All those fixes are made available upstream and will ultimately make there way in to upstream binary releases but what the upstream project can’t guarantee is that those fixes will be isolated from more substantial changes and improvements – community releases typically don’t distinguish compatible bug fixes from more intrusive changes that provide the innovation."

So if you're wondering whether or not we're still the home of open source, as I said last year, the answer is yes. We do everything in the open and we keep nothing back from our communities. I'm fairly sure many of our competitors cannot say the same thing!

I've been tracking the TorqueBox team for a long time, even when the "team" was really just Bob McWhirter. I like what the team are doing and have even been pulled in to learning Ruby and contributing the initial transactions support. So it was good to be able to attend some of their team meeting at JBossWorld and hear the plans for the future. It was also interesting to realise that TorqueBox is yet another example of JBoss Everywhere: providing the enterprise capabilities offered by JBoss projects and platforms to a wider audience of users and developers than we've done traditionally. Who knows ... at some point maybe we'll look at other languages than Ruby to do something similar. Until then check out TorqueBox and my congratulations to the team!

Mark Little

Ubiquitous Computing

Posted by Mark Little May 16, 2011

So just what is JBossEverywhere then? If you've seen the video of my keynote then it should be clear. However, I want to go into more details here just for the avoidance of doubt.


What it is not is simply a way for writing thin client applications that access various JBoss components or services that are running elsewhere. It isn't a new framework for writing HTML5, JavaScript, GWT or native web applications. It may utilise these technologies to achieve a goal, but that goal is so much more.


As I said in the presentation, the underlying theme behind JBossEverywhere is ubiquitous computing. Now there is no way I can take credit for that concept: ubiquitous computing has been around for many years; I remember it being discussed by all of the big middleware and hardware vendors at the turn of the century, as the next big wave. Some people may be forgiven for thinking that it simply didn't turn out that way, but they'd be wrong. You only have to look around you to see that it happened (is continuing to happen every day.) We just take it for granted that technology is an implicit part of everything we do today, yet you only have to turn back the clock a decade to see how different it was. And go back 3 decades, as I showed in the talk, and you could be walking into an episode of the Twilight Zone!


But what has this impact of hardware got to do with anything I want to discuss here? Put quite simply, these devices are an area where middleware, and JBoss in particular, can play an important role. Just as the new wave of personal computers were thought of as constrained 30 years ago and often looked on with distain by those in the workstation and mainframe arenas, yet now they power a lot of enterprise computing, so too will go many of the devices we see around us today as being of limited utility.


Your mobile phone already has capabilities that would put to shame PCs of the 1990's. They have also quickly become critical to our day to day lives, moving from supporting basic games to complex B2B applications. These applications need enterprise capabilities, such as messaging and transactions. In fact I've believed this for over a decade, having made Arjuna run on an HP Jornada 720 in 2000, with the intent to take this further had HP decided not to junk Bluestone only months later! A lot of the work I've done in intervening years on extended transactions and end-to-end transactions has also been an offshoot of these thoughts.


But it's not just mobile phones. Due to the economics of scale, it's not far fetched to assume that sooner than you think your washing machine, car or even coffee pot, will have more raw processing power than workstations or laptops of years gone by. Being able to tap into these processors is something that will happen, security considerations not withstanding. In fact as I've said before, this is really where I think cloud will go (return). At the moment cloud, or at least public cloud, is little more than offshoring; useful yes, but not taking things far enough. The true cloud is the processors around us, and being able to use that cloud offers many advantages and opportunities. And once again, middleware will be useful there.


So JBossEverywhere is about defining middleware components and frameworks that can be used on these various devices. We should not expect people to reinvent the wheel, e.g., transactions, when there's a perfectly good wheel already out there. It'll mean developing new projects and pushing the envelope, but that's what we're good at. New frameworks that will combine adaptability, configurability, monitoring etc. to allow them dynamically cope with changing deployment environments so that the application doesn't have to (in many cases.)


I suppose another way of stating the goals of JBosEverywhere is Ubiquitous Middleware, or specifically Ubiquitous JBoss!

Mark Little

JBUGs are important!

Posted by Mark Little May 9, 2011

From the beginning of JBoss, JBUGs (JBoss User Groups) have been very important to us and our communities. They're a great way for the communities to share information and to influence what happens in the projects and platforms. We try hard to help JBUGs promote themselves and develop their own identities, and often we'll work with them to get some of our rockstars to the events they hold. However, over the next few weeks and months we're going to be adding more support to the JBUGs to make them even more compelling and help the JBUG organisers as much as possible. So if you've got a JBUG and it's not on our list, or you just want to be sure that the contact information we have for you is accurate, then get in touch with us as soon as possible. If you've any difficulties going through that route, then you can always contact me directly. My goal is to have a pin on the map in every city around the world and maybe even the arctic/antarctic! With your help we can accomplish this!

Mark Little

JBoss Everywhere

Posted by Mark Little May 8, 2011

I'm just back from JBossWorld and JUDcon. Individually they were each fantastic events, with JUDCon proving to be the premier event for JBoss developers and JBossWorld the place to find out where the products are heading. But this year things were slightly different and I hinted at this a few days before the event: this time we showed everyone where the future lies for middleware in general and JBoss in particular.


I could go into details in this blog entry, but thanks to Max, Pete and others we have an unofficial video of my keynote that drives the message home. (What's that they say about pictures and a thousand words?) There will be an official recording soon and I'll update this blog when that's out. However, in the meantime I recommend that you shut off your email client, turn your phone onto silent, grab a tea or coffee, and take the time to watch not only the best keynote this year, but probably the best keynote ever at JBossWorld (as voted by people who have been with JBoss a lot longer than I!)


When you're finished let us know what you think and come back here to find out more details of what we have planned. The next few months and years are going to be a great time for R&D at JBoss. Get involved: there's a lot to do and it'll be fun!


Finally we will be running a series of articles, asylum podcasts etc. to cover in detail the demonstration that you'll see in the video. So much went into it that we simply could not cover in the time. If you want to know more then we will show you everything! And my thanks to the team, including Kevin, Manik, Mike, Sanne, Jason, Pete, Ales, Emmanuel, Jay, Wesley, Burr, Christian, Mircea, for their work on the demo and making concrete some of the things I've been talking and thinking about for years. We have such a high concentration of the best talent in the industry at JBoss!


So remember: JBoss Everywhere!! (And thanks to Bob for giving a succinct name to what I could only describe in pages of text!)



It's been a frustrating couple of days. I won't go into details, but suffice it to say that between a certain travel bureau and a certain airline, I've been unable to get to Boston for JUDCon as planned until 24 hours later! But I'm on my way now, with my transactions presentation done, an almost final draft of my session on JBoss PaaS completed, some hopes for the expert panel, and lots of meetings planned. But it's my keynote on Tuesday that has my immediate attention as it promises to be different to the usual format: I'll be outlining our vision for the next few years, which goes way beyond (but also includes) the traditional Java EE landscape that JBoss has been associated with successfully for many years, and at the same time illustrating some of these ideas through a highly interactive and visual demonstration that the teams have been working on for several weeks. This demo will be very intense and implicitly as well as explicitly shows the advancements we and our communities have made in a number of areas, not just Cloud. In fact there's so much going on within the demo that I doubt I'll be able to call out all of the projects within the scope of the keynote without overrunning, so what I think I'll do is get the team to write up an article on it specifically after JBossWorld closes. It's very cool and I'm really looking forward to presenting it to the audience on the day!

"Twas the night before Christmas, when all through the house, not a creature was stirring, not even a mouse" OK, let's hold it there because we all know that isn't quite right. As I said last Christmas Eve, the JBossAS team were definitely stirring and as a result released the final version of 6 and at the same time were working on JBossAS 7, which will be (cue The Six Million Dollar Man music) "Better, stronger, faster" than it was before. OK, for those of you under 30 that reference probably means nothing .


However, returning to the main theme of this posting, the JBossAS 7 team have been at it again and just released the first beta of 7. If you haven't tried it out yet then I recommend you do so. JBossAS 7 will be the basis for everything we do in the coming years in the area of Java Enterprise Edition 7 (and subsequently 8), as well as things we'll be doing (are doing) outside of that arena. And if you want to understand more on that last bit then you should come along to JUDCon and JBossWorld!

Hot on the heels of my previous entry praising the JBossAS team, the team go and do it again! This time they've achieved EE6 web profile compliance and have tagged the code! Of course an official release may not appear until the new year, but this is great news. I don't want to spoil the surprise too much, so expect to see a lot more said about this release from the team once it comes out in January! Once again congratulations go to the entire team (core developers, docs, managers, QA etc.), who pulled together to make this a reality. And on Christmas Eve no less! It's almost certain to be a merry Christmas and a very happy new year!!

Mark Little

The JBossAS team rock!

Posted by Mark Little Dec 16, 2010

Over the years we've put in a lot of time and effort to make JBossAS the best application server out there. With JBossAS 5 we refocussed around a new microcontainer architecture that gave us a lot more flexibility in terms of deployments and configuration. Building on AS 5, we saw performance improvements through AS 6 and now into AS 7. For those of us within JBoss and the active developer communities, this progression has been fairly low-key. However, now that we are through the first official community release of AS 7 and more people are starting to kick the tyres on it, the feedback we're getting is very positive and most folks seem quite pleasantly surprised!


Take the latest article for instance, which looks at startup times for various types of Java EE container. If you skip to the bit where the author comments specifically on JBossAS you'll see that between AS5 and AS7 we've seen orders of magnitude improvements in the start-up time. However, this is not due to the use of OSGi (which we do support), but to the work of Jason and the team on improvements to the microcontainer architecture and implementation. If you want more details then be sure to check out the Asylum Podcast that was recorded recently.


Of course start-up times are only part of the equation. You'll hear more of the benefits of the micro-services architecture on the podcast. But the various teams, such as HornetQ, JBossTS, EJ3, JCA and others, have all been looking at how to improve the run-time aspects of the container. We aren't quite ready yet to publish official figures, but I can tell you that by the time EAP 6 comes out, JBossAS 7 will rock! It will be the best platform on which to develop and deploy your enterprise applications, whether they run in the Cloud or run locally. So if you haven't taken a look at it yet, I recommend that you do so and provide us with your feedback. Or write articles extolling the virtues of the new performance improvements that you will find :-)


And I'll take this opportunity to congratulate Jason and his team, along with the other project leads and their teams, for putting in a great effort! We are really seeing the benefits and they'll keep coming over the next few months!

Mark Little

Nearly two years on ...

Posted by Mark Little Dec 12, 2010

It's been nearly two years since Sacha left and "passed the baton" to me. As instructed, I think/hope that I didn't "screw it up", as he requested ;-) It has been a very eventful 18 months or so and I continue to be indebted to Sacha for selecting me as his successor. Over this time we've seen some of our competitors get acquired, the release of Java EE6 (which we pioneered with CDI and Bean Validation), the start of a new JBoss developer conference series, some acquisitions, countless project releases, new standards efforts, adoption of newer languages, and new projects being created, and many new product releases. In short, it has been a very busy year and a half!


My thanks go out to everyone involved in what I have mentioned above. It would take an entire blog entry to mention them all and even then I'd probably miss out some, so I won't even try. Each of our projects and platforms has a thriving and growing community of contributors. Whether those contributors cut code, provide docs, log issues, comments, use cases, or whatever, whether they are Red Hat employees or work for some other company, they (you) are all part of the greater JBoss community and critical to our (your) success. And over this last 18 months I've been in the privileged position to monitor all of these efforts in one way or another, and sometimes help where I can. I've seen the communities grow and the core developers thrive on the challenges that their communities offer. In a word, it has been fun!


I've also watched out competitors increase their FUD against us (queue Richard Burton's voice and the ominous music from Jeff Wayne's War of the Worlds!) Our market share has increased over this period. Our communities have increased over this period. But probably the most telling thing that shows how much of a threat we are to others in the enterprise Java middleware space is the amount of FUD that has also increased in this period. As I said in a separate blog, "I suppose [FUD is] easier to do than actually provide significant technical differentiation"! Yes FUD is annoying, but if you take the time to step back and think about it, it's actually quite flattering that you (we) have gotten to the point where companies large and small have to resort to it in order to try to retain their market share! JBoss and open source is a major player in middleware, whether you are looking at traditional deployments or new arenas such as Cloud.


So in the last 18 months I've definitely had "fun". But I suppose if there's one downside of Sacha (and Marc's) legacy, it's that I have less time to spend on actual coding. Or at least that's what I was worried about when I had to weigh up the pros and cons of taking over. Although it turns out that I don't have as much time for cutting code as I once had, I still manage to do it. (Which reminds me, I hope that my transaction addition to TorqueBox makes it into the trunk eventually ;-)! I think it's important to keep coding, particularly in an environment such as JBoss which is heavily engineering driven. Plus it helps keep my grounded as well as sane :-)


Back in March 2009 when Sacha asked me to take over, I recall thinking that this could be either the best move I could make for JBoss or the worst. It wasn't an easy decision to make. But now, almost two years on from that date I think I made the right choice and have to thank him and the wider JBoss community for a wonderful journey! If the past is any indication of the future then bring it on!!

Over the years both Red Hat and JBoss have a history of making good strategy acquisitions including, but not limited to, the Arjuna Transaction Service, Metamatrix and, of course, JBoss itself. Well I'm pleased to be able to announce that today we've done it again, this time in the Cloud space with the acquisition of Makara! Makara, if you don't already know, have been doing some great work with JBoss technology in the Cloud for a while now and has a great presence at JBossWorld and Summit earlier this year. To put what they do currently in a nutshell it's provisioning of JBossAS into public and private Clouds, with monitoring and management to enable auto-scaling.


Now obviously there's some overlap with projects we've been doing in JBoss and Red Hat, such as SteamCannon and CloudEngine, as well as obvious areas of synergy like DeltaCloud. Plus Makara's technology isn't open source. So that's why the engineering teams across the board have been talking about how best to drive the integration forward and ensure that the considerations of our communities are taken into account. Over the past 10 years I've been "acquired" many times as well as being involved in acquisitions. I've also helped open source a number of previously closed source technologies. To do this right will require time and doing is right is very important for us. So please don't expect to see code appearing immediately, but you will see the Makara team appearing in the forums, IRC and elsewhere to answer any questions that our developers and community may have.


So with that, I'll just say a big welcome to the Makara team! It's going to be a great adventure over the next weeks, months and years.

Rich Sharples gives a pretty good overview of our product lifecycle in response to some FUD from Snorcale. As a slight aside, I love it when certain Closed Source companies preach to us and the communities about open source: the words "grandmother" and "sucking eggs" spring immediately to mind! Anyhow, FUD is something that we've seen rather a lot of in recent times; I suppose it's easier to do than actually provide significant technical differentiation, and it's nice for us to keep disproving it!


As I said, Rich's post is a good overview. But some of the things that are implicit in it need a bit more explicit discussions. For a start, the open source communities are extremely important to us and we try not to do anything that would affect them adversely. Everything that we do during the productisation process in terms of bug fixes, feature improvements etc. goes back into the community releases. We are not a closed source company that periodically dumps our code into a public repository.


The communities, whether they are comprised of people who contribute code, let us know about bugs, or give us use cases and requirements, are critical to the success of our projects and hence our products. Of course we recognise that not everyone will want to purchase a support agreement from us and will be confident enough to self-support. Those individuals and companies are still important to us; they're still a mark of success, both for us and for the community at large! If you listened to some of the FUD you'd think that we walk all over the communities once we get what we want, i.e., the code. Nothing could be further from the truth; just take a look at JUDCon for example. Of course you can't please all of the people all of the time, but to think that an open source company such as Red Hat would do anything to mess with its communities is crazy. I think it shows that companies such as Snorcale are having to resort to the Chewbacca Defence in order to try to confuse everyone and distract them from their own issues around open source.


Another thing that is implicit in Rich's description, is what we like to term "baking in the community": this is where the community (including our employees) works to ensure that each release of a project (and hence a subsequent product) is fit for purpose. Our communities feed requirements into each project release via forums, JIRA, emails etc. The development teams, which may well include community developers as well as our employees, then work on any associated new capabilities, or bug fixes, and turn those into new project releases. The communities then take those releases and kick the tyres, providing feedback on what's good and what's bad, what works and what doesn't. As a result, it may be many months, or several project releases, before the project teams and their communities are happy with a particular feature. This is baking in the community, and only something that's been suitably baked makes it into a product.


All of the above should help to illustrate some of the trade-offs that are inherent in our approach. The communities are always getting the cutting-edge features and capabilities, some of which may well have been added by our developers on behalf of customers, as well as all bug fixes that we may find during productization. The community releases move forward relatively quickly compared to the products, because we spend a lot of time in the productization process, which might include removing some things from the project releases that aren't quite ready yet, e.g., they haven't had enough bake-time. Those who purchase support for our products (platforms) get a slower moving beast, that offers guaranteed stability over a much longer period of time; it may be months or years before they gain access to the feature set that's available in a project.


So in conclusion, we believe the model we use is able to walk that line between project needs and platform needs. It's something that we have been working on for a few years, but which we do evaluate based on feedback from all of our community members, including product customers. It has allowed us to grow our offerings substantially over the past 4 years and retain our leadership position. So let's see how the next 4 years plays out.

Filter Blog

By date:
By tag: