一个软件最热闹的一天，往往是它上线的那天。
项目组拍照，公众号发新闻，首页写着“正式上线”，版本号从 0.x 终于跳到 1.0.0。如果这是学校项目，可能还会顺手拿去参加比赛；如果是政企项目，会有验收会、汇报材料和一整套交付文档；如果是开源项目，README 上会挂满徽章，第一批 Star 来得很快。
三年以后再回去看，画面经常没那么漂亮。
域名还在，证书过期了；登录页面还在，验证码接口已经失效；数据库版本没人敢升；上游 API 改了，页面开始报错；最早写代码的人毕业、离职或者转岗；承建商换了几轮；备份脚本每天都在跑，却没人验证过能不能恢复。
系统没有举行葬礼。
它只是慢慢失去了照顾它的人。
这也是我越来越在意的一个问题：我们是不是已经非常擅长制造软件，却远没有同样擅长维护软件？
V1.0 是最容易的一版
写一个新系统很有成就感。
需求是新的，架构是新的，技术栈可以重新选，UI 可以重新设计。每做一个功能，都能在任务列表上打一个勾。
维护完全是另一种工作。
它很少带来“从无到有”的兴奋感。更多时候，你在处理这些东西：
数据库升级以后某个老 SQL 不能跑了；一个依赖库曝了高危漏洞；浏览器更新后旧 API 被废弃；短信供应商改接口；证书要续；操作系统停止支持；某个学生用户毕业了但历史数据不能删；某位管理员换岗了权限还没交接；三年前写的导入程序突然收到一份从没见过格式的 Excel。
这些工作很难拿去路演。
没人会在发布会上激动地宣布：
我们今天成功把一个运行了四年的系统从 PostgreSQL 15 升到了 PostgreSQL 17，而且用户毫无感觉。
可真正能运行十年的软件，恰恰是靠这种“用户毫无感觉”的工作活下来的。
软件的出生很适合做新闻。
软件的成年、养老和善终，没有那么好看。
软件正在以前所未有的速度出生
GitHub 的 2025 Octoverse 数据很夸张：平台上已经有约 6.3 亿个项目，仅 2025 年就新增约 1.21 亿个仓库，平均每分钟创建超过 230 个。与 AI 相关的仓库超过 430 万个，其中超过 69 万个使用生成式 AI SDK 的公开项目是在最近一年创建的。
图：GitHub Octoverse 2025。630M projects、180M+ developers、4.3M AI projects。来源：GitHub。
当然，这些数字不能拿来证明“废弃软件同比增长了多少”。一个 GitHub 仓库可能只是作业、实验、脚本或者一次性的原型。
但它说明另一件很明确的事：把一个软件做出来，门槛正在快速下降。
过去一个周末只能做个 Demo，现在有了脚手架、云服务、开源组件和 AI Agent，一个人几天就能拼出带登录、数据库、后台管理、权限和部署脚本的系统。
这当然是进步。
麻烦在后面。
AI 可以在一分钟里给你生成五百行代码，却不会自动承诺五年后继续维护这五百行代码。
它不会替你续域名，不会为一次错误的数据迁移承担责任，也不会在凌晨两点因为生产数据库坏了被电话叫起来。
GitHub 在 2026 年谈开源维护压力时写得很直白：生成代码、Issue 和安全报告的成本已经大幅下降，但审查这些内容的成本并没有同步下降。平台甚至在 2026 年增加了 Pull Request 数量限制，理由包括低质量、重复和“顺手提交”的贡献正在挤压维护者的 triage、review 和 CI 资源。
图：GitHub 在 2026 年上线 Pull Request 数量限制。来源：GitHub Changelog。
软件生产力突然暴涨以后，真正稀缺的东西正在从“谁能写出来”变成“谁愿意长期负责”。
开源世界早就吃过这个亏
很多人对开源有一个浪漫想象：代码公开以后，自然会有人维护。
现实没那么自动。
Linux Foundation 和哈佛 LISH 的 Census II 研究分析了数十万条生产环境中的开源库使用记录。一个很扎眼的发现是，在其中一组数据里，排名前 50 的重要开源包，超过 80% 的新增代码由 136 名开发者贡献。
也就是说，我们以为自己依赖的是“全球开源社区”，实际落到一些关键组件上，背后可能就是很少几个人。
图：Linux Foundation 与 Harvard LISH 的 Census II 研究。来源：Linux Foundation。
一个项目用户很多，不代表维护者很多。
下载量很高，也不代表有人有空修你的 Bug。
Star 很多，更不代表五年以后还有人发 Release。
这也是为什么现在越来越多机构开始讨论“项目健康度”。Linux Foundation 新的 LFX Insights 已经把活跃维护者数量、贡献者集中度、贡献者留存、漏洞修复等指标放到一起看。因为单看 Star 和下载量，已经很难判断一个依赖到底靠不靠谱。
代码当然可以永远留在仓库里。
维护能力不会。
我们的项目管理，也长期偏爱“建成”这两个字
这个问题在国内并不新鲜。
2026 年国家网信办网站刊发的一篇政务应用规范化解读，直接点出了过去存在的 “重建设、轻运维”“重数量、轻质量” 倾向，并且专门提到要清理使用频率低、实用性不强的“僵尸”“空壳”应用。
能在正式政策解读里出现这种措辞，说明问题已经不是某个单位偶尔管理不善。
它是一种大家都见过的项目生命周期病。
立项的时候最认真。
验收的时候最热闹。
系统正式进入日常运行以后，关注度反而开始下降。
国家层面的政务信息化项目管理办法其实已经规定，项目验收并投入运行 12 至 24 个月后还要开展绩效自评价，审批部门还可以开展第三方后评价；一些地方的新规甚至把运维、绩效评估、最终退出都放进全生命周期管理里。
这套思路值得更多软件项目借鉴。
因为验收当天能打开首页，证明不了什么。
两年以后还稳定、有人维护、数据能迁、漏洞有人修，才说明这个系统真的活下来了。
我之前在《系统越建越多，为什么办事的人还是要一遍遍填同样的信息》里写过重复建设的问题。其实“没人维护”经常就是它的下一章：旧系统没有真正退出，新系统又立项了，于是组织里堆出一层又一层年代不同、技术栈不同、负责人不同的系统。
最后每个系统都还“在运行”。
只是没人敢碰。
最危险的软件，往往没有真正死掉
一个彻底下线的软件反而比较干净。
更麻烦的是那些处于半死状态的系统。
没人继续开发，但公网端口还开着。
没有用户增长，但服务器还挂着。
没有安全预算，但依赖库继续变老。
管理员已经换了三任，却还有一个六年前创建的超级管理员账号。
没人记得当初为什么这么设计，但业务又确实还依赖里面的一小块功能，所以谁也不敢关。
这种软件特别像城市里的危房。
看起来还站着，于是大家默认它还能继续用。
直到某一天真出事故，所有人才开始翻当年的施工图。
对于安全来说，这种状态尤其糟糕。
维护暂停以后，漏洞数据库不会暂停；证书会过期；依赖会 EOL；攻击方式会继续升级；员工会离职；密钥会遗失；备份介质会损坏。
软件停止演进，并不会让外部世界也停止变化。
高校项目尤其容易产生“一届一系统”
这一点其实离学生很近。
某一届学生做了一个网站。
下一届觉得 UI 不好看，又做一个。
第三届换了老师，需求变化，再做一个。
毕业设计、创新项目、实验室系统、比赛项目，每一批人都更喜欢从零开始，因为从零开始最容易体现“这是我做的”。
维护上一届的系统就尴尬多了。
改了两个 Bug，简历不好写。
做了一次数据库迁移，也不像“创新成果”。
给一个用了四年的系统补完整单元测试，更不会有“打造全新平台”听起来响亮。
于是奖励机制天然偏向造新东西，维护旧东西很难获得同等认可。
最后实验室服务器上可能放着十几个项目。
真正还活着的只有两个。
其余八个不能删，因为“以前是成果”；也不能升级，因为没人知道怎么升级。
这类项目最后留下来的技术遗产，有时不是代码，是一排谁都不敢停的 Docker 容器。
企业里也一样，只不过墓地藏在内网
企业内部系统不会出现在 GitHub Octoverse 里。
但很多公司的内网同样堆满这种东西：临时审批工具、活动后台、内部统计页、一次性数据同步服务、某位员工为了省事写的机器人、一个已经没有负责人但财务月底还要用一次的脚本。
最初它们都很合理。
真正的问题出现在人员流动以后。
代码仓库还在，但构建方法没了。
README 只有一句 npm install && npm run dev，真正运行依赖的四个环境变量没人知道去哪申请。
线上机器是某个离职员工三年前手工部署的。
数据库备份有，但恢复密码在他的个人密码管理器里。
这时候“公司拥有源代码”这句话会显得特别苍白。
源代码只是维护能力的一部分。
系统真正需要继承的是：构建方式、部署方式、数据结构、密钥、权限、故障经验、业务边界和一群知道它为什么存在的人。
所以，新系统立项以前，最好先想好它怎么死
这句话听起来有点丧，其实非常工程化。
飞机设计要考虑退役，数据库要考虑迁移，API 要考虑弃用，软件同样应该有退出方案。
我越来越觉得，一套认真负责的软件立项材料里，除了“功能需求”和“技术架构”，至少应该回答下面这些问题：
- 谁是这个系统明确的长期负责人？负责人离职以后谁接？
- 三年维护经费从哪里来？安全更新、短信、证书、云资源算没算进去？
- 源码能否重新构建，部署流程能否由第二个人完整复现？
- 数据能否标准化导出？备份有没有真正做过恢复演练？
- 依赖停止维护以后谁负责升级或替换？高危漏洞多久必须处理？
- 什么情况下应该合并、迁移或者彻底关停这个系统？
- 上线 12 个月、24 个月以后，谁回来重新判断它还有没有价值？
这几项看起来都没有“AI 智能分析平台”“数字孪生驾驶舱”那么性感。
但它们决定了项目五年以后到底是一套基础设施，还是服务器上的电子遗迹。
我们缺的可能从来不是更多 V1.0
今天的软件开发环境太强了。
一个大学生可以在宿舍里部署过去只有公司团队才能做出来的 SaaS；一个小团队可以在一周内搭出完整业务原型；AI 又把这个速度继续往前推了一大截。
这是非常好的时代。
所以更应该珍惜这种能力。
如果“开发变便宜”的最终结果只是让我们生产更多没人负责的后台、更多半年后失效的小程序、更多无人回复 Issue 的仓库和更多谁也不敢关的旧系统，那些被节省下来的开发成本，迟早会从别的地方收回来。
可能是一场数据迁移。
可能是一次安全事故。
可能是某个周五晚上，突然有人发现一个五年前的服务挂了，而公司的核心流程还依赖它。
写软件的时候，我们很喜欢问：
这个功能多久能上线？
以后也许应该多问一句：
谁准备把它维护到什么时候？
一个项目真正成熟的标志，大概不是发布了多少个新功能。
而是五年以后，当最初写它的人都已经去了别的地方，新的维护者仍然知道怎么升级它、怎么修它、怎么迁走数据，甚至知道什么时候应该体面地把它关掉。
软件和人一样。
能被创造出来当然重要。
有人愿意长期照顾它，也有人知道什么时候让它结束，才算完整地活过。
资料来源
- GitHub Octoverse 2025
- GitHub：Welcome to the Eternal September of open source
- GitHub Changelog：Limit open pull requests for users without write access
- Linux Foundation：Census II of Free and Open Source Software
- 国家网信办：政务应用程序规范化推动基层减负与效能提升
- 国务院办公厅：国家政务信息化项目建设管理办法
- 教育部：高等学校数字校园建设规范（试行）
- 泰州市姜堰区：政务信息化项目全生命周期管理流程
我们是不是正在制造越来越多没人维护的软件？
https://wangling.hauchet.cn/archives/are-we-building-more-software-nobody-maintains
评论