如果你翻一翻自己项目依赖的那些仓库，多半会撞见类似的画面：最后一次提交停在几个月前，issue 区里有人认真描述了问题，还附上了复现步骤，然后就没有下文了。删掉？好像还能用。留着？心里总有点不踏实。开源生态里大量真实的处境，就卡在这两种念头之间。
被看见的是代码，被消耗的是注意力
一个仓库能被别人用起来，靠的不只是核心那段逻辑。有人把报错信息整理成能复现的步骤，有人补一段新手看得懂的说明，有人把散落在讨论里的结论收进文档，有人在依赖升级后默默修掉编译不过的地方。这些事不会出现在发布说明里，也很难被外部感知，但它们决定了别人第一次尝试时的体验。开源生态的运转，很大一部分重量压在这些不显眼的动作上，而做这些动作的人，多数是用自己的零碎时间。
许可证划的是边界，不是承诺
不少团队在选型时会认真读许可证，这当然必要。但许可证回答的是“我能怎么用”，不回答“出问题时谁在”。把许可证当成服务承诺，是很常见的误读。反过来，使用方也没必要因为项目免费就默认它必须随叫随到，这两件事本来就不在同一个层面上。
公司参与进来之后，节奏会变
越来越多企业把工程师放进开源项目里做持续投入，这是件好事：有人能稳定跟进 issue，有人能做版本规划，文档和测试也不必只靠周末补。但公司的动机和社区的习惯并不总是一致。公司要为产品路线负责，社区里有人在意兼容性，有人在意某个小众场景，还有人只是希望自己的补丁被认真看一眼。节奏不同未必是冲突，但它需要被说出来、被写进规则里，否则沉默的一方会慢慢走开。
分叉解决代码，解决不了人手
遇到停滞的仓库，技术上分叉一份继续维护并不难，难的是之后的日子。你得接住上游的变更，得回应别人的问题，得在某天自己也不想干的时候找到下一个人。很多分叉就停在第一个人离开的时候。所以我在看一个项目时会多想一层：当最初那个人不在了，这里还有没有第二双手愿意接。
这也是我对开源生态的一个朴素判断标准。它不取决于仓库有多热闹，而取决于无人发声的那段时间里，事情会不会自己转下去。能做到这一点的项目，通常不靠某个英雄，而靠一些很小但被固定下来的习惯：
- 把决策写下来，哪怕只是“暂时这样”；
- 把新人提的第一个问题当回事；
- 把“我不知道”也如实说出来，让别人有机会补位。
回到开头那个问题。换不换，取决于你能承受多少不确定性，以及你愿意分出多少时间去填那个空。有时答案是自己动手，有时是把依赖收窄、把风险摊开，还有时候，答案只是发一条礼貌的催促，然后继续等。开源生态里没有哪一步是真正免费的，只是账单送来的方式和时间不同。