GitHub 高管回应新竞争者：世界不需要一个新的 GitHub

本周，GitHub 在旧金山举行的年度 Universe '26 大会上直面了平台稳定性问题。

这家代码托管公司把主题演讲的很大一部分时间用于介绍其正在进行的投资，包括新增 400 万核 CPU 和 160PB 存储，以及对后端基础设施进行全面重构。

但在主题演讲后的新闻发布会上以及接受 The New Stack 采访时，由微软 CoreAI 执行副总裁、现任 GitHub 负责人 Jay Parikh 和 GitHub COO Kyle Daigle 组成的领导团队也回答了有关 GitHub 在这一不断变化的开发者格局中扮演何种角色的问题——以及他们如何看待因这些变化而涌现的一些竞争。

这是一个恰逢其时的问题，因为前 GitHub CEO Thomas Dohmke 在 GitHub 大会前几天刚刚推出了一个 GitHub 替代品。

当在新闻发布会上被问及 Dohmke 的初创公司 Entire——以及微软旗下投资机构 M12 对 Entire 的投资——时，Daigle 圆滑地指出，微软经常投资那些“不仅与 GitHub 竞争，也与微软整个产品体系竞争”的工具。“这是好事，不是坏事。”

Daigle 指出，GitHub 在全球范围内运营，服务超过 2.25 亿开发者，并不断迭代以更好地服务他们。

“我不认为世界需要一个新的 GitHub。”——GitHub COO Kyle Daigle

“我不认为世界需要一个新的 GitHub，”他说。“他们可能需要不同的工具。这很好，但他们需要的是 [GitHub] 为智能体时代演进，而这正是我们在做的。

“我们今天展示的 Git 层数据本身就说明了问题。”

图片来源：The New Stack

Daigle 向 The New Stack 强调了 GitHub 在整个软件开发生态系统中扮演的角色——涵盖个人开发者、大型开源项目和财富 100 强企业。

Daigle 认为，关于新的 Git forge（或更广泛地说，版本控制 forge）的讨论过于狭隘地聚焦于公司以及这些平台的经济用途。“我认为这忽略了问题的核心组成部分，”他告诉 The New Stack。

“我们从来不是唯一的 Git 托管方。我们从来不是唯一的 SCM 托管方，”Daigle 说，并指出 Perforce 以及企业多年来依赖的其他选择。他认为，GitHub 的与众不同之处在于大规模地将所有开发者汇聚在一起，而不是只关注企业或只关注开源。“我没看到有人试图去解决那个问题。他们是在解决这个问题的一部分，”他说。“有些地方他们非常有主见，并以独特的方式去做。我认为这一直都是如此。”

Daigle 的论点核心在于，构建专注于企业的工具要容易得多。至少目前，这正是 Entire 和大多数其他 Git forge 的关注点所在。

更尖锐地说，Daigle 称此刻“感觉类似于零利率时代的终结”，当时“有很多非常有才华、有趣的开发者工具，但它们都极其狭窄。”他补充道：“幸运的是，其中很多人最终加入了 GitHub——并做出了一些非常出色的工作。”

“GitHub 可能认为不需要一个新的 GitHub，但开发者显然需要。”——Entire CEO Thomas Dohmke

Entire 的回应

当 The New Stack 请 Dohmke 评论 Daigle 关于世界不需要一个新的 GitHub 的评估时，Dohmke 提供了以下声明：“GitHub 可能认为不需要一个新的 GitHub，但开发者显然需要。我们真的想把软件开发和开源的未来交到一家大型科技公司手中吗？我们正在构建 Entire，让社区的新家园开源、可扩展，并分布于全球多个区域。”

平台与产品

随着 Dohmke 的 Entire 平台以新竞争者的形式登场争夺用户，Parikh 在周三的新闻发布会上强调了 GitHub 用户社区及其所提供平台的重要性：“随着我们构建软件的方式和软件生命周期在世界范围内快速变化，社区的力量，我认为，在我们创造什么、如何分享、如何共同学习方面，比以往任何时候都更加重要。”

Parikh 在后来的 The New Stack 采访中也表达了类似观点，当被问及 GitHub 现在面临的竞争格局时，他区分了单个开发工具与支持它们的平台。

“GitHub 和微软一直都是平台公司，”他说。“外面有太多东西是产品，是的，我们有产品，我们也有平台。”

对 Parikh 来说，这意味着提供完整的开发工作流，同时让开发者选择他们使用哪些部分。或者正如 Daigle 所说，“我们会给你完整流程，或者我们会给你基础组件，我认为这是大多数公司想要的。每个人都对‘做这件事的唯一方法是什么’感兴趣，但没有人想买唯一的方法。他们想要可选性和选择权。”

智能体在哪里搞出问题

支持这些多样化的工作流，最终迫使 GitHub 重新审视团队此前关于哪些服务最可能发生故障的一些假设。

“出故障的地方并不是我们历史上预期会出故障的地方，因为智能体的行为方式与人类截然不同，”Daigle 说。“有些服务一直扩展得非常好，我们本以为在相当长一段时间内都没问题，却出现了令人意外的故障。”

