开始在维护一个小库后,我终于理解了为什么维护者会沉默
摘要
一位开发者分享了自己维护一个小型开源库的经历,描述了问题数量、功能请求和AI生成的拉取请求如何导致倦怠,并敦促用户赞助维护者。
大约一年前,我构建了一个内部小工具,开源了它,心想也许会有10个人觉得有用。它慢慢积累了几百个星标,然后问题就开始来了。不是铺天盖地,但也足够多,而让我惊讶的是,其中很多并不是真正的错误——而是人们希望添加一些对他们用例有意义,但对原始范围毫无意义的功能。或者是一些像“你的README没有考虑到我的特定设置”之类的问题。我喜欢帮助别人,我以为我会享受这个过程,一开始也的确如此,但大约在第四个月时,我发现自己开始害怕打开GitHub通知。AI生成的拉取请求让情况变得更糟,老实说。不是因为这些代码总是很糟糕,而是因为它们带着自信的描述出现,表面上看很合理,然后你要花30分钟追踪边缘情况,才发现提交者实际上并没有针对任何真实场景进行测试。以人类贡献的节奏,这是可控的。但以“有人点击生成然后提交”的节奏,这完全是另一个问题。现在我无比尊重那些拥有大量用户库的维护者。那些维护着半个互联网依赖的库的人,大部分是免费在做,大部分是利用业余时间,而且大部分时候还要面对那些写得像向客服投诉一样的问题报告者。如果你使用开源软件,并且它为你节省了几个小时的工作,去赞助某个人吧。即使每个月几美元也有意义,而且这些人大多都有GitHub赞助页面,就放在那里。
相似文章
维护者的困境
一篇探讨开源维护者所面临挑战的博客文章,包括拉取请求积压、AI工具对代码审查的影响,以及在质量与倦怠之间取得平衡的困境。
我不再需要你的 PR
一位开源维护者解释为何现在更偏爱由 LLM 生成的代码,而非社区 PR:AI 辅助能降低风险与摩擦,将贡献价值转向反馈、缺陷报告与设计讨论。
开源中的倦怠:一个我们可以共同解决的结构性问题
对开源软件开发者倦怠现象的详细分析,基于一位心理学家的访谈和研究,识别结构性原因及潜在解决方案。
@dabit3:一个非常有趣的故事,展示了 @github 目前的状态无法有效保护开源维护者免受 AI 滥用的影响。
一个故事描述了在发布 900 美元赏金后,AI 机器人如何用垃圾评论和未经测试的 PR 淹没了一个 GitHub 仓库,迫使维护者实施如贡献者白名单和声誉机器人等变通方法,凸显了 GitHub 缺乏反机器人机制。
经验分享:构建用于处理 GitHub、Discourse 和邮件的 AI Agent(开源维护的真实用例)
作者分享了为 Seafile 构建 AI Agent 的案例研究,该 Agent 通过同步知识库并提供可操作建议,协助维护人员在 GitHub、Discourse 和邮件中分流处理支持请求。