Whether you call it workflow, task flow, process flow, process management, BPM, or something else entirely, workflow systems have been extremely important to enterprise systems over the past decade or so. With the advent of SOA and larger scale deployments, the combination of SOA and workflow (typically BPM, given the business drivers behind SOA) became inevitable and sensible. These days it doesn't matter where you look: if there's a SOA platform around then there'll be some way of orchestrating the services involved and the way in which they are invoked.

Looking at this from a very JBoss specific perspective, we decided at the outset of the JBossESB project that some form of process flow technology was critical to the adoption of SOA, and the obvious candidate for us was jBPM. The maturity of the project, the enthusiasm of the community and the engineers, in particular Tom Baeyens, the project lead. From there jBPM 3 made its way into our SOA Platform and the rest, as they say, is history. Over the past couple of years we've revised the SOA Platform a few times, with the latest 5.0 release only a month or so ago, building on the integration with our various projects including jBPM, JBossESB and Drools.

Over that time the feedback, both from customers and community users, has been overwhelmingly positive. The integration of SOA with BPM was pretty much spot on, giving those users who didn't want to worry about Web Services or BPEL an alternative. Plus over that time the Drools team have been pushing the boundaries between traditional rules engines and process flow in their community, with equally positive results. With the work we started elsewhere around Process Governance and another foray into the WS-BPEL space with Riftsaw, the impact of workflow-based technologies on everything we were doing within JBoss was reaching a critical mass and a more global, less project specific rethink, was in order.

Probably one of the first public announcements to emerge from our rethink was the initial release of jBPM 4. The jBPM team had taken on board much of the feedback they'd obtained from the jBPM community as well as the JBossESB and SOA-P communities. Tom's vision of the PVM had been building for several years (before integration of jBPM 3 with JBossESB) and finally saw daylight with jBPM 4. Many of the improvements we see in jBPM 4 versus jBPM 3 are a direct result of the feedback I mentioned and baking them in the community is critical to ensure that the team have them right. After all, that is the open source way. Whether or not a version of jBPM 4 was ever officially supported in a product by Red Hat is immaterial to that aspect: we need to ensure that something as radically different in architecture and implementation from the previous major revision is right for the community and our platforms, and the best way of doing that is putting code out there for people to use and on which to give feedback. And that feedback has been great. Thank you to all who have contributed and continue to do so.

But of course things don't always run according to plan and 6 years after joining, Tom decided to leave for pastures new. That left us with a new jBPM lead, Alejandro, who has been a skilled engineer working on the project for many years. It also coincided with the release of SOA-P 5.0 and a need to continue the workflow rethink that had been going on for quite a while. Naturally the departure of any project lead may cause worries in the community and with customers, but where jBPM is concerned they are unfounded: jBPM has been core to all of our BPM and SOA efforts for years and that will remain the case, whoever is the project lead.

Now of course the issue of technical direction comes up whenever any significant engineering talent moves away from a company. However, we continue to have workflow-related rockstars in our engineering teams and communities, and as an open source company we never close our doors to anyone who leaves if they want to continue to contribute to any of our projects. In the meantime, work on unifying the core workflow capabilities we have around jBPM goes on and I have the utmost confidence that our customers and communities will benefit from this effort. As always, we're soliciting feedback from anyone on what they want to see, what they don't want to see, where things can be improved etc. There's a great deal of work in jBPM 4 and DroolsFlow that will feed into this story and what comes out from the project and into the community over the next few months will be iterated over many times as we move from alpha releases through to the final community version.

However, it seems that there remain concerns around jBPM 4. Will it be productized? Will it be supported (really the same as the first question)? Will we put any engineering effort into it? It is fair to say that there was expectation that jBPM 4 would appear in a version of the SOA Platform as a replacement for jBPM 3. With the changes to the jBPM project team and the next steps in unifying our efforts in this area across projects, it is not going to happen. But that does not mean we are dropping engineering effort around jBPM 4: far from it! While we work on plans for jBPM 5 we need to continue to work on community features in jBPM 4 that will eventually make their way into jBPM 5, so you will see more jBPM 4 releases! Once again, this is one of the key benefits for choosing open source, where we (JBoss and community) get immediate access to feedback, both positive and negative. We're working together on this and that means the technical direction can be influenced by community, even if some in the community cannot contribute code directly. Send your feedback in and continue to download releases of jBPM 4 as they will be the testbed for many of the features that will be in jBPM 5.

But what if you've been relying on jBPM 4 becoming productized? Unfortunately plans change and whilst jBPM 4 may not see productization under that name, a lot of it will under the banner of jBPM 5. Fortunately a smoother transition between previous versions of jBPM and jBPM 5 will be a key consideration for the next supported release. We think we know what is needed in that regard, but once again it's important that we hear from the community. What do you want to see to help migrate yourself from jBPM 3, say, to jBPM 5?

In summary, jBPM is alive and kicking, as well as going from strength to strength. Some of the people involved in the effort may have changed, but the criticality of it to JBoss remains the same. We will continue to invest in this area and although the next supported release may have a slightly different version number to what was expected originally, the end goal remains the same: the best open source embedded Java workflow/BPM solution in the industry. If you're in the jBPM community or considering joining then now is the right time to get involved (again). Give the team your feedback and support, so that they can deliver on what we all want and need! And as a friend of mine would say if he were still in my position: Onward!