来源：The New Stack

这些故障在初夏开始出现，促使 GitHub 不再把增加容量当作主要解决方案。

“这不仅仅是增加核心数量、整体横向扩展，还要审视那些需要彻底重写的核心服务，因为行为模式已经变得截然不同，”Daigle 说。

Parikh 曾在 Facebook 和 Akamai 负责基础设施扩展，他表示当前的增长率让渐进式改进变得毫无意义。

“你必须从整个系统的角度来审视它，”他说。“现在在这里或那里提升 5% 或 10%，只能撑两周或一周。”

让这一切更难的是，GitHub 必须在保持服务运行并与现有工作流兼容的同时做出这些改变。而且与此同时，流量模式也在变化，Parikh 说。

“现在的流量模式也不是静态的……我们优化了 CPU，然后突然间瓶颈会转移到别处，接着你就会想，‘哦，我以为它会出现在这里，结果它出现在了那里。’现在的好消息是，你可以分阶段推出这些改动。你测试这些东西，然后进行调整，”他说。

团队已承诺的一项重大架构变革是将 GitHub 的 Git 基础设施中的计算与存储分离。这使公司现在能够更容易地根据需求分别扩展两者。

“取决于流量是什么、一天中的什么时间、谁在使用它以及其上承载什么类型的产品，你可以独立地扩展这些东西，并针对计算工作负载和存储工作负载的变化方式进行优化，”Parikh 在新闻发布会上说。

Parikh 说，从 GitHub 自有数据中心迁移到 Azure 还提供了更多容量、地理灵活性和冗余，而现有设施无法提供这些。但他也强调，这项工作尚未完成，还包括其他改动，例如加固和扩展 GitHub Actions。

“我们无法增加容量。我们在 GitHub 一直运营的那些固定数据中心里没有那样的规模，因此迁移到能为我们提供灵活性、规模、位置、冗余、网络等一切的云基础设施对我们来说要好得多，”Parikh 对 The New Stack 说。

保持免费仓库免费

有趣的是，这些架构变革也影响了在 GitHub 上托管所有开源代码和免费仓库的经济性。

Daigle 说，将计算与存储分离应该会降低存储 Git 仓库的成本，帮助 GitHub 在开发者和他们的智能体创造更多工作时维持访问。

Daigle 说，GitHub 对其社区负有责任。突然把开发者限制在少数几个私有仓库会“破坏 GitHub 之所以为 GitHub 的整个契约”，他说。

Daigle 说，任何写代码的人，无论是写了多年还是刚刚起步，都应该在 GitHub 有一个家。“仓库不应该被藏在你的笔记本电脑里，或者[成为]朋友之间共享的 HTML 文件，”他说。“我们为此提供了一个地方。”

不过，他确实将这一承诺与提供 AI 模型的成本区分开来。他说，GitHub 无法给每个人无限的免费 token，因此不得不决定在哪些地方补贴访问。

重新思考 Git 与验证

除了 GitHub 自身的基础设施之外，Daigle 还认为 Git 本身也有改变的空间。他希望公司与社区合作改进其底层基础，并认为类似“Git 之上的 porcelain 层”可以发挥作用，他将其描述为一种简化对底层系统访问的更高层接口。

Daigle 说，GitHub 需要“在社区中确立我们的角色”，并与既有参与者和新参与者一起重新思考 Git 的一些底层基础。“在智能体变革之前，它们就有点说不通了，”他说，“而现在它们真的、真的说不通了。”

但与此同时，Daigle 对于这个智能体时代是否需要一种完全不同的版本控制系统仍持谨慎态度。

“我想在行动之前先知道我们确实需要行动，”他说。“我不认为我们已经用尽[Git]了。我只是认为我们确实需要更深入地投入。”

“你实际上需要审查它，你需要把它推送到生产环境，你需要运行其他工作流，你需要进行 AI 扫描以查找安全问题，”Parikh 在新闻发布会上说。

Daigle 预计验证——审查、测试并决定软件是否应该进入生产环境——将成为下一个瓶颈。

Daigle 预计验证——审查、测试并决定软件是否应该进入生产环境——将成为下一个瓶颈。他认为，即使 CPU 无限，也不值得在每次智能体提交后都运行每一个构建。

“如果我同时有 5 个或 10 个智能体在运行，为了智能体本身，我实际上并不想要也不需要所有这些构建，”他说。“而这需要智能体或相关人类改变行为。”

他提出的可能性包括：对本地执行的构建进行签名，并随智能体的工作一起提交；选择一组更小的相关测试；以及探索证明驱动的开发。测试、评估和实时验证的正确组合将取决于具体应用。

“如果你是汽车制造商，你不会说，‘好吧，我让我的智能体检查一下制动卡钳是否啮合，’”他说。

文章《“我不认为世界需要一个新的 GitHub”：GitHub 的领导者们对他们新竞争对手的真实看法》首发于 The New Stack。