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 版本策略為第三方評測口徑，不代表官方承諾。
