加载失败
HashiCorp 联创 Mitchell Hashimoto（也是 Ghostty，一个终端模拟器项目的作者）发文称 GitHub 不再适合 serious work，并提到自己长期把 GitHub 当作观察 OSS 协作和维护者行为的窗口。HN 讨论围绕 GitHub 的 outages、GitHub Actions（GitHub 的 CI/CD 工作流系统）、PR、API 和搜索索引展开，很多人还拿第三方 uptime 统计和 GitHub 官方 availability 更新来对照。评论里常见的解释是 Microsoft 收购后的管理优先级变化、向 Azure（微软云基础设施）迁移、以及 Copilot、AI Credits 之类 AI 功能推进带来的压力。讨论也延伸到 GitLab、Forgejo（开源自托管 forge）、Gitea（轻量级 Git 服务）、SourceHut（偏极简的开源代码托管平台）和 Radicle（偏 P2P 的分布式代码协作项目）等替代方案，以及 self-hosted runner（自托管执行节点）和 federation / P2P 代码托管是否足够可靠。
许多评论把重点放在 GitHub 最近的可用性和稳定性下降上。大家举了 Actions 随机失败、PR 里代码不可见、合并时静默丢提交、搜索和索引延迟等例子。还有人提到官方 Status page 并不完整反映部分 outage，第三方监控把 uptime 算到约 86%。对依赖 issue、review、CI/CD 和文档协作的团队来说，这已经不是偶发故障，而是会直接打断日常工作。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
另一派认为，问题的主因是 AI 时代带来的流量和仓库数量暴涨，而不只是工程失误。评论里反复提到 vibe coding、AI slop 和越来越多的低质量仓库，甚至引用 GitHub 自己关于 10X/30X 容量的说法。有人用公开数据指出 public repo 数量短期增长很快，也有人说真正吃资源的往往是少数高活跃仓库的 PR、Actions 和搜索索引。按这个解释，故障可能是新型负载压到既有架构边界后的结果。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
不少人把 GitHub 的问题归咎于 Microsoft 收购后的产品方向变化。评论提到迁到 Azure 基础设施、UI 改成 React 后影响浏览器返回、Layoff 导致运维和系统知识流失，以及不断把 Copilot、AI Credits 等功能推到所有人面前。还有人把它类比为 Embrace, extend, and extinguish，认为微软更像是在提取现金流而不是长期打磨产品。也有人说这不是短期失误，而是数年里管理层更替、优先级从稳定转向新功能的累积后果。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14] [来源15]
也有评论反对把问题简单归结为砸钱不够。有人强调，平台在短时间内放大一个数量级时，很多故障模式会变成前所未见，重新设计架构、重写关键路径和迁移旧系统都不能按预算表直接加速。另一些人区分了 git 本身和 GitHub 周边的集中式服务，认为真正难的是 PR、Actions、搜索和自动化这些附加层，而不是分布式版本控制本身。还有人用自己做过大规模系统的经历说明，哪怕是企业级资源，也未必能把复杂迁移按期消化。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
许多回复给出的不是抱怨而是迁移清单：GitLab（尤其 self-hosted）、Forgejo、Gitea、SourceHut、Gerrit、Codeberg，甚至自建 home runner。有人说迁走后最直接的收益是不用再盯 GitHub outages，build 还可能因为专用硬件更快。也有人称 Forgejo 接近 GitHub 的 drop-in replacement，而 GitLab 虽然功能重但 CI/CD 和自托管 runners 依旧好用。还有少数人提到更激进的方案，比如 ForgeFed、ATproto、Radicle 这类带 federation 或 P2P 思路的 forge。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14] [来源15] [来源16] [来源17] [来源18]
另一组评论则解释为什么很多公司还是继续留在 GitHub。对开源项目来说，GitHub 的社区、stars、熟悉的 UI 和几乎人人都有的账号会显著降低协作门槛；对闭源公司来说，默认选项和历史包袱往往比理想架构更重要。有人指出，GitHub Actions 让很多工作流被锁进平台内部，迁移并不是简单改几个 URL，而是要连 CI、webhook、review 流程一起搬。也有人承认，就算有替代品，GitHub 仍然是最省心的公共镜像和最容易吸引贡献者的地方。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
还有一条支线在争论作者是不是太情绪化。有人直接把他的表述当成个人执念，甚至用带有心理暗示的措辞质疑他；另一些人则反驳说，这种说法是 ad hominem，完全偏离了问题本身。支持者强调，GitHub 对维护者并不只是代码仓库，而是 issue、review、讨论和文档协作的主工作台。对长期在 OSS 里做维护的人来说，平台故障打断的不只是写代码，而是整个社区工作流，所以情绪激烈并不奇怪。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
GitHub Actions: GitHub 内置的 CI/CD 工作流系统，常用于自动构建、测试和部署。
self-hosted runner: 由自己控制的机器来执行 Actions job，可减轻对 GitHub 托管执行环境的依赖。
vibe coding: 用 AI 快速生成代码的写法，常被认为会放大仓库数量和提交噪音。
AI slop: 低质量、批量化的 AI 生成内容或代码。
network effects: 因用户和生态集中而形成的平台粘性，迁移成本会越来越高。
Forgejo: 一个开源、自托管的代码托管平台，常被当作 GitHub 替代品。
Embrace, extend, and extinguish（EEE）: 对微软式策略的概括，指先兼容再扩展，最后挤压竞争对手。