11 月 6 日凌晨 1 点 04 分，ERPNext 发布 v16.54.0。13 项功能里，最不起眼的一条是：把会修改数据的操作，限制为只能用 POST 请求。
它不会让任何页面变慢，也不会在界面上弹出错误。它只会让一批凌晨跑批的脚本，在第二天早上安静地失败——或者更糟，安静地什么都没做，而报表照常出，数字是旧的。
同一周还有两件事：11 月 12 日，ERPNext 又发了 v16.55.0 与 v15.125.0；11 月 6 日，媒体报道微步在线就 Artex 项目闭源发布版权声明，明确 10 月 8 日之后流传的 fork 都不算官方版本。把这三件事放在一起，开源软件在企业里的真实成本结构才露出来：你拿到的是一份代码，不是一张时间表。
一、补丁日：改的是接口契约，不是功能
先看这一串版本节奏。下面是 GitHub 发布页上能查到的时间：
| 版本 | 发布日期 | 关键变更 | 谁会受影响 |
|---|---|---|---|
| v15.124.5 | 2026-11-04 | v15 维护线常规修复 | 仍在 v15 的存量部署 |
| v16.54.0 | 2026-11-06 | 写操作限制为 POST；物料/客户/供应商增加公司级限制；客户冻结与解冻日期；销售订单直接生成形式发票 | 自研集成脚本、多公司集团、信用管理流程 |
| v16.55.0 | 2026-11-12 | 生产计划按权限过滤仓库与订单；预留关闭时不再创建预留 | 制造与仓储角色 |
| v15.125.0 | 2026-11-12 | 生产计划只显示用户可访问的已提交销售订单 | v15 多公司部署 |
2026-11-04 至 11-12，ERPNext 在 v15 与 v16 两条维护线上共发布 4 个版本（GitHub 发布页）
节奏不是问题，开源项目本来就走得勤。问题在变更的性质。POST 那一条，对应的 PR 是 #62519，官方描述很直白：修改数据的操作只能用 POST，仍用 GET 调用的脚本必须改；顺带把销售订单门户上的"支付"按钮也换到了新方法上。
这条为什么会伤人？企业里大量"胶水代码"是这么写的：一个定时任务，用 GET 拼一个 URL，把 ERP 里某张单据的状态推给 WMS、OMS、对账平台或者银行前置机。这类脚本往往没有测试、没有监控、没有负责人，只在出事那天才被想起来。
升级前先做一件事：把所有"用 GET 改数据"的调用找出来。
方法不复杂：在测试环境打开访问日志，筛出方法为 GET、路径命中写入类端点的请求；再对自研脚本做一次全量检索。改完不只是换方法名——重试逻辑、幂等键、超时设置都要跟着复核，因为 POST 失败后的重放行为和 GET 完全不同。
还有一个容易被忽略的细节：GitHub 发布页自己标注了，发布说明是由 LLM 生成的摘要，可能存在错误，细节要回看 PR。这不是黑开源，恰恰是提示企业——发布说明是线索，PR 才是证据。做变更评审时把 PR 号抄进变更单，比抄一句"修复若干问题"有用得多。
二、主数据的公司边界：从默认共享到显式授权
v16.54.0 里另一条影响更深的变更，是给物料、客户、供应商三张主数据加了"限制公司"和"允许公司"两个设置（PR #63045）。官方描述是：只有被允许的公司的用户才能看到这些记录；其他公司的交易不能使用被限制的记录；与被隐藏主数据关联的记录，也会一起被隐藏。
过去多公司部署的默认状态是"共享"：一张物料表全集团用，靠价格表和仓库去区分。现在默认状态变成了"可显式收紧"：谁能在哪家公司用这张物料、这个供应商，是可以逐条设定的。方向是对的——集团里共享供应商但分公司独立采购、独立结算，本来就该有边界。但对已经跑了几年的系统，这是一次数据契约的重写。
最容易踩的时间点是月结。采购订单引用了某张被限制的供应商记录，单据会被隐藏或拒绝；销售订单引用了被限制的客户，开票时才发现找不到主数据；跨公司调拨的中间单据，两头的主数据可见性不一致。这类问题不会在上线当天出现，会在第一次跨公司结账时集中出现。
依赖顺序是硬门槛：这个功能依赖 Frappe 16.55.0 及以上（PR #63977）。
先升框架、再升应用，否则会出现"功能菜单在、配置项不出现"的假象，实施人员很容易误判为版本不对而反复重装。另有一条同批变更：客户可以设置"冻结"与"解冻日期"，被冻结期间销售订单、交货单、销售发票、POS 发票都不能保存或提交，报价单仍可开——这条把信用管理从"靠人记"变成了"系统拦"，但也意味着历史遗留的冻结标记会立刻生效。
这也是开源 ERP 这两年的方向：功能追赶基本结束，剩下的活是把多组织、多权限的边界做扎实。Odoo 20 合并了操作与记录域，ERPNext 把公司边界做到主数据层，路径不同，结论相同——智能体进来之前，先得让"谁能看什么、能改什么"变成可执行规则。
三、分支日：fork 不是备份
11 月 6 日，媒体报道微步在线就 Artex 项目闭源发布版权声明。要点很清楚：Artex 已于 2026 年 10 月 8 日正式闭源；此后互联网上公开流传的各类 fork 都不属于官方发布；原始版本受 AGPL 3.0 约束，对外分发原版或修改版都要保留版权声明、附带完整许可文本、标注变更；如果第三方要基于它做商业闭源产品，需要单独洽谈商业授权。商用版本 Artex Pro 只通过其 RedAgents 平台对企业客户开放。
这不是孤例，而是开源商业化的常规动作：先以 AGPL 聚拢社区，再以闭源版本做商业闭环。对使用方来说，真正要理解的是 AGPL 的传染性——它管的不是"你有没有改代码"，而是"你有没有分发"。企业内部自己用、自己改，义务有限；一旦随项目交付给客户，或者包装成服务对外提供，源码提供义务就跟着来了。踩坑往往不是因为想占便宜，而是把"内部使用"和"交付客户"混在了一个代码库里。
| 有源码 | 有维护 |
|---|---|
| 你能读、能改、能自托管；出问题时可以自己定位，不必等厂商排期。这是真实的控制权。 | 有人持续合并安全补丁、跟进依赖升级、回应漏洞披露；分支有归属、有 SLA、有明确的许可证状态。 |
这两件事经常被混为一谈。闭源那天发生的，不是"代码消失了"，而是你的 fork 从"上游的一条分支"变成了"你自己的私有分支"。安全补丁要自己写，依赖升级要自己扛，合规审查要自己举证，出了漏洞没有上游可以指认。团队里如果没有人专门负责这件事，它就会一直沉在待办列表底部，直到某次扫描报告把它翻出来。
最危险的错觉是："我们 fork 过，所以不怕闭源。"
fork 保住的是那一时刻的代码，不是之后的维护。闭源后流传的衍生版本还多了一层风险：来源不可验证，代码投毒无从排查。微步在声明里专门提示了这一点。企业该做的不是继续找"最新可用分支"，而是把这份代码登记为"自维护资产"，明确负责人、补丁节奏与替代方案。
四、把第三张到期日写进合同
11 月 12 日，中国电科旗下电科数字发布消息：由华讯网络牵头，金融、交通、能源等行业单位及复旦大学共同参与编制的团体标准《软件产品开源应用风险评估规范》，已在全国团体标准信息平台正式发布。公开信息写明，规范系统规定了软件产品开源应用风险评估的评估对象、评估流程、评估指标、风险分级与处置要求。
我没有取得该标准的编号与条款原文，这里只把它当作"框架已经出现"的信号。值得关注的是评估对象转向：过去问"用了多少开源"，现在要问"这三张日期能不能被回答"。
| 到期日 | 要回答的问题 | 证据在哪 | 责任人 |
|---|---|---|---|
| 补丁日 | 这次补丁改了哪些接口契约？我们的调用方跟不跟得上？ | 发布页 PR 号、变更日志、集成调用清单 | 集成负责人 |
| 支持终止日 | 这条版本线还能撑多久？升级路径上缺哪个模块？ | 官方支持矩阵、依赖下限、第三方模块的版本状态 | 平台负责人 |
| 许可变更日 | 许可证会不会变？变了之后我们还能不能交付给客户？ | 许可证文本、商用条款、上游治理结构 | 法务 + 采购 |
顺带说一句版本线的寿命。第三方评测（Cloud Converge，2026 年 11 月）称 ERPNext v15 的支持计划到 2027 年底、v16 到 2029 年底；同样的口径下，Odoo 只支持最近三个大版本。这些是第三方整理，不是官方承诺，但它提醒了一件事：开源项目的"支持期"不是一句"社区会管"，而是一张要看清楚的表。
给 CIO 的三条动作，下周就能开始：
- 台账加三列。每一套开源组件记三项：版本线与依赖下限、上游分支状态（活跃/停滞/已闭源）、许可证与商用条款。不要新建系统，先在现有 CMDB 或采购台账上加列。
- 补丁前跑两条探针。一条只读探针验证权限与可见性，一条写路径回归验证所有改数据的调用。把"用 GET 改数据"的清单一次性清零，比每次出事再查便宜得多。
- 合同写两句话。许可变更提前多少天通知；若上游闭源，源码、构建脚本与依赖清单是否交付托管。这两句比任何"原厂支持"承诺都实在。
开源的"免费"，买的是获取代码的那一下动作。要付的是时间表：什么时候打补丁、什么时候必须升级、什么时候许可证会变。CIO 的活，是把这张时间表从社区手里要过来，放进自己的变更日历。
回到 11 月 6 日凌晨的那个补丁。它没有上新闻，也没有发布会。但它比大多数 AI 功能更能决定一套系统明年还能不能正常运行——因为 AI 可以等，脚本不会。
资料来源：ERPNext GitHub 发布页（v16.54.0，2026-11-06；v16.55.0 / v15.125.0，2026-11-12；PR #62519、#63045、#63041、#63977、#62152）；itHub Directory ERPNext 条目（更新于 2026-11-07，含 Python 3.14 与 Frappe 16.55 依赖说明）；Frappdate 发布摘要（2026-11-06）；消费日报网《国内网络安全公司微步针对 Artex 二次开发商用发布声明》（2026-11-06）；中国电子科技集团《软件产品开源应用风险评估规范》正式发布（2026-11-12）；Cloud Converge《Odoo vs ERPNext》（2026-11）。
口径说明：版本日期与 PR 变更以 GitHub 发布页为准；发布说明为 LLM 生成摘要，细节已回看 PR 条目。Artex 闭源日期、许可义务与 RedAgents 能力数据均引自微步在线声明及媒体报道，其中"数十家大型企业""100% RCE 级别突破"为厂商自述，未经第三方审计。团体标准的编号与条款原文未取得，本文仅引用其评估框架的公开描述。ERPNext 支持期与 Odoo 版本策略为第三方评测口径，不代表官方承诺。
