软件发布那天好用，不算难。难的是用了几年，用户正忙着自己的事，它还能安稳地待着。
我更在意后面这个标准。一次更新做了多少功能，不如它有没有打断工作、有没有让旧文件打不开、有没有逼用户重新学一遍来得重要。
iHomePage 从 2017 年做到现在，重写过几次。这个网站就用它。说这话之前，我得先承认：我们自己也花了很多年，才想清楚哪些东西不该继续做。我并不是站在一个从来不折腾的位置上，劝别人少折腾。
更新的成本，经常由用户付
微软 2025 年 10 月的 Windows 11 更新 KB5066835，官方记录里就列了好几个问题。其中一个，是恢复环境里的 USB 键盘和鼠标可能无法使用。另一个，是依赖 HTTP.sys 的网站可能无法加载，包括 localhost。
修复环境本来是出事时救场的地方，更新却连这里一起影响了。用户不是装完补丁就结束，还得判断哪里坏了、查说明、等后续修复。
这种成本也不只发生在电脑上。美国 NHTSA 的 25V710000 召回记录，涉及 Jeep Wrangler 4xe 的空中软件更新问题，可能导致车辆失去驱动力。最后的补救办法是去经销商处理。
发布对厂商可能只是流水线上的一步。到了用户那里，可能就变成半天工作，甚至是一趟线下维修。
「重启一下」不是没有成本
我之前写过 Claude Desktop 在 Windows 上自己关闭、再也打不开的经历。弹窗说文件被占用，后来查到的方向却是 AppX 容器和内核对象的引用。
我的电脑上一直开着终端、编辑器、后台服务和 SSH。重启会把它们全部打断。软件能重新打开了，我还得把原来的工作一件件恢复。
所以我对自动更新的要求很具体：可以下载，可以校验，可以准备好。什么时候结束正在运行的程序，要给用户决定。
如果一种修复方式总是要求用户推倒工作现场，那只是把产品的问题变成用户反复付出的时间。
长期承诺，最好具体一点
Dan Bricklin 在 2004 年就写过能用两百年的软件。他关心的是记录和基础设施，不是说每个活动页面都该活两百年。
这个区分很重要。软件会停用，需求会消失，没有必要什么都永久保留。但承载长期数据的东西，不能只按下一次发版来考虑。
SQLite 的承诺就很具体：长期支持，保持 C API 和数据库文件格式的向后兼容。今天写下的数据库，未来仍应能读写。
Linux 常说不破坏用户空间兼容性。这个承诺也有边界，重点是二进制接口，不是保证所有源码和构建方式永远不变。
承诺能坚持，往往因为范围够明确。说「我们很重视兼容」太宽泛。说清哪一种文件、哪一个接口不能随便改，才知道该守哪里。
活得久，不等于从来没改
BBEdit 从 1992 年做到现在，仍然更新，也仍然发布只修问题的版本。它的稳定，是几十年继续维护的结果。
Sublime Text 的大版本间隔很长。有人把这种节奏看成省心，也有人等一个修复等得着急。两种感受都可能是真的。
IRC 仍能工作，但用户规模早已远小于高峰。假如只把增长当成功，就很难承认一个协议用了几十年仍有价值。
Winamp 又是另一种提醒。2024 年公开源码时，许可证和第三方代码的权利问题接连出现，仓库最后被删除。软件本身还在，交给后人维护的准备却没有做好。
所以，耐用不只是代码不坏。还包括许可证清楚、构建材料齐全、别人有办法接着修。
长期不更新，会把人害了
这一点不能因为我喜欢稳定，就轻轻带过。
Verizon 的 2026 年数据泄露调查报告里，漏洞利用已是很突出的初始入侵方式。CISA 的已知在野利用漏洞目录里，也能看到不少多年前就已经有补丁的问题。
攻击者会用新漏洞，也会继续用早就修好的旧漏洞。老系统照常运行，不代表它照常安全。
「暂时没出事」不是维护计划。安全补丁要及时装。已经停止支持的软件，也需要替换安排。我想要的是稳定维护，不能拿它替放任不管辩护。
但更新通道本身，也可能出事
2025 年，多个常用 npm 包的发布者账号被盗，恶意版本短时间上线。2026 年，axios 也出现过恶意发布事件。
tj-actions/changed-files 的案例更直接。攻击者把已有版本标签指向恶意提交。用户没改配置，也没主动换版本，工作流却开始执行另一份代码。
这说明「一直自动跟最新」也不是完整答案。问题出在发布凭据、可变引用和供应链，不能简单归结为更新太快。
该做的是锁定依赖，校验来源，关键自动化尽量用不可变的提交标识，控制安装脚本。也要区分紧急安全修复和普通功能更新，分别安排处理。
稳定与安全，不该让用户只能二选一。厂商把安全补丁和整个界面重做绑在一起，才会让人觉得不更新反而更省事。
还有一种坏法：厂商不做了
软件也可能没有坏，只是服务被关了，安装包不发了，导出入口过期了。
MinIO 从停止提供容器镜像，走到了仓库归档。Wemo 在 2026 年 1 月关闭云服务，部分设备失去了原有的设置和使用路径。Skype 在 2025 年 5 月退役，后续导出数据也有期限。
它们的情况不同，但都会把同一个问题留给用户：原来依赖的东西，接下来怎么继续？
许可证没有改变，也不代表发布物和维护会一直提供。硬件还在，也不代表依赖的云服务还在。数据名义上归你，也不代表随时都有地方导出。
我希望这些条件在买入时就写清楚。关停时才公布规则，用户往往已经没有多少选择。
我们自己的重写，也该被追问
iHomePage 九年里重写过几次。我不能只说这是技术进步带来的机会，却不承认其中有多少反复。
有一点我会区分：团队自己决定重写，和用户正在工作时被强制更新，承担成本的人不一样。但这不能免掉我们自己的维护责任。
这些年真正让我觉得有进展的，经常是删掉某个计划。一个功能听起来合理，做出来以后，却可能每年都要花时间照看。功能越多，要长期守住的承诺也越多。
少做一点，有时就是为了把答应过的事做好。
如果想让一个软件用十年
- 明确一项必须长期兼容的承诺。文件格式也好，API 也好，写具体。
- 更新可以准备好，但别擅自关掉用户正在用的程序。
- 把安全修复和功能改版分开，给用户清楚的选择。
- 让数据能脱离软件继续存在。用公开、有文档、其他工具也能读取的格式。
- 保存构建所需的材料，别把十年后能否修复，押在某个外部下载地址上。
- 加功能时，把以后每年要维护的成本一起算进去。
- 提前写清停运安排：怎样导出，留多长时间，自托管版本怎么办。
- 安全补丁照样及时处理。稳定不能靠拖延维护来换。
我想要的软件，是用久了以后，用户仍然能放心把事情交给它。发布只是开始，后面天天都好用，才算数。