开源项目资深大佬：被冒犯到停止维护代码，让它真凉吧！

出品|51CTO技术栈（微信号：blog51cto）

“hey，你这个开源项目是不是已经死掉了？已经被分叉了吗？”

Max表示他开发这些工具包的主要动机一直都是：一，兴趣；二，改善垃圾帖子。在那段时间里，包括最近一段时间，大众对于网站种充斥着AI生成的内容的反抗情绪如此强烈，Max开始意识到没有人类控制的情况下发布AI生成内容的危险性，因为现在他如果发布“MadebyAI”的内容，多半会收到死亡威胁。

激烈的抵抗AI生成内容的大众情绪，再加上AI行业发展速度之快，让Max决定修整一段时间为自己充电。

在这段时间中，Max暂停了开源项目的更新与维护，这本应该很好。然而，令Max意想不到的情况让他气炸了。

图片

问题就出在Max一个最新开源的项目上。simpleaichat，是Max开发的一款用于与ChatGPT交互的Python包，目前已经取得了3000GithubStars。由于这个包的设计范围非常明确且有限，而且依赖性最小，Max就认为这个包可以在不破坏代码的情况下暂停开发，等他自己将状态调整恢复过来之后再进行维护。

可等他恢复了正常的开源节奏之后，却收到了这样一个关于simpleaichat的GitHub问题，标题简短且充满讽刺：“这已经被放弃了吗？” 

图片

另一位GitHub用户也补了一刀：“恕我直言，我也对答案感兴趣。”Max看到这个问题，还以为这个项目出现了很严重的Bug或依赖性问题，但检查之后完全没有。 

这还没完，2天之后，Max又一次被这类问题cue到了——“这个包还在开发中吗？”“是不是已经被人分叉出去维护了？”

图片

Max觉得这很无理取闹：是否有一个潜在的条款来要求开源人必须积极维护他发布的任何开源软件？如果在GitHub上达到一定的星级或通过GitHubSponsorships/Patreon申请资金，你就有义务提供免费的支持吗？

没有。毕竟，像MIT等大多数许可的开源代码许可证都包含类似的一条：“软件按原样提供，没有任何形式的保证”的变体。  

这样粗鲁的情况并非个例。simpleaichat并不是Max第一次遭到这样抱怨嘲讽的开源项目。

大约十年前，Max在GitHub上发布了一个跟踪对抗性用户输入文本字符串的项目—— BigListofNaughtyStrings，现在已经有45k星，这个项目本质上就是一个txt文件，根本不存在依赖性问题。而且，如果添加对各种字符串问题不敏感的内容到列表中，可能会使列表变得更加混乱，所以我很犹豫是否接受每个拉取请求。但尽管如此，依旧会有人感到不爽。

图片

可能到现在也有人认为，GitHub零问题或零拉取请求（PR）是理所应当的，但这过于理想化，工作生活的现实就是，我们的收件箱永远做不到清空状态。

每个平凡的开源项目都会有一个问题/PR队列，这需要一个分类优先级：并非所有问题和PR都是同等重要的，筛选队列需要时间和精力。

作为一名维护人员，Max越来越意识到这一点，因为接受误导性的PR，反而会带来更多的技术债务，需要付出更多的努力来解决。

Max举了一个发生在自己身上的例子。用户遇到一个很酷的GitHub项目，很长一段时间没有更新了，难免沮丧。这种事也经常发生在Max身上。

开源的一大好处是，如果一个拥有许可证的开源项目确实处于非活动状态，那么它就可以无缝分叉。有时分叉可以变得比原来的项目更好，这对每个人来说都很棒！

但根据Max的经验，它反而被用作威胁。维护人员一旦懈怠，就会有人拿分叉当做威胁的理由，甚至分裂开发社区。

AI行业实在太独特了，发展速度非常惊人，变化也完全超出了人们的预期。Max看来，最近的ChatGPT受益者，如LangChain、LlamaIndex和AutoGPT，产生了一种错误的感觉，即开源的人工智能项目必须像火箭一样一直持续冲刺发光发热，但问题就在于开源维护者是人，不是机器，并且现在的维护者也有自己的全职工作，当然现在也有不少是由大量风险投资所支持的公司在管理。

持续为开源项目提供支持的这种压力，Max认为已经无形中成为了开源工作的最大障碍。Max目前已经停止了发布有趣的一次性项目和人工智能模型，因为他实在没有足够的“带宽”（精力）去处理这些偷懒的问题，比如“嗨，这里出问题了，请修复，谢谢！”不管是不是会产生依赖性中断的问题。

Max表示：“如果能挣到同等的薪水，我很乐意辞去数据科学家的专业工作，全职从事开源项目。”他认为，现在唯一能让开源项目它发挥作用的方法，就是像所有人工智能初创公司一样筹集风险投资。

许多人可能认为一个良好的开源维护者应该做到积极及时地响应和解决各种issue，要不断地、有节奏地发布版本，要有十分完善的说明文档，还要在各种交流社区回复问题等等。

但事实并非如此，开源维护者也许只有几个人甚至只有一个人在作战。他们并不是全职做开源项目，精力和能力有限。就如同某位Alluxio社区的开源维护者提到的：“对于不少其实还是挺合理的用户需求和反馈，甚至一些好很好的PR，我都拖延了很久很久，这里给大家先道个歉。”

源：知乎

另外提醒一点，使用开源项目提问题需要理性，而不是无脑抬杠。最近就曝出了一条新闻，说一名开发者在Vant的GitHub仓库提交了一个issue，跟有赞的开源维护者杠上了。

图片

这位开发者最后有些吵架的情绪：“我的问题是，那你说它到底合理不合理呢？中文理解就这么困难吗？”（PS：让维护者给出2选1的答案：合理或者不合理。）

图片

没错开源精神鼓励自由和分享，但并不意味着使用者可以用命令甚至威胁的口吻去冒犯。不管是精神领袖斯托曼还是Linus，他们倡导的都不是这样一种维护者不被尊重的文化。当然，这也再一次暴露出了目前开源项目维护管理的问题所在：用爱发电被当成理所当然。

最后，千万不要再当面询问维护者“开源项目是否已经凉了”这种问题了，非常愚蠢。轻则惹恼维护人员并延迟开发。重则会刺激到维护人员，让他们重新考虑继续从事开源项目是否值得，真的让项目凉透。

北京市海淀区中关村南1条甲1号ECO中科爱克大厦6-7层

北京市公安局海淀分局备案编号：110108002980号营业执照