摘要：本文分析了Camunda公司停止开发开源版BPM引擎Camunda7CE后，开发者面临的三种选择。重点探讨了采用分叉版本的合理性，指出分叉既能保留团队专业能力，又能确保项目稳定运行。文章阐述了分叉的概念、动机和挑战，针对Camunda7，作者团队提出多项优化改进，包括消除漏洞、提升兼容性等，并强调分叉不仅能降低风险，更能促进技术演进。目前该分叉项目已获得社区支持，并通过官方认证，将在2025年投入工业应用。
本文探讨了一种由一家大型外国供应商------camunda所引发的复杂局面。该公司宣布对其产品和许可政策作出调整，导致开源版BPM引擎Camunda 7 CE完全停止开发。
问题
camunda该平台软件的最新版本将于2025年10月发布，此后将停止提供免费更新，补丁只能通过商业订阅获取。因此，全球开发者需做出决定：要么继续使用该软件，同时充分考虑信息安全风险及与现有环境的兼容性；要么放弃使用该技术并重写项目，要么将您的项目迁移到兼容的分叉版本。我们认为后一种方案最为合理，因为它既能保留开发团队的专业能力，又能确保已实现的项目在相同负载下依然正常运行。我们将在本文中详细阐述这种做法的优缺点。首先从概念框架入手。
什么是分叉
"分叉"是指基于先前存在的项目的源代码版本而创建的竞争性项目。所有开源软件项目都可能被"分叉"，这种可能性是根本性的，也是"开源软件"这一概念的基础：
自由分发您修改后的版本给他人。通过这样做，您让整个社区都能受益于您的修改。获取源代码是必要条件。
与此同时，分叉的一个显著特征是"意图"，即作者有意以该分叉替代原始项目，从而与之形成竞争。单纯地创建或发布项目的代码变体通常不会导致分叉。事实上，在自由软件（FLOSS) 开发过程中，推出各种变体进行试验被视为一种常态。许多FLOSS项目（例如Linux内核开发项目）会刻意开展"筛选测试"（也称为"竞赛"），在这些测试中，不同的开发者会实现各种相互竞争的方案；随后对结果进行比较，并由项目采纳表现最佳的方案（即"获胜者"）。 这些"筛选测试"常常以进化论的术语来讨论，例如，"胜出的突变"会被采纳到项目中，而其他替代方案则被斥为"进化死胡同"。由于各方都力求让"最佳"方案被项目采纳，而摒弃所有其他方案，这并非分叉。
大多数创建分叉的尝试都会被社区忽略，因为开发者必须有非常充分的理由，才会考虑转向竞争性软件产品。在开源软件领域，开发者通常不愿支持分叉：人们普遍认为，分叉会分散本可用于整合的精力，增加维护和后续开发的难度，迫使开发者将注意力放在项目管理上，而非专注于改进产品本身。因此，分叉的创建者不得不阐明，为何其他开发者应当支持他们的分叉；常见的原因包括：认为改动推进得太慢，或者相反，认为改动推进得过快；项目管理对外界过于封闭；许可制度阻碍了开发工作；或者基础项目的技术发展方向从根本上存在错误且已陷入僵局。
分叉被视为一种坏事------不仅因为它们意味着未来将付出大量无谓的努力，还因为分叉通常伴随着继承群体之间就合法性、传承性和发展方向等问题展开激烈争执与相互攻击。在自由软件中，分叉往往源于目标分歧或个人冲突导致的分裂。因此，分叉会带来声誉损失，不同团队之间的关系可能从友好转为高度紧张，甚至敌对。但归根结底，分叉其实是一种"救生阀"，让那些对当前项目管理不满的人有机会证明，他们的替代方案会更好、更具前景。
与此同时，最常见的情况发展是：
- 分叉的终结。宣布一个分叉很容易，但要对其实现有效修改、维护构建环境、搭建演示平台、准备文档以及开发项目迁移工具，则需要付出巨大努力。
接下来是中间情况：
- 要么出现稳定的分化（例如jBPM、Activity、Camunda），要么经过一段时间后，这些分支会重新与原项目合并。此外，采用双重许可的项目也越来越多：用户可在符合开源许可条款的前提下免费使用该产品，而希望在不兼容开源许可的环境中（例如在封闭系统中）使用该产品的公司或用户，则可以购买商业许可。
最后，也是最罕见但至关重要的选项：
- 原版的消亡。当基础项目彻底停止发展并最终关闭时。
分叉的原因多种多样：可能是为了实现某种实验性功能；也可能是移植到新的细分市场或平台；甚至是为了挽救项目，因为主项目由于种种原因陷入停滞。分叉数量过多可能会给所有开发者带来严重问题，但随着时间推移，这种问题会逐渐缓解------那些无法获得发展支持的分叉团队最终会走向消亡。
需要哪些改进
基于分叉创建的软件，其行为最初与基于原始代码创建的软件完全一致。这是确保连续性的关键所在。
但随着源代码的不断修改，生成的软件与原始版本的差异也越来越大。针对Camunda BPM引擎的核心，我们认为有必要考虑并优化以下关键点：
-
消除Camunda组件中存在超过10年的CVE漏洞，我们认为这些漏洞的根源在于供应商无法放弃对已过时技术的支持，而这些技术至今仍在大型商业客户的基础设施上运行。
-
使引擎运行更稳定，使其无需再维护那些已过时的技术（如旧版本的应用服务器、JavaEE 和 Spring Framework 5）。
-
从引擎的程序代码中移除开源版本中未使用的组件（即从Camunda Enterprise代码库继承而来的内置遥测和许可证管理系统）。
-
实现不同流程工件（部署包、流程图与子流程、决策表图、处于不同执行状态的实例等）之间的智能导航功能。
-
实现自定义热力图构建方法，并支持基于Spring Boot Actuator的BPM引擎集成，提供增强的监控功能。
-
确保与最新版JDK（17、21+）兼容，并与俄罗斯版本的操作系统和数据库兼容。
兄弟，力量在哪里？
面向最终用户的Camunda 7分支，首先是一种确保稳定性并降低转向新技术相关风险的途径。采用这一方案，您无需重写项目或重新实现集成：您的旧BPMN和DMN模型将自动被新引擎所兼容并继续运行，所有API方法保持熟悉且可预测，从而将生产环境中的出错几率降至最低。此外，Camunda不仅是一套软件工具，更是一种完整的协作方法论，能够将开发人员与业务分析师紧密结合起来。如果将其替换为第三方解决方案，不仅项目中的程序代码可能需要调整，连团队间的协作方式也可能随之改变，这将带来巨大的组织成本。而分叉则能够保留惯常的工作流程、积累的最佳实践以及与本地基础设施的兼容性。
需要特别强调的是，分叉并不仅仅关乎"复活"。这种方法为工程改进开辟了空间，尤其是在那些主要供应商受限于必须保持向后兼容性或以全球市场为导向的领域。新供应商可专注于用户的特定需求，优先实施那些长期以来备受青睐但原厂并未提供的功能与最佳实践。由此，分叉不仅成为降低成本和降低风险的工具，更成为一个能够向现代需求演进的技术平台。
孤掌难鸣
由一支团队完成如此大规模的改进工作，即使这支团队具备相当高的专业水平，客观上也颇具挑战。不过好消息是，霍尔蒙特公司的开发者产品已在全球广泛普及，因此我们很容易就能促成各团队与项目的合作。 我们关于流程开发通用工具、统一的业务流程执行环境管理中心、支持多种IDE环境以及兼容不同BPM引擎的构想，在社区中引起了热烈反响，这使我们得以携手最活跃的国际团队，共同推进分叉项目的开发。我们向他们的项目提交代码，他们则与我们分享他们的研究成果和专业见解。因此，分叉所发挥的并非是分裂作用，而是恰恰相反，将不同团队凝聚在一起。这真是太棒了。
operaton 不仅是Camunda 7的技术替代品，更是面向重视稳定性和可预测性的企业的战略性选择。我们的分叉版本保留了原平台的所有优势，同时提供了现代化的改进，并完全符合中国的各项要求。
经测试及数字发展部登记处的官方认证证实，我们已做好于2025年10月在Camunda生命周期结束之后立即投入工业应用的准备。我们提供的不仅是一个分叉，更是一项经过验证的技术的演进式发展。
写在最后
任何管理软件技术领域的发展，离不开企业管理最核心的本质-- 降本增效，只要企业的组织架构和协作需求还在，流程的管理及绩效优化依然是企业管理的基础，技术的创新发展离不开业务的本质需求，至于各种新鲜概念更多的还只是营销的需要，专业领域的发展需要持续的沉淀及积累。
关于 鲲鹏BPM
鲲鹏BPM是企业流程管理（BPM）和工作流程自动化软件及服务全球的领导厂商，提供最优秀的企业流程自动化和流程改进的解决方案、流程优化、大模型流程迁移方案。
结合大模型的一款全新旧系统拍照迁移工具，能根据聊天和图片生成标准BPMN 2.0 XML，可与主流开源或企业级流程引擎（如Flowable, Camunda、Operaton、activiti）无缝集成。
同时，欲知更多 鲲鹏BPM 的相关资料，请访问 http://flow.je4.cn/#/login
上传图片，根据图片生成标准BPMN2.0效果：
根据聊天内容生成标准BPMN2.0效果：
