装完依赖，跑通构建，事情看起来就结束了。真正支撑这套东西运转的，往往是几个提交频率很低、文档写得很朴素的仓库。它们不出现在任何介绍材料里，也很少有人专门去读，直到某次升级把它们弄坏。
这大概是开源生态最容易被忽略的一面：热闹的地方和承担重任的地方，往往不是同一批项目。
依赖清单里的真实工作量
打开一个中等规模项目的依赖清单，条目数通常会让人愣一下。直接写进配置的只有十几个，展开之后可能是几百个。名字大多陌生，维护者大多用业余时间照看它们，issue 区里还有几个月没人回复的提问。
问题在于这些项目所处的位置：一个被上百个项目间接引用的解析库，出错时的影响面远超它的知名度；而维护者能得到的回报，往往只是偶尔一句谢谢。开源生态的稳定性，很大程度上建立在这种不对等的付出上。
许可证回答不了的问题
讨论开源生态时，话题很容易迅速转向许可证。它当然重要，但它回答的是“我能怎么用”，回答不了“它还能用多久”。一个采用宽松许可证的项目，同样可能在某天停止更新，把一批使用者留在原地。
更实际的信号藏在别处：最近一次发布是什么时候，issue 是被处理了还是被搁置，文档里有没有写明维护节奏，出现分歧时项目怎么处理。这些细节比许可证文本更能说明一个项目当前的状态。
边缘项目的存续
中心项目被反复讨论、反复投入，边缘项目靠惯性滑行。可边缘一旦断掉，中心也会跟着动摇：修复一个底层小库的成本，有时比换掉整个上层框架还高。
想改善这一点，比较现实的做法是让维护者的时间有出处：有人愿意为维护本身付费，或者把本地改造过的部分回馈回去。这两种做法都谈不上体面，也谈不上高效，但至少让“继续维护”这件事有个落脚点。只靠热情支撑的项目，热情耗尽时就很难继续。
使用者可以看什么
作为使用者，未必需要评估整个生态，但至少可以对自己直接依赖的东西多问几句：
- 这个项目最近半年有没有实质性的代码变动？
- issue 区里，维护者是在回应，还是长期沉默？
- 文档有没有说明哪些功能是稳定承诺，哪些只是顺带提供？
- 如果它明天停止维护，替换路径是否清楚？
这些问题没有标准答案，但问过之后，你对依赖清单的信任会更有依据一些。
开源生态说到底并不是一堆仓库的集合，而是一组相互依赖的承诺。承诺不会自动兑现，它需要有人花时间。你不需要成为维护者，但至少值得知道，自己依赖的那些东西，是谁在花时间照看。