GitHub‘失宠’？开发者纷纷逃离，Zig、Dillo等项目迁移背后

时间回溯到2018年，微软斥资75亿美元将GitHub收入囊中，彼时众多开发者忧心忡忡，唯恐这个开源代码协作平台落入科技巨头之手后，自由会受到限制，甚至有人放出狠话要放弃GitHub。然而，多年时光流转，微软大体上维护了GitHub的开放本质，使得大多数开发者渐渐放下心来。

不过，今年8月风云再起，GitHub首席执行官Thomas Dohmke宣告离职，且GitHub决定不再设置CEO一职，直接由微软AI团队接管，此举再度引发外界对平台未来走向的聚焦。

在此背景下，一股隐秘的“迁移浪潮”悄然涌动：越来越多的开发者着手将开源项目从GitHub转移至其他平台，这其中不仅有轻量级浏览器、游戏模拟器等项目，还包括诸如Zig这般知名的编程语言。

众人不禁好奇：GitHub究竟是哪里触怒了开发者，抑或是开发者自身的问题？

Zig核心开发者直言：GitHub的优先级与工程文化早已“变质”

在此次迁移潮中，Zig编程语言的体量堪称最大，波及范围也最广。

Zig是一门尚在开发中的原生编译型编程语言，然而它已被若干知名项目所采纳，例如Bun JavaScript构建工具。截止目前，它在GitHub上已收获42.5k颗星以及3.1k的复刻数。

前不久，Zig的主要开发者Andrew Kelley在官方社区网站发布了一篇题为《从GitHub迁移到Codeberg》的文章，宣告Zig项目将移师Codeberg——一家总部位于德国柏林的非营利性Git托管机构，堪称GitHub的替代者。

Kelley在公告中坦率表示：“自十年前执行git init以来，Zig的代码始终托管于GitHub之上。但遗憾的是，当GitHub被微软收购之时，倒计时便已启动。我曾在心中默念：‘请给我5年，别让一切化为乌有。’如今，七年已过，我们不过是靠着借来的时间勉力支撑。”

他列举了诸多迁移缘由，核心在于GitHub的工程文化和服务质量已然蜕变。

Kelley指出，昔日铸就GitHub辉煌的工程实力，如今已不复存在。其优先级与工程文化均已“腐朽”，用户们唯有忍受一个臃肿不堪、Bug频出的JavaScript框架，官方还美其名曰“进步”。往日流畅的功能，现今变得迟缓，诸多特性甚至彻底失效。

其中，GitHub Actions的不稳定性尤为突出。在Kelley看来，Actions作为持续集成与持续交付的关键功能，却完全遭到GitHub内部的漠视，任务运行状态宛若随机触发。

他说道：“GitHub CEO曾扬言‘接受AI或者滚蛋’，微软似乎全盘采纳。Actions开始肆意调度，作业随机执行，加之其他漏洞与无法人工干预，导致我们的CI系统严重拥堵，连master分支的提交都无法校验。”

因此，Kelley表示：“与其将捐款资金用于购置更多CI硬件以应对这崩塌的基础设施，我们决定索性更换一个Git托管服务商。”

此外，Kelley对GitHub过度拥抱AI的倾向持反对立场，毕竟这与Zig项目禁止在issue、PR或评论中使用大语言模型（LLM）的政策相抵触。他提到，多次目睹有人违反该政策，而这种情况至少部分源于GitHub持续推广“用Copilot提交Issue”的功能。

甘愿牺牲收入

在迁移过程中，让Kelley略感忧虑的是GitHub Sponsors。这项功能曾是Zig早期募资成功的关键，至今仍占据项目收入的相当比重。2024年，GitHub Sponsors为Zig软件基金会贡献了逾17万美元，是其最大的收入来源。

