GitHub 虽有替代方案，但无真正替代品

# GitHub有替代品，但尚无完美替代方案 来源：https://lalitm.com/post/github-alternatives/ Git代码托管平台Codeberg（https://codeberg.org/）近日做出决定，禁止主要由生成式AI编写代码的项目（https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html），此举引发担忧（https://xn--gckvb8fzb.com/i-regret-migrating-to-codeberg/）并导致其他平台（https://news.ycombinator.com/item?id=49021856）（https://lobste.rs/s/ax914v/protecting_our_floss_commons_from_llms）的广泛讨论。 这个决定并不令我意外——我并非批评。Codeberg一直将自身定位为使命驱动的GitHub替代品，而非中立基础设施。[1](https://lalitm.com/post/github-alternatives/#fn:1) 真正引起我兴趣的是反应中的失望情绪。许多人似乎认为，少数可信的GitHub替代品之一竟将其自身或项目排除在外。他们曾期望Codeberg成为普适的替代方案，成为比GitHub更优的平台，成为离开GitHub后的必然之选。 在我看来，这暴露了开源领域的巨大缺口。托管Git仓库的平台很多，但能承载开源社区的平台却寥寥无几。GitHub为项目提供了统一的身份体系、使用习惯和发现路径，而尚无替代平台能在相似规模上复现这一点。 我认为答案未必是另一个中心化平台，也未必要求所有项目集中于一处。但仅靠去中心化远远不够。任何替代GitHub的方案都需要共享的社交层：贡献者已有的身份认同、理解的协作规范，以及跨网络的项目发现机制。 ## 为何不自建托管服务？# (https://lalitm.com/post/github-alternatives/#why-not-self-hosting) 每当对GitHub的不满出现时，总会有人说道："Git是去中心化的，自建代码托管平台就行了。" 我自建Gitea已多年，对此论点深有体会。自托管适合个人项目，但若想吸引陌生人贡献则并不理想。在GitHub上，大多数人已拥有账户并理解议题和拉取请求的工作方式。而在自建平台上，即使报告小错误也需要新建账户、学习平台操作并遵循我的规范。除非真正关心项目，否则很少有人愿意费此周折——我知道自己就不会。 贡献仅是问题的一半。GitHub曾真正擅长项目发现。我常因关注者标记星标而发现项目，这些领域往往是我自己不会主动搜索的。那种体验宛如围绕创造者建立的社交网络。 如今GitHub重新设计了信息流，我几乎不再访问。默认设置影响力巨大：一旦项目发现不再出现在GitHub推荐界面，它就基本从我的工作流中消失了。 ## 为何不继续使用GitHub？# (https://lalitm.com/post/github-alternatives/#why-not-github) GitHub基础体验持续恶化：加载缓慢、频繁故障、通知不可靠。GitHub自身近期承认两次重大事故"不可接受"(https://github.blog/news-insights/company-news/an-update-on-github-availability/)。 拉取请求体验同样糟糕。大型PR导航和审查极其缓慢。堆叠式PR[2](https://lalitm.com/post/github-alternatives/#fn:2)在大型软件公司内部流行超过十年，却直到近期才在GitHub上线公共预览版(https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/)，且仍存在诸多问题(https://news.ycombinator.com/item?id=49113452)(https://news.ycombinator.com/item?id=49122109)。 令我沮丧的是，GitHub大举推进AI时，核心代码托管平台却显得冷落，而Copilot无处不在。当审查界面已不堪重负时，再多的代码生成代理也于事无补。 Ghostty项目正是这种挫败感的例证。四月末Mitchell Hashimoto宣布Ghostty将离开GitHub(https://mitchellh.com/writing/ghostty-leaving-github)，因为频繁的宕机阻碍维护者正常工作： > 写下本文时，我已因GitHub Actions故障约2小时无法进行PR审查。若平台每天持续数小时阻塞工作，这里已不再是严肃工作的场所。 值得注意的是，他同时强调GitHub的价值远不止托管服务： > 对于"Git本身是分布式的"这类论点：问题不在Git，而在于我们依赖的周边基础设施：议题追踪、PR、Actions等等。 Hashimoto表示Ghostty正与多个商业及开源供应商洽谈迁移计划。这样一个知名项目不得不四处寻觅，而非转向现成的默认选择，恰恰印证了我所说的生态缺口。 ## 为何不选择现有替代方案？# (https://lalitm.com/post/github-alternatives/#why-not-the-alternatives) 值得审视各类替代方案及其现存问题： GitLab(https://about.gitlab.com/)功能完备，但商业气息浓厚，甚至超过GitHub。[3](https://lalitm.com/post/github-alternatives/#fn:3)我在帮助开发者偶然发现项目方面，其效果也不如GitHub。 SourceHut(https://sr.ht/)专注透明，与Codeberg类似秉持明确的价值观驱动。[4](https://lalitm.com/post/github-alternatives/#fn:4)其基于邮件的工作流虽经Linux内核等项目验证，但对大多数GitHub用户而言较为陌生。 Forgejo(https://forgejo.org/)的联邦项目可能最终将自托管实例连接成共享网络。该方向前景可期，但开发历时漫长，仍处于实验阶段[5](https://lalitm.com/post/github-alternatives/#fn:5)，尚未能实质性解决自托管的社交碎片化问题。 Radicle(https://radicle.xyz/)在技术上颇具创新：仓库通过点对点复制，议题和补丁与之共同存储。但其成熟度尚不足以替代GitHub支撑公共项目。例如，公共网页界面仅支持浏览仓库，贡献者需安装其CLI或桌面应用。发现漏洞的用户不应被迫安装平台软件才能提交报告。[6](https://lalitm.com/post/github-alternatives/#fn:6) 基于直觉判断，我最关注的项目是Tangled(https://tangled.org/)。我欣赏其对代码社交体验的聚焦：首页立即展示众多精彩项目，恰如早期GitHub的设计。但该项目仍处于Alpha阶段，能否发展成为真正的替代方案尚待观察。 ## 无聊的公司能填补空白吗？# (https://lalitm.com/post/github-alternatives/#could-a-boring-company-fill-the-gap) 值得注意的是，除GitLab外，*所有*竞争平台都围绕去中心化或社会使命构建。这使得它们本质上不如营利性公司"直白"。这不禁让人思考市场是否存在后者的发展空间。 或许可借鉴bunny.net(https://bunny.net/)模式而非风险投资驱动的创业公司：刻意保持"无聊"，无意成为软件开发的操作系统，也不愿围绕投资界当前热衷的技术重构编程体系。这类公司可专注于提升开源协作的愉悦度与可靠性，直接向开发者和小型组织收费，依营收支撑的速度自然增长。 待解问题是这能否成为可行的商业模式。关键难点恰是我反复强调的缺失要素：共享身份、协作规范和项目发现机制，仅当平台达到规模后才具价值。仅优化仓库托管无法解决冷启动问题。[7](https://lalitm.com/post/github-alternatives/#fn:7) 我不知由谁、抑或能否有人解决此问题。但真正的替代方案必须将社交层视为核心产品，而非仓库数量达标后自然衍生的附属功能。