一个开发者把某个开源项目的 README 从头翻到尾，示例跑通了，配置一改就报错。他打开 issue 列表，看到半年前有人问过同样的问题，唯一的回复是「欢迎提交 PR」。这不是个例，而是很多人接触开源时的第一道坎：源码是开放的，理解成本却没有跟着开放。
我们习惯用仓库数量、提交频率来谈论「开源生态」，可这些数字描述的是产出，不是通路。生态里还有一大块不产生代码的东西：有人把安装步骤写成新手能照着做的样子，有人盯着依赖升级，有人在别人提问时愿意多解释一句背景。这些工作不出现在提交记录里，却决定了外面的人能不能走进来。
门槛不在许可证，而在默认前提
很多项目的文档是从作者视角写的。它假设读者已经知道这个项目为什么这样设计、哪些参数可以忽略、报错信息里的那个词指的是哪个子系统。作者当然清楚，因为他从第一天就在场。新来的人不在场，于是同一个报错，对前者是提示，对后者是谜语。
issue 区也常有类似的气氛。提问被当成噪音，回答被压缩成一句「看文档」。这句话本身没错，问题是文档假定你已经在正确的上下文里。把解释成本转移给最缺上下文的人，是一种很省力、也很有效的筛选机制。它筛掉的不一定是不合适的用户，很多时候只是还没找到入口的人。
许可证管的是另一件事
许可证经常被当成法律条款来读，其实它也在塑造参与意愿。下游能不能把代码嵌进自己的产品，能不能改完再分发，是否需要公开修改，这些决定了有多少人愿意长期待在这里。一个许可宽松的项目，可能吸引来大量使用者；一个许可严格的项目，可能留下更愿意回馈的少数人。两种情况都成立，麻烦的是宣传口径和实际条款对不上——使用者照着前者做预期，撞上后者才发现要重新评估。
谁在为那些没人提交代码的仓库付账
开源生态能不能自我维持，很大程度上取决于这些角色有没有人接手：
- 打包者：把源码变成各平台能直接装的东西，处理编译选项和依赖冲突。
- 文档维护者：跟着接口变化改示例，删掉已经跑不通的旧写法。
- 答疑者：在 issue 和讨论区里补上下文，把重复问题收敛成条目。
- 持续集成维护者：让每次提交都能被验证，而不是等到发版前才发现问题。
这些岗位大多没有报酬，也很难写进简历。它们靠习惯、靠个人兴趣、靠某家公司顺手承担。一旦承担的人离开，项目表面上看还在更新，实际上已经失去了接待新人的能力。
不是每个项目都该做生态
有些项目由一家公司主导，源码开放但治理集中，路线图不对外讨论。这不必然是坏事：统一决策有时比协商更快，用户也能得到稳定的接口。问题在于表述。把「代码可见」说成「共同建设」，会让照着宣传来的人产生错误预期，最后双方都觉得被辜负。
反过来，也有些项目过度承诺开放性，结果每个方向都有人提，没人拍板，版本节奏被拖散。开放本身不是目的，它只是一种组织成本的分摊方式。分摊得动就分摊，分摊不动就诚实说清楚边界，这比含糊其辞要体面。
如果你正打算在一个开源项目上投入时间，先别急着看特性列表。翻一翻最近三个月的 issue，看提问有没有人回；照着文档从零装一遍，记下卡住的次数；再看看最近一次接口变更，示例有没有同步改。这些琐碎动作给出的信号，往往比一份功能清单更能说明：你即将进入的是一个还在生长的开源生态，还是一个只能远观的代码仓库。