GitHub 与软件之罪

原文 ↗ Hacker News 讨论 ↗

替代方案与镜像策略

  • 许多人建议通过多个 pushurl 条目将仓库镜像到多个 forge（GitHub、GitLab、Codeberg 等），这也是一些人第一次了解到的做法。
  • 也有人提出去中心化或新兴方案：基于 Forgejo 的托管、Gitea、sr.ht、tangled.org、radicle.dev、基于 Nostr 的 git，甚至是在 VPN tailnet 上运行一个裸仓库 VPS/Mac mini。

Issue、PR 与项目元数据锁定

  • 几位评论者认为，真正的锁定并不在于 git 托管本身，而在于周边生态：issue、PR、wiki、讨论、CI/CD 以及历史上下文。
  • 迁移代码很容易；迁移工作流、集成和元数据则被描述为困难且常常是专有的。
  • 有人主张将工具拆分开来（例如 YouTrack/Jira、Gerrit、独立 wiki、聊天），以获得灵活性；而另一些人则把这看作搜索和复杂性噩梦，更愿意把一切放在一个地方。

自托管的取舍

  • 一些人表示，在廉价服务器或 NAS 设备上自托管 Forgejo/Gitea 非常直接，而且维护成本低。
  • 另一些人则形容自托管 GitLab 很笨重（镜像很大、资源占用高），并且带来安全与运维负担。
  • 也有人预见会“回归自托管”，但指出大多数人并不想为自己的 forge 付费或自行运维。

中心化、网络效应与星标

  • 强大的网络效应被认为是 GitHub 即便有可信替代品仍然保持主导地位的主要原因。
  • GitHub stars 被视为项目合法性的一种强大“货币”，并有人声称它们可以买来，因此扭曲了采用情况。
  • 这种 star 经济被视为锁定的关键来源；把星标导入到别处并不能解决持续累积的问题。

可靠性、性能与 AI 重点

  • 评论者指出 GitHub 频繁宕机，并引用变更日志数据：很多条目是“Copilot/agent”，而没有任何标注为“performance/reliability”的条目。
  • 该 UI 被批评为臃肿且重度依赖 JavaScript；有一条分析列出了即使在简单页面上也会加载数百个 JS 文件，其中包括与 Copilot 相关的 bundle。
  • 也有人表示 GitHub 对他们来说总体上“就是能用”，只有很少真正造成影响的宕机。

关于根本原因与文章语气的争论

  • 一方将问题归咎于 Microsoft/GitHub 把 AI 功能优先于稳定性，以及长达十年的技术债。
  • 另一方则把近期的痛点归因于 AI 编程工具带来的自动化活动突然激增，认为没有哪个团队能足够快地扩容。
  • 有些人觉得原文过于负面或带有意识形态色彩；也有人认为，考虑到企业使用场景和 SLA，这种批评是合理的。