根据开源项目，尾声阶段注意力下降明显？

本文目录导读：

1. 现象层面
2. 为什么会这样
3. 有数据支撑吗
4. 怎么应对

在开源项目的尾声阶段（收尾、维护、或临近发布/交接时）注意力下降明显，这个现象在很多社区里确实存在，也有不少研究和案例支撑,可以从几个层面来理解：

现象层面

开源项目尾声阶段常见的表现：

• PR 响应变慢：维护者对 issue/PR 的回复周期从几天拉长到几周甚至几个月
• review 质量下降：code review 变得敷衍，LGTM 泛滥
• 决策拖延：该合并的不合并，该拒绝的不拒绝
• 文档/测试债堆积：知道要做但没人做
• 核心维护者消失：commit 频率断崖式下跌

为什么会这样

动机结构变化

开源早期靠新鲜感 + 成就感 + 学习动机驱动，尾声阶段这些都被消耗殆尽,剩下的是：

• 重复的维护工作
• 无报酬的责任压力
• 用户抱怨 > 用户感谢

认知负荷累积

长期处理同一项目会产生决策疲劳，尾声阶段往往是最需要判断力的时刻（要不要发 1.0？要不要重构？要不要交接？）,但恰恰此时认知资源最低。

注意力经济

维护者往往同时推进多个项目，当某个项目进入尾声（低回报、高摩擦）,注意力会自然迁移到新项目。

社会性因素

• 核心作者退出 → 剩下的人缺乏权威感
• fork 分流 → 社区分裂
• 商业化/公司赞助变化

有数据支撑吗

有,比较常被引用的观察：

• Avelino 等人（2019） 对 GitHub 项目的研究发现，维护者倦怠与项目生命周期阶段强相关
• Coelho & Valente（2017） npm 生态的研究显示，大量包在“完成后”进入低维护状态
• Eghbal《Working in Public》 提出“stadium/venue/toy”分类，指出很多项目本质是“完成后即博物馆化”
• Linux、Python 2、Angular.js 等大项目的 EOL 阶段都呈现类似模式

怎么应对

如果是你所在的项目：

1. 显式宣布 EOL 或维护模式，比拖着强
2. 降低贡献门槛：good first issue、明确 roadmap
3. 交接/共维护：引入 co-maintainer
4. 自动化：CI、dependabot、stale bot 分担注意力消耗
5. 接受“完成”：不是所有项目都要永续活跃

如果你指的是某个具体开源项目（比如某个 ML 框架、某个工具库）出现了尾声阶段注意力下降，可以告诉我名字，我可以针对它的 commit/issue 数据具体分析。