近期，Zig 编程语言的基金会（The Zig Software Foundation）已宣布退出 GitHub，原因是其领导层认为这个代码共享平台的服务正在衰退。
这场风波始于 2025 年 4 月，当时 GitHub 用户 AlekseiNikiforovIBM 发起了一个名为“safe_sleep.sh 脚本罕见地无限期挂起”的讨论帖。GitHub 在 8 月份解决了这个问题，但并未在该讨论帖中透露，导致该帖一直保持未解决状态，直到本周一才关闭。
这段代码一直占用 100% 的 CPU 资源，并且会永远运行下去。
就在上周，Zig 软件基金会主席兼首席开发人员 Andrew Kelly 宣布，Zig 项目将迁移到非营利性 Git 托管服务 Codeberg。他给出的理由是：GitHub 不再致力于工程的卓越性。
他用来支持这一论断的证据之一，正是上述那个“safe_sleep.sh 罕见挂起”的帖子。
“最重要的是，Actions（GitHub 自动化工作流）存在不可原谅的错误，却被彻底忽视了。”Kelly 提到，“在 GitHub CEO 喊出‘要么拥抱 AI，要么走人’后，微软的那些跟班似乎心领神会，因为 GitHub Actions 开始‘随缘调度’，似乎在随机选择任务来运行。再加上其他各种 Bug 和无法手动干预的问题，导致我们的 CI 系统严重积压，甚至连主分支的提交都无法完成检测。”
Kelly 的抱怨似乎有理有据，因为讨论帖中的这个 Bug，最早可以追溯到 2022 年 2 月的一次代码更改，用户在之前的 Bug 报告中就曾指出过问题。
那次代码更改用一个名为 “safe_sleep” 的脚本替换了 Posix 系统的 “sleep” 命令，但这个脚本未能像宣传的那样工作。它本应允许 GitHub Actions runner（运行 GitHub Actions 工作流的应用）安全地暂停执行。
Zig 核心开发者 Matthew Lugg 在 4 月的 Bug 讨论帖中评论道：“从代码上看，这个‘安全休眠’脚本的 Bug 显而易见：如果进程在循环本应返回的一秒间隔内未被调度，它就会简单地永远空转下去。”
“在负载极高的 CI 机器上，这种情况很容易发生。但一旦发生后果相当严重：它会完全破坏一个 runner，直到进行手动干预。在 Zig 的 CI 运行机器上，我们观察到有多个这样的进程运行了数百小时，悄无声息地拖垮了两个 runner 服务，并持续了数周。”
这个修复方案于 2025 年 8 月 20 日合并，而它源于 2024 年 2 月提出的一个独立 Issue。但 2025 年 4 月提出的相关 Bug 报告一直开放到 2025 年 12 月 1 日才关闭。另一个 CPU 占用 Bug 至今仍未解决。
Answer.AI 和 Fast.AI 的联合创始人 Jeremy Howard 在一系列社交媒体帖子中表示，用户关于 GitHub Actions 处于糟糕状态的说法似乎是成立的。“这个 Bug 的实现方式，对于几乎任何初次看到的人来说，都非常明显：它会一直占用 100% 的 CPU 资源，并且会永远运行下去，除非任务恰好在正确的某一秒内检查时间。”
“我实在想象不出，一个正常运转的组织是如何能犯下如此多令人啼笑皆非的低级错误。”
他补充说道，去年 2 月提出的跨平台 CPU 问题修复方案，在没有经过审核的情况下被搁置了一年，并于 2025 年 3 月被 GitHub 机器人关闭，随后才被重新启用并合并。
Howard 总结道：“虽然有人可能会说这只是一个孤立事件，但我实在想象不出，一个正常运转的组织是如何能犯下如此多令人拍案叫绝的低级错误。”
GitHub 没有立即回应置评请求。
尽管 Kelly 事后为他激烈的措词道了歉，但 Zig 并非唯一公开与 GitHub 分道扬镳的软件项目。
就在上周末，Dillo 浏览器项目的创建者 Rodrigo Arias Mallo 表示，他计划从 GitHub 撤离，主要顾虑包括：对 JavaScript 的过度依赖、GitHub 随意拒绝服务的能力、可用性下降、审核工具不足，以及“过度关注 LLM 和生成式 AI，这些正在破坏开放网络（或其残存部分）”。Codeberg 方面，其付费支持会员数量自 1 月以来已翻了一番，从 600 多名增加到上周的 1,200 多名。
参考链接：
https://www.theregister.com/2025/12/02/zig_quits_github_microsoft_ai_obsession/
点击底部
阅读原文访问 InfoQ 官网，获取更多精彩内容！
