评估新的软件代码托管平台

原文 ↗ Hacker News 讨论 ↗

开发者在权衡 GitHub 替代方案时，正围绕便利性、控制权，以及 AI 训练、开源核心许可和中心化等问题上的理念展开取舍。评论者将主流代码托管平台（GitHub、GitLab）与自托管选项（Gitea/Forgejo、SourceHut、OneDev、Radicle 以及其他 Web3 风格平台）进行比较，强调 CI 工具、维护负担、联邦化努力和社区建设方式的差异。许多人认为，把代码镜像到 GitHub 以便发现，同时把主仓库托管在别处，是一种务实的折中，即便他们也批评各个平台不透明的政策、日益增长的臃肿以及带有鲜明立场的治理方式。

软件代码托管平台格局与新选项

  • 除了主要的平台（GitHub、GitLab、SourceHut、Gitea/Forgejo、Codeberg、Bitbucket）之外，评论者还提到了一些更新或更小众的选择：
    • Radicle、protocol.land、Gitopia（都在不同程度上带有 Web3/加密货币方面的特征）。
    • Pierre，面向产品导向工作流。
    • OneDev、Ayllu、Fossil、Gitolite/GitWeb、darcs、Pijul。
  • 有些人认为 Radicle 和类似项目确实“新颖且令人兴奋”；也有人对 Web3/加密货币关联持谨慎态度。

自托管 vs SaaS

  • 许多人正在转向自托管的 Gitea/Forgejo、GitLab、darcs 等，尤其是用于协作较少的个人项目。
  • GitLab 被认为功能丰富，但很重且维护成本高；体验从“痛苦的怪兽”到“通过基于 cron 的升级稳定可靠”不等。
  • Gitea/Forgejo 因其简洁性受到称赞；内置 CI 和 Actions 正在逐渐成熟。
  • 一些人正在尝试小型独立托管服务商和“小而美的互联网”理念。

CI 和 YAML 工作流

  • 关于 CI 中“复杂 YAML”的争论：
    • 有人认为所有现代 CI（GitHub Actions、GitLab CI、SourceHut、Drone）本质上都使用类似的 YAML，因此批评一个却接受另一个并不一致。
    • 建议的最佳实践是：让 YAML 保持精简，并在仓库内调用脚本，以便 CI 能在本地可复现。

电子邮件 vs Web 工作流（SourceHut、社区）

  • 基于电子邮件的工作流立场两极分化：
    • 支持者认为它们很简单，真正的问题在于工具本身。
    • 批评者认为它们过时、会让“21 世纪”的贡献者望而却步，而且不利于构建更广泛的社区。
  • 关于 SourceHut 的担忧：
    • 有人认为它敌视化名；但也有人澄清它要求的是稳定的电子邮件地址，而不是法定姓名。
    • 禁止大多数加密货币项目的政策引发了对平台“自由度”的质疑，但也有人欣赏其明确的价值观和人工审核。

AI、Copilot 与代码隐私

  • 对“AI 驱动”的代码托管平台训练其托管代码，尤其是 GPL/FOSS 代码，存在强烈担忧。
  • 有人认为 LLM 和 Copilot 只是工具且可选；另一些人则希望自己的代码完全无法被 AI 访问，把这类偏好比作更喜欢“厨师制作的”而非工业化食品。
  • 有人指出，把自托管仓库镜像到 GitHub 以便被发现，同时又反对 Copilot，在意识形态上是自相矛盾的。

去中心化、联邦化与发现

  • 人们对以下方向感兴趣：
    • ActivityPub/ForgeFed：在无需在每个平台都注册账号的情况下，实现跨代码托管平台的问题/PR。
    • 联邦式搜索和可选择加入的发现机制，而不是由 GitHub 维持中心化主导地位。
  • 几个人指出，如果不在 GitHub 上，很难构建社区，但他们仍希望把“发现”与“托管”解耦。

UX、政策与“劣化”

  • 有人抱怨 GitHub 基于 React 的界面比以前更慢、更卡顿。
  • 担心代码托管平台为了追逐模糊的 AI 趋势而出现“劣化”。
  • 一些人认为博文作者的标准和语气前后不一致，或者过于尖刻；另一些人则为带有强烈个人观点的写作辩护，认为它们仍然有价值。