jBPM 4 is dead?

[markroy]

Is jBPM 4 dead? It certainly seems so.

Evidence:

• Top two developers have left the project.
  
• No significant source code changes in over 60 days.
  
• No statement from RedHat management about jBPM 4, despite several requests from users here.
  
• jBPM 5 roadmap is being discussed (among developers), which is a significantly different from jBPM 4, without any mention of closure or support for jBPM 4.
  
• You can no longer purchase support for jBPM by itself, only as part of the JBoss SOA plaftform. The recent release of SOA 5.0 includes jBPM 3, not jBPM 4.
  
• Even Ronald van Kuijk has been absent
  

Without a significant outcry from the community, I suspect RedHat is going to forget that jBPM 4 ever existed. Which means people like me that have started with jBPM 4 (I have no jBPM 3 version code to fall back to) will be left high and dry. Waiting for the jBPM 5 release (tho no date is given, the scope of the changes suggest it's many months away) isn't practical.

[rebody]

Hi  Mark,

  We have talked about the future of jBPM4 and Alejandro promise that jBPM4 will still go on developing. I think we should wait for a few moments. I believe that there will be a solution to keep maintaining jBPM4 before jBPM5 released.

[aguizar]

Mark, let's not spread panic. In the first place there will be another jBPM 4 release soon (version 4.4) to publish the issues fixed after jBPM 4.3 was released. The decision to stop selling support for frameworks and focus on the platform was driven purely by demand. As for jBPM 5, please understand this was a necessary, long overdue move. It was no longer meaningful to develop two similar projects (jBPM, Drools Flow) separately. Such a move unavoidable affects both jBPM 4 and Drools Flow users alike. However, in the long run, we believe the new strategy is in the best interest of both projects.

[markroy]

Personally, I am panicking. I've been promoting jBPM to my customer as the best thing out there. They were reluctant to go with an open source solution, but I assured them that RedHat support was available. (I asked for a quote for support specifically for jBPM 4.x, was told I need SOA-P. I got a quote for SOA-P, but only just realized it does not include jBPM4). Now I have to go back to my customer and tell them support will not be available. And moreover, there will be major changes moving to a future release.

I understand the need/desire to merge jBPM and Drools Flow in a future version. I don't have an issue with that. What I am concerned about is the lack of a statement of commitment by RedHat *management* (no offense Alejandro) to complete the planned features for jBPM 4, create a production quality release and provide support until a production-ready jBPM5 is available.

[sebastian.s]

Hi Mark!

I can understand how you feel about this. The really long missing statements from Red Hat / JBoss really left the community with doubt and insecurity.

From what I can say: discussion on the future of jBPM just started on the mailing list. I am getting the idea that Drools and jBPM should be joined in one project to offer a more complete solution - but how this is going has not been decided yet. Sometimes I am getting the impression it has been - in this case the discussion on the developer's mailing list would be useless. For me there is still the chance that jBPM 5 will be based-up on parts of jBPM 4. It offers the PVM to also support Drools Flow and after all Drools in first place is still a java rule engine based up-on the rete algorithm IMHO. jBPM 4 is not bad - not just yet finished. I think there is already a kind of consensus that users should be enabled to just use the rules engine and the process engine of jBPM 5 without having to deal with both of them.

For my part I hope that the discussion taking place on the developers' mailing list is one with an outcome which has not been decided.  I would like to invite you to join the discussion on the mailing list, Mark. I would especially be interested in your current use case.

Cheers!

Sebastian

[gelos]

just to add my 2c to the topic

changing focus to version 5 when version 4 is broken in major ways in very concerning

our team's chosen to use version 4 over 3 (which we regret) and right now we are stuck and struggling

we got version 4.0 to work but had to patch basic things such as transaction management in offline processing, timers not supporting absolute dates and only durations, etc.

tried to upgrade to 4.3 and discovered that it introduces yet more bugs that are even more impacting and touch basic flow functionality. we understand that it's software and it's a normal cycle of stabilizing new code, but not having version 4 roadmap clearly stated and committed to and starting to talk about version 5 is premature and disruptive to many

gelos

[dr_pompeii]

Hello Alejandro

Well just few months ago I start this pretty cool journeying about learn jBPM, is very interesting and important, I have read the book

jBPM Developer Guide, furthermore I am Technical Review in Apress for the two last book about Spring Enterprise/Web Recipes, and we have an interesting chapter about jBPM/Spring, therefore I am really interesting in go deeper to work with jBPM

In the first place there will be another jBPM 4 release soon (version 4.4) to publish the issues fixed after jBPM 4.3

I am confuse, I wrote this post About differences between jPDL editors jBPM  3.2.6 and 4.3, since the book written by Salaboy, use the old jBPM version and in some reply in my post said

The GPD for jBPM4 has not finished yet.

Therefore with 4.4 the GPD would be finished?

with 4.4 and 5 future release, spring support would be still available?

Saludos desde Perú

-Manuel

[sebastian.s]

Hola Manuel!

The graphical process designer is a subproject and do not expect it to be finished in 4.4. We are currently discussing the future of jBPM and dependency injection using a Framework like Spring is a topic. You're welcome to join the discussion on the mailing list. At the moment there is the idea to even aim for support for a couple of dependency frameworks (Spring, Guice, ..).

Cheers

Sebastian

[dr_pompeii]

Hello Sebastian

Thanks for the reply

The graphical process designer is a subproject and do not expect it to be finished in 4.4

OK, but please resolve my doubt, since GPD has not all features yet like previous release, In a good sense

Must I configure by hand in source tab pane my jpdl requeriments that I can't do by properties window approach?

You're welcome to join the discussion on the mailing list

Sounds great, can you provide me the link to join me?, mostly what kind of discussion cover such list?

At the moment there is the idea to even aim for support for a couple of dependency frameworks (Spring

I think that is wise have integration with Spring, both frameworks are powerful

Best Regards!

-Manuel

[eschabell]

Mark,

Red Hat has always been clear on jBPM 4, it is and never has reach any state that was ever considered for inclusion in her products. I have mentioned this before to more than one member of the community here.

The JBoss SOA-P product has always been the entry point for a supported release of jBPM. True, it used to be possible to have framework support on only jBPM, but it was always for the versions included in the JBoss SOA-P product. These are the ones that made it through Red Hat's QA, testing and integration process. Finally, it was decided to only provide support for jBPM through a JBoss SOA-P subscription.

Any member of Red Hat asked with regards to sales support of jBPM 4 should have always told you that support is possible for jBPM v3.2.x (depending on time frame, but this is the only supported branch for some time now), and for 5 years for each release.

It seems to me that it is up to the community to take a project in any direction it so desires. This is no different for jBPM.

[rebody]

Hi Eric,

  Do you mean that Red Hat won't go on maintaining jBPM 4?  There were already many customers using jBPM 4 around us.  Could we find a way to keep maintaining?  At least fix bugs.

[eschabell]

Hi HX,

I mean only that at jboss.org you have Projects which can eventually lead to Products. The idea is that Red Hat picks and chooses the Project elements it feels it can offer support on within the Product(s) it will offer.

jBPM version X is always here on .org an unsupported Project offering.

The jBPM Community Project members can work on jBPM 4 (I assume you all will, as there has been lot's of interest posted here lately so why stop working on it). The code base is GPL, it is freely available and I am assuming anyone with a bit of competence and interest will be given the chance to commit to the project.

It is all open source here at jboss.org, life always will and can go on....

[rebody]

Hi Eric,

  Thank you very much for your reply.  It's very meaningful to me.  I don't want to see jBPM 4 dead at this moment, at least before the jBPM 5 releases.

[markroy]

Red Hat has always been clear on jBPM 4

Can you please point to a reference for this statement? I haven't seen anything anywhere that suggests that jBPM 4 was not a planned product progression from jBPM 3.

Perhaps I'm naive, but I assumed that jBPM 4 would become a supported product once the community beta-tested it and that it had reached a level of production readiness. Is this not the way JBoss projects evolve? If not, why would the community invest any time in projects that RedHat is not serious about? Will jBPM 5 be a "real product", or will you say "just kidding" after a community forms around it?

[gelos]

just to support your way of thinking - my company made the exact same conclusion and we also suggested to our client to go with the version 4, since there was enough time for it to solidify and mature

now we are hunkering down with 4.0, patching it ourselves where we absolutely must and trying to figure out what the heck to do next

gelos