上游不修了，这套系统还能撑几年

一、上游说不维护了，软件明天还能跑吗

大多数时候还能跑。昨天能启动的系统，不会因为上游社区发了一封公告就停在原地。

变化的是另一件事：以后出了问题，没有人再按惯例修。漏洞、兼容、新硬件、新浏览器，这些过去由上游顺手处理的事，现在归你了。

公开报道里有一件近的例子。今年十月二日，西门子关掉了 OpenRadioss 这个免费开放了四年的仿真项目。

需要注意的是，它并没有消失。源代码和安装包还留在各处存档里，商业版继续卖，只是公开项目那条线不再有新功能。

这就是老板要先分清的第一件事：停更不等于软件坏掉，而是「以后由谁负责」换了人。

二、停更分三种，先认是哪一种

第一种是换商业版续接。公开的那条线停了，同一个团队在卖的版本还在更新，条款变了。

OpenRadioss 就属于这种。公司把用户往商业版引，代码还能跑，服务要买。

第二种是真停更。没有人接，没有商业版，提交记录停在某一天，补丁也就停了。

第三种是换了许可证。软件照常更新，但用法和价钱重新算一遍，很多团队是这一种最容易吃亏。

三种情形对应三种处置。用同一种办法应付三种情形，通常要花两遍钱。

三、第一种：换商业版续接，功能还在，条款变了

这一类最常见，也最好谈。因为对方还要做生意，会给你一份合同，而不是一句「不维护了」。

要看的不是功能表，是价格和期限。有的按年收，有的按机器数收，有的按调用量收。

还要看一条：以前你自己改过的那几处，商业版认不认。改过的地方越多，迁移时补的活越多。

举个例子：一家做设备巡检的公司，四年前拿一个开源仿真工具做二次开发。上游转商业版之后，功能没少，年费按坐席算，比它当初料想的高出不少。

四、第二种：真停更，补丁和新硬件支持一起停

真停更的信号很明确：主版本号很久不动，问题列表里没人回复，发版记录停在过去的某个月。

它不会立刻坏，但会一点点落后。新的操作系统不支持，新的安全标准不认，新买的机器跑不动。

这一类拖一年，代价往往比现在就换更高。因为拖到最后，你是被一次故障推着走的。

五、第三种：只是换了许可证，账要重算

许可证一改，用法就可能从「随便用」变成「按量付」或者「不能转卖服务」。

很多团队的软件清单里，这一类的占比比想象的高。清单不更新，账就一直按旧的理解在算。

公开报道里也有同类的事：几个常用组件改了许可，半年后法务才发现自己在按旧条款做生意。

看到许可证变更的公告，第一件事是把这组件在哪些系统里用的清单拉出来，不是先争论它合不合理。

六、危险的组合：停更＋你还在加新需求

真正容易出事的是这一种：上游停了，你这边还在给这套系统加功能。

维护者停了，意味着踩坑的人只剩你自己。每加一个新需求，都是在没有人兜着的地基上再砌一层。

公开报道里，今年十月有一件很像的教训。PHP 官方披露的一个漏洞，线索最早出现在二〇二四年的一次外部审计里，当时就有一位核心开发者注意到了。

公开报道说，问题一直没修，后来是被一个 AI 模型先找出来的。基金会自己的说法是：迟迟没修，是一次结构性的失败。

这不是某个程序员偷懒。是「看见了，谁出钱修，谁承担改坏的风险」没有答案。

七、有没有人在修：看提交、看发版、看谁在回问题

判断一个项目还活不活，不用看宣传，看三样东西就够了。

一看提交记录：最近一年有没有实质改动，还是只有改错别字。

二看发版：安全修复有没有跟着版本出门，还是攒了一年才发一次。

三看谁在回问题：是维护者本人在回，还是一片没人管的求助帖。

三样都冷，就是真的没人管了。这时不管软件现在多稳，都要按「真停更」处理。

八、自己接手要付的三笔钱

第一笔是人。你至少要有一个人，能把问题看懂、能把补丁合进来、能对新版本做验证。

第二笔是时间。上游一年改五次，你接手以后也得跟上五次，否则差距只会越拉越大。

第三笔是风险。你自己合的补丁，出问题没有别人替你兜着，责任落在签字的那个人身上。

三笔加起来，通常比买一份商业支持贵。愿意自己接手的，多半是因为这套软件离业务太近，改起来比换更省事。

还有一件事容易被忽略：接手的人得留得住。这个人一走，代码里那些「为什么这么改」的理由也跟着走。

所以接手之前先回答一句：三年之内，这个人还在不在。答不上来，就还是买支持更稳。

九、买商业支持前，先问四句

第一句：安全补丁多久给一次，延迟最长几天。

第二句：只修已知问题，还是连新硬件、新系统的适配也管。

第三句：合同到期不续，已经发布的版本还能不能用。

第四句：他们自己什么时候停止支持这个版本。

四句里最容易被忽略的是第三句。很多合同写得很漂亮，续费一停，补丁也就停了。

问的时候把答案写下来，谁答的、什么时候答的，一起记上。口头承诺在续费那天就不算数了。

十、换掉之前，先把「用到哪几处」数清

换一个组件，先要知道它到底被几处调用。清单不准，工期就是猜的。

从依赖清单出发，再拿线上实际运行的记录对一遍，对不上的地方以线上为准。

然后看两头：哪些地方只是简单调用，可以顺手换；哪些地方做过二次开发，要单独排期。

数清之后，通常会发现真正难换的只有两成，其余八成是顺手的事。心里有数，谈判和排期才稳。

十一、漏洞出来了，先看有没有人认领

漏洞公告出来之后，先看有没有人认领修复，而不是先看严重程度。

有人认领、也在发版，就按正常流程排期升级，别慌。

没人认领，或者认领的人自己说「没有时间」，那就要按停更处理，往三条出路里挑一条。

最差的一种情况是：有人认领，但修法会改坏兼容。这时要算的是「改坏的那部分」和「漏洞暴露的那部分」哪个更贵。

这两种账都不好算，但有一个办法能让它变简单：提前把「这套组件坏了会影响哪些业务」写在纸上，出事那天照着看。

十二、今天能做的三件事

第一件，把清单拉出来：清单里每一个组件，标上最后一次发版的时间和维护方。

第二件，标出危险的：还在加新需求、又属于停更状态的，单独列一行。

第三件，给每个危险项写一句处置：买支持、自己接手、还是排在明年换掉。

三件事加起来，一间中型公司的技术负责人，一周之内能做出来。做完之后，再谈预算就有依据。

十三、这套判断管几年

这套判断不是一次性的。依赖会变，项目会停，许可证会改，明年还会有新的名字出现在公告里。

所以把它做成一年一次的例行检查，比做一次大排查更有用。

例行检查的成本很低：清单在版本库里，标一标发版时间，半小时的事。

真正贵的是不做检查。等出事那天才发现上游三年前就不动了，那时能选的只剩最贵的那条路。