感受jBPM的动荡，想为jBPM4创建一个社区版的分支
jBPM4的发展遇到了瓶颈，官方已经有一个多月没有更新代码了，前段时间又传出了jBPM的主要成员tom和jorom离开red hat的消息，虽然jboss方面已经指定了alexjando作为新的project leader，但是这个家伙一个月来只更新了一次svn，而且还只是改改配置文件。
上周五，jboss突然发布了一个jbpm5的架构讨论帖，在jBPM4尚有好多好多bug没有搞定的情况下开始筹划jbpm5的新功能了。
https://community.jboss.org/wiki/jBPM5RequestforComments
虽然wiki上面架构图画的很完全，但是从功能来看，基本已经找不到jbpm的影子了，去jbpm-dev开发者邮件列表上看了一下，jboss官方的意思似乎是要用drools flow将jbpm取而代之。
看来前段时间传闻的jbpm和drools的争端已经有了结果，jbpm下一步就算不合并到drools中，也是要被鸠占鹊巢了。下一次发布的jbpm5就是打着jbpm招牌的drools flow了。毕竟drools flow已经完成了bpmn2（据说，咱们没亲眼见过，毕竟drools flow在国内没什么人用）。
下一步怎么办呢？目前已经有不少公司都在是用jbpm4了，使用jbpm3的人就更多，难道我们还要再等几个月甚至一年以上的时间，等drools flow把jbpm完全替代了之后再用工作流吗？还是说我们现在就必须迁移到drools flow上才行。
我的想法是将jbpm4的trunk代码拿出来，放到google code上做一个社区版分支，继续进行维护，这样至少可以保证目前已经使用了jbpm4的项目不会丧失持续的支持（当然对我们自己有好处啦，我们目前做的东西都是基于jbpm4，jbpm4如果死掉了我们岂不是要从头开始？）。
从开源协议上来说是没有问题的，LGPL要求如果修改了原代码，就要开放出来，只要社区版的jbpm4依然使用LGPL开源就可以了。问题是，red hat是否允许我们使用jbpm这个名字，或者说，我们是否可以在修补了bug之后，发布jbpm-4.3.1版，red hat目前拥有jbpm的版权，它是否会禁止其他地方使用jbpm的发布名称呢？也许我们必须改成其他名字，就像mysql被收购以后，作者立刻去搞了一个maria一样？We know there are some issues that need to be dealt with (where some of
them have even been solved in the latest snapshot code already), and
we're also looking into that. Community involvement here is definitely
welcome, so please drop me a message if you want to help out."
> In the jBPM 5 archetecture figure, there is just a 'Core Process
> Engine' but no more details for the PVM and jPDL. Will we drop the
> support of jPDL and turn to the BPMN and drools?
We have been participating in the creation of the BPMN2 specification,
and we believe it is a big step forward. Therefore, we want to target
our future development to BPMN2. Having a standardized language instead
of a proprietary one is almost always a good thing (quality,
interoperability, etc.). And because BPMN2 also allows you to easily
extend the language if necessary, it still gives us the flexibility we
need as well.
So yes, we are looking at moving towards BPMN2 as the main process
execution language and moving away from proprietary languages as jPDL
and RuleFlow. Especially since we believe that BPMN2 will be able to
support the same (process language) features as jPDL, but we welcome
feedback on this. Not sure why you are saying "BPMN and drools" though?
Drools Flow is in exactly the same situation, as that also had a
proprietary language, but will also move to BPMN2.
> Because I just find 'jBPM (3.x) convert plan' here. So I think whether
> we could make a more clearly details for the PVM and jPDL4?
The reason is that jBPM 3.x is currently the officially supported
version. As part of this service, we will provide a migration path from
jBPM 3.x to jBPM5. This however does not there will be no migration
path for jBPM4. We hope and believe that, with some help from the
community, we can extend that to also support jBPM 4.x to jBPM5 migration.
Kris
从好的方面讲，jBPM5会继续开发，并提供BPMN2标准的流程支持，坏消息是对jBPM4的未来都是含糊其辞We know there are some issues that need to be dealt with (where some of
them have even been solved in the latest snapshot code already), and
we're also looking into that. Community involvement here is definitely
welcome, so please drop me a message if you want to help out."
> In the jBPM 5 archetecture figure, there is just a 'Core Process
> Engine' but no more details for the PVM and jPDL. Will we drop the
> support of jPDL and turn to the BPMN and drools?
We have been participating in the creation of the BPMN2 specification,
and we believe it is a big step forward. Therefore, we want to target
our future development to BPMN2. Having a standardized language instead
of a proprietary one is almost always a good thing (quality,
interoperability, etc.). And because BPMN2 also allows you to easily
extend the language if necessary, it still gives us the flexibility we
need as well.
So yes, we are looking at moving towards BPMN2 as the main process
execution language and moving away from proprietary languages as jPDL
and RuleFlow. Especially since we believe that BPMN2 will be able to
support the same (process language) features as jPDL, but we welcome
feedback on this. Not sure why you are saying "BPMN and drools" though?
Drools Flow is in exactly the same situation, as that also had a
proprietary language, but will also move to BPMN2.
> Because I just find 'jBPM (3.x) convert plan' here. So I think whether
> we could make a more clearly details for the PVM and jPDL4?
The reason is that jBPM 3.x is currently the officially supported
version. As part of this service, we will provide a migration path from
jBPM 3.x to jBPM5. This however does not there will be no migration
path for jBPM4. We hope and believe that, with some help from the
community, we can extend that to also support jBPM 4.x to jBPM5 migration.
Kris
从好的方面讲，jBPM5会继续开发，并提供BPMN2标准的流程支持，坏消息是对jBPM4的未来都是含糊其辞
我也刚接触,如果能接受v4对v3的变化,基本也能接受v5对v4的改造了,因为变化实在太大了
We know there are some issues that need to be dealt with (where some of
them have even been solved in the latest snapshot code already), and
we're also looking into that. Community involvement here is definitely
welcome, so please drop me a message if you want to help out."
> In the jBPM 5 archetecture figure, there is just a 'Core Process
> Engine' but no more details for the PVM and jPDL. Will we drop the
> support of jPDL and turn to the BPMN and drools?
We have been participating in the creation of the BPMN2 specification,
and we believe it is a big step forward. Therefore, we want to target
our future development to BPMN2. Having a standardized language instead
of a proprietary one is almost always a good thing (quality,
interoperability, etc.). And because BPMN2 also allows you to easily
extend the language if necessary, it still gives us the flexibility we
need as well.
So yes, we are looking at moving towards BPMN2 as the main process
execution language and moving away from proprietary languages as jPDL
and RuleFlow. Especially since we believe that BPMN2 will be able to
support the same (process language) features as jPDL, but we welcome
feedback on this. Not sure why you are saying "BPMN and drools" though?
Drools Flow is in exactly the same situation, as that also had a
proprietary language, but will also move to BPMN2.
> Because I just find 'jBPM (3.x) convert plan' here. So I think whether
> we could make a more clearly details for the PVM and jPDL4?
The reason is that jBPM 3.x is currently the officially supported
version. As part of this service, we will provide a migration path from
jBPM 3.x to jBPM5. This however does not there will be no migration
path for jBPM4. We hope and believe that, with some help from the
community, we can extend that to also support jBPM 4.x to jBPM5 migration.
Kris
从好的方面讲，jBPM5会继续开发，并提供BPMN2标准的流程支持，坏消息是对jBPM4的未来都是含糊其辞
我也刚接触,如果能接受v4对v3的变化,基本也能接受v5对v4的改造了,因为变化实在太大了
那不是这样子的，V3的确设计比较糟糕，不能满足实际需求而摒弃掉是明智的。但是V4已基本能够满足项目需求了，投入了大量精力去消化这个东西并且在此基础上形成一些成果，如果摒弃掉就相当于之前做的工作很多都白费了，最重要是对JBPM没信心了，因为即使我们跟上了JBPM5，很可能在应用过程中又推出个JBPM6，那么就变成纯粹为技术而技术，无法应用到实际项目当中也就没什么价值可言了。 26 楼 taocong810 2010-04-23 支持楼主。
现在国内有很多用jpbm的公司，就稳定性和可扩展性来说，jpbm4应该是该领域的No.1。
我的建议倒是，楼主可以基于jpbm4.3， 做一个jpbm-side这样的分支，特点为：
1.修复jpbm4.3的bugfix
2.扩展一些功能，使得更加符合中国的国情
楼主加油 加油 27 楼 ianatxm 2010-04-28 见楼主贴出的回信。
jBPM5会取代jBPM4和Drools Flow，毕竟jBPM是jboss官方项目，名气在外。但是jBPM5肯定又是一个全新的框架，就是说刚上到jBPM4.3的同学们还要继续努力。
最可怜的就是外围厂商，因为这意味着以前的产品又要重新开发，大家又回到同一起点线了。
既然版权所有者不同意单独发展一个分支版本，所以社区版在授权上讲，就不成立了。 28 楼 comsci 2010-05-03 这个消息真的让人感到沮丧，这说明一个问题，核心技术和代码一定要掌握在自己的手中。。。依靠别人来生存，始终不是一件让人放心的事情。。。。
这个事件再次给国内的软件企业敲响一次警钟，要想真正生存和发展，自己的企业必须拥有自己的核心技术和产品。。。。。。
外国人是靠不住的，别人是靠不住的。。。。。
29 楼 comsci 2010-05-03 临远，我完全支持你们团队在国内搞一个项目，名叫JBPM中国化，把JBPM这个项目在国内搞下去，你们团队能够好好利用这个机会。。。 30 楼 xyz20003 2010-05-03 多谢神父支持，如果真要在国内搞开源项目，就不能叫jBPM了。而且LGPL对代码的约束太强，不如Apache 2好操作。
最近我尽量多的在jBPM官方论坛游荡，看是否可以寻找到其他机会。同时也在比较jPDL，BPMN和BPEL这些规范，为下一步做准备。 31 楼 almar17 2010-05-05 我也支持楼主，如果可以，我也希望能出一分力 32 楼 lyf_wx 2010-05-06 支持楼主！ 33 楼 Dawn.yang 2011-03-04 这个贴应该继续顶下去，不知道临远大哥最近对jbpm4.4有没有进一步的研究和改进？ 34 楼 Dawn.yang 2011-03-04 http://www.iteye.com/problems/60300
大家看看这个问题
