一个团队把模型权重和推理代码推到公开仓库，当天的讨论区很热闹。三个月后再打开这个仓库，最活跃的地方往往不是提交记录，而是 issue 列表：某张显卡跑不起来、某个版本的依赖冲突、示例代码里的接口早就变了、有人反复追问能不能商用。发布只用了一个下午，回答这些问题要用掉接下来的一整年。
发布是一个瞬间，生态是一段长尾
开源生态经常被理解成“把东西放出去”。但放出去只是起点。真正决定一个项目能不能被别人用起来的，是之后那些不产生新闻的工作：一张说得清楚的兼容性表格、一个能跑通的最小示例、对下游修改的及时回应、把许可证的边界写在显眼的位置。这些事情没有传播性，却直接决定了使用者第一次尝试的成败。
最容易被低估的三件事
- 文档的时效性。示例代码会随着依赖升级慢慢失效，而多数人只会照着示例跑一遍；一次失败往往就会让他们不再回来。
- 兼容性。硬件、驱动、框架版本之间层层叠加，一张含糊的兼容表会让使用者反复试错，最后把问题归到项目本身。
- 许可证与边界。模型能不能商用、输出归谁、训练数据的说明写到什么程度，这些如果不写清楚，使用者就会按最保守的方式去理解。
谁在承担这些工作
上游团队、下游集成者、补文档的志愿者、维护镜像和示例的人。这些人很少出现在发布公告里。开源生态的韧性，很大程度上取决于这些角色有没有稳定的时间，而不是取决于发布当天有多少转发。一个项目如果只在上游有维护者，下游全靠自生自灭，它的长尾会很短。
开放不是默认答案
也有些部分不适合开放。涉及个人数据的处理逻辑、需要严格审计的推理链路、安全敏感的权重发布策略，都需要保留边界。把开放本身当成目的，容易得到一个看着热闹、实际没人敢用的仓库。反过来，把“哪些开放、哪些不开放、为什么”讲明白，反而更容易换来信任。许可证写得拗口但清楚，比写得漂亮却含糊要有用得多。
怎么感觉一个项目值不值得投入
比起发布当天的热度，不如去看三个月后还在回复问题的人有几个，看文档最后一次更新是什么时候，看变更记录里有没有写清为什么改。这些都没有办法用一个数字概括，但花半天时间翻一遍仓库，基本能感觉出来。
仓库能不能被信任，从来不靠一句“我们开源了”，靠的是那些琐碎、重复、没人愿意做但总得有人做的事。