对此，Kelley特别感谢前GitHub开源项目产品经理、亦是GitHub Sponsors功能的缔造者Devon Zuegel的贡献：“她如天使般降临，使GitHub成为数千开发者稳定的收入来源。在她的引领下，GitHub Sponsors的未来曾一片光明，然而她也选择了去追寻更大的机遇。自她离去后，这一产品同样遭到忽视，并开始滑坡。”

“我们认为这是一种潜在风险，”Kelley同时呼吁赞助者转向其他渠道捐助，例如同为非营利组织的Every.org。

目前，Zig的GitHub仓库已设为只读，主仓库的规范origin/master分支迁移至Codeberg（https://codeberg.org/ziglang/zig.git）。

Kelley采取的迁移策略亦相对简洁：为规避GitHub激进的供应商锁定，他保留现有Issue不予迁移，但在Codeberg上从30000开始编号，以保持序号清晰。

Kelley表示：“请将GitHub上尚未关闭的Issue视为按需复制，无需全部迁移，除非你需要编辑或补充评论。我们仍会关注已开放的Pull Request和Issue，请放心。”

总体而言，Codeberg目前托管着逾32万个项目，采用可自托管的开源软件Forgejo。使用Codeberg免费，但仅限于开源项目；其服务条款仅在有限情形下允许私有仓库，例如“为FLOSS项目所必需的内容，如存放密钥、团队内部讨论，或暂时隐匿尚未准备公开的项目”。相较之下，GitHub即便在免费账户下也允许商业用途的私有仓库。

开源浏览器开发者：“GitHub已非理想之选”

无独有偶。除了Zig之外，一款极简轻量级浏览器Dillo的开发者Rodrigo Arias Mallo亦加入了从GitHub迁移的行列。他期望为Dillo寻得一个更友好、能够解决现有问题的新家园。

最初，Dillo的源码和网站被上传至GitHub，但Rodrigo如今认为，这已不再是理想之选。

Rodrigo Arias Mallo坦言，GitHub确实在存储Dillo的各类仓库、运行多平台（如Windows、macOS、部分BSD）的CI任务方面助益良多，“因为我手头没有这些平台的机器”。

然而，随着时间推移，GitHub这一平台暴露出的问题日益增多，已不适合作为Dillo的主要开发平台，例如：

1. 前端不友好：GitHub的网页在禁用JavaScript的情况下几乎形同虚设，这让采用C++、C、HTML、CSS编写的Dillo浏览器几乎无法浏览issue、pull request、源代码或CI日志，而这些本质上不过是普通的HTML内容。昔日GitHub尚能优雅降级，如今却已不再。同时，页面资源需求高昂，而渲染的内容大多仅为静态文本。
2. 单点控制风险：Rodrigo表示，“GitHub由单一实体操控，它随时可能单方面封禁我们的仓库或账号。如此我们甚至无法在原链接上告知社区发生了什么。若无完整的本地备份，这将导致数据丢失。”
3. 使用体验下降：在使用体验方面，GitHub亦日益迟缓，影响开发流程。同时它要求始终维持高速网络连接，而Rodrigo并非总能做到。此外，GitHub强调“推模式”——只要项目有新动态，你就会收到通知。Rodrigo称，自己并不青睐这种方式，更倾向于“拉模式”：仅当自己主动查看时才获取更新。这也使他能更轻松地离线工作。可惜如今许多替代平台也开始效仿GitHub的推模式。
4. 社区管理不足：从社区管理视角看，它缺乏充足的用户管理工具，尤其在非技术用户数量远超开发者的项目中。当开发者正在讨论的issue被大量从未贡献过项目的用户评论刷屏时，往往弊大于利，长久下来会令开发者精疲力竭。
5. 过度拥抱 AI：GitHub正紧跟大语言模型（LLM）和生成式AI这股潮流，但这趋势正在摧毁开放网络（残存的部分）。对Rodrigo而言，影响直接可见：许多网站为防止LLM抓取导致过载，而设置了JavaScript墙甚至浏览器指纹识别，这也阻挡了Dillo用户。Rodrigo称，自己不愿再为这种趋势推波助澜。“虽然把Dillo迁走并不会阻止GitHub抓取我们的代码，但至少我不会继续主动助力。”

