过去几个月，我在 GitHub 上从事开源 AI 项目的工作遇到了生存危机，特别是因为对 AI 抵制的呼声越来越强烈，同时 AI 行业发展速度特快，让我感觉跟不上节奏了。那段时间，我暂停了自己的项目，我认为这样做完全没问题。

我最新的一个开源项目是 simpleaichat，它是一个用来接入 ChatGPT 的 Python 包，在 GitHub 已经获得 3000 个 Star。这个项目功能有限，依赖性小，就是为了让你能够在暂停开发的时候，代码不会出问题。

当我状态好转，恢复我的开源工作后，我查看了 simpleaichat 的 GitHub 问题列表。发现有人提了一个问题：“这个项目被放弃了吗？” 接着另一个 GitHub 用户跟帖问：“我也想知道答案。”

这让我感到惊慌，我急忙检查是否出现了新的重大问题或依赖问题，但事实上并没有。

两天后，又有人提出了一个问题：“这个包还在持续开发中吗？”

坦白的说，这种做法绝对是在施压，且表现得非常无礼。

我从未见过任何讨论或文章，探讨询问一个开源项目是否停止维护是否恰当。发布开源软件是否意味着你有隐性的契约去积极维护它？如果你在 GitHub 上获得了一定数量的 Star，或者通过 GitHub 赞助/Patreon 寻求资金支持，你是否有义务提供免费支持？毕竟，大多数宽松的开源代码许可证，如 MIT 许可证，都包含了类似 “软件是以‘现状’提供的，不附带任何种类的保证” 的条款。

遗憾的是，simpleaichat 并不是我遇到此类投诉的第一个开源项目。大约十年前我在 GitHub 上发布的 “Big List of Naughty Strings”，用于跟踪对抗性用户输入文本字符串，实际上这只是一个拥有 45k GitHub Star 的 txt 文件。它永远不会有依赖性问题，而且添加不针对特定字符串问题的条目可能会让列表比现在更加混乱，因此我对接受每个拉取请求都特别谨慎。尽管如此，人们还是感到愤怒。

有些人似乎认为像 “Inbox Zero” 一样，GitHub 上的 “Issue-zero” 或 “pull request-zero” 是一个目标，但由于职业生活的现实，这在实际中是不可行的。每个稍具规模的开源项目都会有 issue/PR 队列，这就需要进行优先级分配：不是所有的问题和 PR 都同等重要，筛选这些队列需要时间并且精心处理。作为维护者，我反复以艰难的方式处理这些问题，因为接受一个误导性的 PR 会产生技术债务，并且需要付出更多的努力来解决。

我理解当你发现一个很酷的 GitHub 项目已经很久没有更新时的失望。我经常遇到这种情况。如果代码仍然有效，那特别好，我会很高兴。但如果不是，我就会寻找其他解决方案，或将其视为一个有趣的新挑战，按照自己的需求修改它。这就是开源的魅力！如果有一个不活跃的开源项目对你的商业项目很重要，那么提供一个咨询合约或悬赏增加所需功能是一个很好的解决办法。

开源的一个伟大之处在于，如果一个有宽松许可证的开源项目变得不活跃，可以很容易地进行 Fork。有时，Fork 项目甚至可能比原始项目更好，这对所有人来说都是好事！但根据我的经验，这通常被视为一种威胁。正是维护者的过错，为他们创造了 Fork 的理由，导致了开发社区的分裂。

AI 行业独特的一点是，它确实在快速发展和演变，以至于开发期望发生了变化。最近受益于 ChatGPT 热潮的 LangChain、LlamaIndex 和 AutoGPT 等项目，创造了一种错觉，即开源 AI 项目必须不断发布新内容。不同的是，这些项目由将其作为全职工作的人维护，并且现在由大量风险投资支持的公司管理。

持续为一个开源项目提供支持的压力已成为我继续开源工作的最大障碍。就我个人而言，我已经停止发布有趣的一次性项目和 AI 模型，因为我可能没有足够的精力来处理项目依赖出问题多年后不可避免的 “嗨，这个坏了，请修复，谢谢” 这样的私信。如果我能通过全职开展我的开源项目赚取与我作为数据科学家相当的薪水，那么我会很乐意这么做。但现实是，如今要实现这一点，似乎只能像那些 AI 初创公司一样筹集风险资本。

询问一个开源项目是否已经死亡的最好结果是你会惹恼维护者并延迟开发。最糟糕的结果是你让维护者重新考虑是否值得继续从事开源项目。