[heiko.braun]

But I think, thats not for us to discuss, it would be a JBoss management task.

No, it's definitely not a management thing. JBoss projects are still OSS run by the project leads. It's something the project leads need to discuss and decide. There will not be a top-to-bottom decision on this. Actually it can't if you think about the way projects are organized within jboss.

Avoiding the discussion, or doing it non-public doesn't help either. So I am glad you guys share your concerns. IMO a public statement like drools did is a good step into the right direction: http://www.jboss.org/drools/drools-flow.html

But on the other hand, if I compare it to the web service project, there has always been open source competition. In our case it was Metro and CXF. Still this didn't question our approach to provide JBossWS in the first place. But in the long run, community and users did decide for another stack. In this case CXF. But we did make all three of them available on jboss. IMO we'll see something similar with drools and jbpm.

[tom.baeyens]

i think's unwise for jboss to invest in 2 engines and then select the best one in this particular case.

exploring 2 technological strategies/solutions and see what works would be justifyable. but that is imo completely different from the situation we're discussing.

in this case, there is no feature that they target that cannot be build on jbpm. from the beginning i have tried to collaborate by pointing out how all the features they requested could have been build on on jbpm. apart from taste, i have not been able to see a real reason why they had to do it different.

in their logic, they think that they are doing things differently (mostly joint process/rule execution, and nicer integrated in drools codebase/api). and therefor must build their own version of the pvm.

[tom.baeyens]

Being open source, we are able to explore a number of options for particular technologies. The advantage is that the community can help in vetting these options, something they would never get to do in a closed source scenario.

[kukeltje]

The webservices frameworks is a good example where multiple projects from different 'parties' competed (and cooperated) and not all 'survived' (Not sure if 'Darwin' applies here). That is FOSS and if done in a good spirit leads to better results (see the cooperation of the portals that was recently announced). Heck, that is why I joined.

And I agree with Tom that this is not the situation we are discussing here. Sure, everybody has it's preferences like me not wanting to invest to much time in DB stuff or GWT, Heiko disliking seam etc... so choices will be made that not everybody is 100% happy with. No problem, as long as there is a common goal and that definitely seems missing.

Two projects within a company, no matter how they are run without a common goal (like exploring new ways) is not good imo, no matter how they are run by the project leads. Both have a limited budget I'm sure (otherwise the next communityday would for sure be down under ;-)

So I do think it is a management thing, for sure...

[kukeltje]

Oh, that 'definately seems missing' was not about jBPM internally but jBPM vs Drools Flow

[camunda]

Yesterday I had another customer on the phone, who was pretty confused about jbpm and DroolsFlow and told me, it makes a pretty unprofessionel expression to him, that there are two engines which don't have a DIFFERENT purpose in the same JBoss SOA environment. And especially if there is not guideline where the difference is and when to use what.

The support itself seems not to know either, the only answer was jbpm 3 is currently the only supported platform...

Hey, this is not professionel open source, it is like a bunch of uncoordinated open source projects...