最终，在考察替代平台之后，Rodrigo决定自行托管Dillo，将重要数据迁移至Git仓库，并在多个平台建立镜像。他购得了dillo-browser.org域名，租用了一台小型VPS，网站目前可通过https://dillo-browser.org/访问。

为了能在Dillo浏览器中查看仓库，他选用了轻量级Git前端cgit，并对CSS进行了调整。漏洞追踪系统则采用自己开发的C语言工具buggy，解析Markdown文件生成静态HTML页面，确保数据安全且可离线编辑。相关页面可通过https://bug.dillo-browser.org/访问。邮件列表归档由三个独立外部服务保存，并计划进一步备份。关键数据现已置于Git仓库中，可镜像至任意代码托管平台，以降低单点故障风险。

Rodrigo表示，迁移涉及多项变动，需要时间稳定，GitHub仓库在迁移期间仍会更新，并最终将归档，但不删除任何commit或旧版发布包。他对自托管的成果感到满意：“我们以相对低廉的成本和极小的能耗搭建了一个完全独立的项目基地，至少在最糟糕的情况下可以维持三年。”

“将我的代码迁至Codeberg，是对GitHub的一种抗议”

与此同时，一位名为Eldred Habert的开发者亦将自己的gb-bootroms开源项目代码仓库从GitHub迁移至Codeberg，他还完整地分享了自己的迁移经验。

对于做出这一决定的原因，Eldred Habert写道：

这是因为GitHub正愈发积极地推动AI解决方案，而我并不同意其带来的伦理与生态后果；加之它与Elon Musk的合作（如今支持Grok）以及其他一些缘由。

我仅仅是不同意那个平台的政策，因此想要退出，同时也算是一种抗议。而且我也决定言行一致：我现在也在捐助Codeberg，因为他们并非混蛋，并且确实在努力做正确的事情，所以他们值得支持。

尽管我希望能神奇地“一键删除一切且不出错”，但现实并不允许。那些原本托管在GitHub上的复刻仓库必须保留，以免PR崩溃（不过我已删除了过时的复刻）；同时，网上还有很多链接指向我的各类仓库。因此，我选择在迁移后的仓库里放置一个提示，说明它们已迁移。

网友热议

社区对Kelley的迁移决定反应各异。确实有开发者对GitHub表示不满，主要是界面性能下滑与AI功能“泛滥”。

然而，也有人认为，这不过是早期敏感项目的个体抉择。

另有网友评论道：

• 不同的开发者有着各自偏好的工作与协作方式。我怀疑开源社区会集中于某一个单一的解决方案上。我认为我们正处于一个“再去中心化”的阶段，开发者会将他们的项目迁移至能够满足个人或团队在控制权、托管管辖权、企业或社区所有权、工作流程以及正常运行时间等方面需求的平台。这是因为源码托管平台之间的竞争正日趋激烈。不同的细分需求能够通过各自偏好的平台得到满足，这本身是件好事，尽管对于那些希望在不太知名的平台上提交补丁的开发者而言，可能会稍显不便。
• 我们正处在“离散化阶段”；类似的公告接连不断，每条都指向不同的GitHub替代方案。我猜测，再过数月，各个社区可能会汇聚到一个占据主导地位的平台。我很好奇，这个平台会是现有的某一个，还是全新亮相。也许会有某个知名公司或个人推出新平台，营销得力，然后一统天下。

事实上，随着微软加深对GitHub的AI掌控，开发者对平台未来的信任正面临新的考验。你认为GitHub是否仍值得信赖？这些迁移潮会加速，抑或只是阶段性波动？

参考：

https://dillo-browser.org/news/migration-from-github/

https://eldred.fr/blog/forge-migration/

https://ziglang.org/news/migrating-from-github-to-codeberg/

https://news.ycombinator.com/item?id=46096800