Just to support O S and Mark, since we are in the same boat. Instead of talking about jBPM5, JBoss should clarify its position on jBPM4 (roadmap or declare it dead). Can't see how Jboss expects to form a community around jBPM5, when this jBPM4 situation leaves a bitter taste for its users. Kind of remind me of fool me once proverb.
Exactly, you have people investing time and money integrating and deploying jBPM 4 in their production environments, and its not fair not to explain - without any kind of ambiguity - what is going to happen with the jBPM4, knowing that the new jBPM5 will we completely different to the actual API.Things like that you don't expect to happen in organizations like Red Hat.Please be clear and direct as soon as possible in order to allow us take the best and painless decision, maybe we have to come back to the 3.x branch or find other alternatives.
I don't understand why you would have used jBPM 4 for production projects without realizing there is no Enterprise support for it. You get what you see, an open source project with no assurances of anything going forward. In this way of working you are dependent on the community for all future direction, communication and support.
Jboss.org is a hosting location, but the Products that come from here are the ones you want to look at for Enterprise support in your production environments. Go over to jboss.com for these. There you have assurances that the Product versions will be supported for 7 years going forward. If you use the last released versions of jBPM (v3.2.x) in the JBoss SOA-P Product you will be sure up to 2017. Sorry for the short sales-ish stuff, but it is just to clarify the point.
All that being said, jBPM5 planning is to get it into some shape that can be moved into a Product and appear on jboss.com in a product form, including Enterprise support.
I am about to post my reaction to the request for comments. I have a long history with jBPM v3 as an enterprise developer before joining Red Hat, watch for it.
I personally think that a lot of jBPM 4 will be leveraged moving towards the future, but in what form is the question as it needs to be completed in many areas (as you have all stated repeatedly). So get out there and reply to the request for comments and let them know what you like and want from the existing jBPM 4 if that is what you need. This is the fastest way to help Kris get a roadmap out for jBPM5.
Even better, offer to help to create jBPM5. It is community developers that should make their voices heard here anyway!
"I don't understand why you would have used jBPM 4 for production projects without realizing there is no Enterprise support for it."
Speaking for me - we were trying to be proactive. Plans were made in June/July of 2009. jBPM v3 had an excellent track record. v4 was about to be released. It was possible to see how version 3 was progressing and make intelligent assumptions about version 4.
I still think it was a reasonable decision that used knowledge about jBoss as an organization and jBPM as a project and made intelligent projections.
What we are discovering now is that past preformance is no guarantee for future results
I think your answer is not very kind with the community people, a community that adopts your products from the very beginning, using them in real production environments and helping JBoss turn them into high quality products.This relationship is based on trust and commitment, and today you are throwing us a bucket of cold water, setting the basis of a new relationship where these values are not present.You are discouraging us to use your community components.
There is no need to panic.
First of all, if any of you has decided to adopt the community components (as opposed to the supported versions) they did that with the knowledge that there was a chance that the piece of software they downloaded would never be officially supported. That is stated clearly on the community download pages. Now luckily jBPM 4 is an open source project. The sources are available and you can adapt/tweak/change/fix any piece of code that is in the codebase yourself. It should not be that difficult to do and as you probably know, our forums are very alive and you'll likely get plenty of help if that would be needed.
Secondly, as the community is not something that is owned by Red Hat or JBoss but rather constituted by all you guys participating in discussions, opening JIRA issues and providing patches, there is no reason why jBPM 4 would need to die. It is true that the efforts of the Red Hat/JBoss employees will mostly be concentrated on further supporting jBPM 3.x and on starting the effort for jBPM 5. However, the efforts related to jBPM 4 will not be dropped and there will be more jBPM 4 releases. In addition this evolution does not in any way prohibit fixes for jBPM 4 to be contributed by other community members. A number of community members have already expressed interest in doing this, so there is a good chance that this will happen. An important task for these volunteers will probably be to provide a migration path from jBPM 4 to the future jBPM 5.
Lastly, jBPM 5 will be an effort that reaps the fruit of jBPM 4 and Droolsflow and that will implement the BPMN2 standard. It is highly likely that the final solution will be very similar to both of those projects (they are already not that far apart right now) and that the transition from jBPM 4 to jBPM 5 will be very smooth. Of course, as I said before, the more input and collaboration we get for these features, the more likely it will be that they will be implemented.
I hope this removes at least some of the concerns.
P.S. While writing my anwer here, Alejandro made me aware of Mark Little's blog entry that provides an even much better anwer to what I'm trying to say ;-)
I think that we shall try to a bit more positive about the whole situation. Of course latest news from Red Hat/JBoss about not getting jBPM 4.x into product list is a bit disappointing but the most important, at least in my opinion is that we know it now. It is always better to have news (even bad) compared to silence.
At this point we know what are the nearest plans for jBPM as a whole. Moreover finally there is some moves towards merging jBPM and Drools Flow. It was a bit dangerous from my point of view, competition between these two could not be too good for end users.
Let's try to get most of jBPM 4.x and focus on next releases. As we could see there is going to be involvement from core developers, most likely limited but that gives us as community a bit more to share. Many of you has stated that improvements, bug fixes, etc have been done by you so why not sharing your work with other community users and obviously JBoss.org to have a better project that could be reused while working on version 5. I guess Alejandro and the rest of core development team will be more than happy to get patches for already discovered issues.
As Koen and Alejandro has already mentioned, let's try to do not panic about it, jBPM will survive and that's the key to stay with it. Kepp an eye or two on migration issues for jBPM 5 to make our life and work easier in coming years and I am certain everything will be all right. In other words let's look at the bright side of life
I hope that you will agree with me and next releases of jBPM 4.x will be out joined effort.
Its disappointing,we started with JBPM3 and waited for stable JBPM4,since there was major change with architecture from 3 to 4.
When we look into 4 again, there is announcement that 4 will become 5.
I'm a end user who researches on open source projects for enterprise use,
Its fine to take it a on a positive note but it would be helpful if more information is provided on the roadmap of upgradation from 4 to 5.
Will there be major change from 4 to 5?
Do all the community users has to stay way from JBPM4 for a while?
of-course its open source and we can work with code base of 4 ;-), wont it become a dual channel on the same objective?
We are expecting a WIN-WIN strategy,atleast a definitive answer on the migration plans for all those who have put their efforts in 3,4 so far.
Up to this post.
I have to evaluate JBPM for an enterprise project, and it would be useful to know if in this moment it's better to invest on JBPM 4 or wait for the 5 (https://community.jboss.org/wiki/jBPM5Roadmap).
Thanks in advance to all.