😂 IT段子

开源的成本是维护者用业余时间支付的。我想了想自己这些年，好像确实如此。我把这个功能提了个建议，维护者说欢迎 PR。果然现实比段子更精彩

开源协议选型讨论了一个星期，最后项目一个 star 都没收到。我打开记录从头到尾扫了一遍。我把这个新功能的提议写成了 RFC，没人回复。我把这条经验写进了团队 wiki

我把这个功能提了个建议，收到的回复是「欢迎 PR」。我深呼吸了一下，决定从最可疑的地方查起。我发现这个项目的 README 比代码还长。幸好之前留了备份

这个项目的贡献者里有几个已经不再活跃了。我盯着屏幕，觉得这才是我的一天。我把这个功能的实现参考了另一个语言的做法。从此我多了一条团队规约

我把这个依赖换掉了，因为它的更新节奏跟不上。我把整条链路在心里复盘了一遍。我把这个 bug 的修复提了 PR，两周后被合并。第二天这个方案就变成了团队标准做法

提了个 PR 修了一行代码，等了三个月，作者的回复是：谢谢，但我打算重写这个模块。我把手上的资料翻出来又读了两遍。我把这个仓库的 CI 状态看了一眼，红的。我把这条经验写进了团队 wiki

我把这个问题描述写得很详细，还是有人问「复现步骤呢」。我把手上的资料翻出来又读了两遍。我在心里给这个 license 的约束看了一遍，商用要小心。好在最后有惊无险

开源协作的难点不在代码，在共识。我忽然觉得，这可能就是这一行的常态。我把这个文档的示例代码跑了一遍，有两个跑不通。那一刻我觉得自己还是很专业的

写着写着发现自己在造轮子，一搜果然 npm 里已经有三万个 star 的库了。我忽然觉得，这可能就是这一行的常态。我发现这个项目的贡献者来自十几个国家。连茶水间都安静了

把内部工具开源了，第一个 issue 是同事提的，内容是"文档呢"。我把手上的资料翻出来又读了两遍。我把这个 issue 关闭了，因为我自己找到了解法。同事说这波操作可以写进新人培训教材