Entire挑战GitHub地位，双方激辩开发者平台未来

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

这家代码托管公司在主题演讲中花费大量时间谈论其正在进行的投资，包括增加400万核心和160拍字节存储，以及对其后端基础设施进行全面重构。

但在主题演讲后的新闻发布会和接受The New Stack采访时，GitHub的领导团队——微软CoreAI执行副总裁、现任GitHub负责人杰伊·帕里克，以及GitHub首席运营官凯尔·戴格尔——也回答了关于GitHub在这一变化中的开发者生态格局中扮演何种角色的问题，以及他们如何看待目前正在涌现出的一些竞争对手。

这个问题的时机颇为微妙，因为GitHub前CEO托马斯·多姆克就在GitHub大会召开前几天推出了一款GitHub替代产品。

当在新闻发布会上被问及多姆克的创业公司Entire，以及微软M12投资部门对Entire的投资时，戴格尔外交地表示，微软经常投资一些工具，这些工具"不仅与GitHub竞争，还与整个微软产品体系竞争。这是件好事，不是坏事"。

戴格尔指出，GitHub在全球范围内运营，服务超过2.25亿开发者，并持续迭代以更好地服务他们。

"我不认为这个世界需要一个新的GitHub。"

——GitHub首席运营官凯尔·戴格尔

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

"我们今天展示的Git层相关数据已经说明了一切。"

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

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

"我们从来不是唯一的Git托管商，也从来不是唯一的源代码管理托管商，"戴格尔说，并指出Perforce等公司多年来依赖的其他选项。他认为，GitHub的独特之处在于能够大规模地将所有开发者汇聚在一起，而不仅仅是专注于企业或开源。"我没看到有人试图去解决那个问题。他们只是在解决问题的一部分，"他说。"在某些方面，他们的观点非常鲜明，用独特的方式去做事。我认为这一直是事实。"

戴格尔的核心论点是，构建专注于企业的工具要容易得多。至少目前来看，这正是Entire和大多数其他Git平台的关注重点。

戴格尔更直接地表示，当前时刻"感觉类似于零利率时代的结束"，当时"有很多才华横溢、有趣的开发者工具，但它们的范围却极其狭窄"。他补充道："幸运的是，那些人中有很多最终加入了GitHub——并做出了一些非常出色的工作。"

"GitHub可能不认为需要一个新的GitHub，但开发者显然需要。"

——Entire首席执行官托马斯·多姆克

Entire的回应

当The New Stack请多姆克就戴格尔"世界不需要新GitHub"的评价作出回应时，多姆克给出了以下声明："GitHub可能不认为需要一个新的GitHub，但开发者显然需要。我们真的想把软件开发和开源的未来，交到一家大型科技公司手中吗？我们正在打造Entire，让社区的新家园开源、可扩展，并驻留在全球多个地区。"

平台与产品之争

随着多姆克的Entire平台以用户争夺新竞争者的形式亮相，帕里克在周三的新闻发布会上强调了GitHub用户社区及其所提供平台的重要性："随着我们构建方式和软件生命周期的快速变化，社区的力量，我认为，在我们创造、分享、共同学习方面，比以往任何时候都更为重要。"

帕里克在随后接受The New Stack采访时也表达了类似观点，在被问及GitHub目前面临的竞争格局时，他区分了个别开发工具与支撑它们的平台。

"GitHub和微软一直都是平台公司，"他说。"市场上有很多产品，没错，我们也有产品，但我们同时拥有平台。"

对帕里克而言，这意味着提供完整的开发工作流程，同时也让开发者可以选择使用哪些部分。或者正如戴格尔所说，"我们会给你完整的流程，或者给你基础组件，我认为这才是大多数公司想要的。每个人都对'唯一正确的做法是什么'感兴趣，但没人想只买'唯一的一种做法'。他们想要可选性和选择权。"

智能体打破的地方

支持这些多样化的工作流程，最终迫使GitHub团队重新审视了他们之前对哪些服务最可能出故障所做的假设。

"出故障的地方并不是我们历史上预期会出故障的地方，因为智能体的行为方式与人类截然不同，"戴格尔说。"一些我们认为扩展得很好、以为短期内不会有问题的服务，出现了意料之外的故障。"

这些故障从今年初夏开始出现，促使GitHub不再仅仅把增加容量视为主要解决方案。

"这不仅仅是增加核心数量、整体水平扩展，而是要审视那些需要彻底重写的核心服务，因为行为模式实在太不一样了，"戴格尔说。

帕里克曾在Facebook和Akamai有过扩展基础设施的经验，他表示目前的增长速度使得渐进式改进变得毫无意义。

"你必须从整体系统的角度来看待这个问题，"他说。"过去获得5%或10%的提升可以撑很久，现在可能只能撑一两周。"

让这一切变得更加困难的是，GitHub必须在保持服务正常运行并与现有工作流程兼容的同时进行这些变更。而同时，流量模式也在变化，帕里克表示。

"目前流量模式也并不是静态的……我们优化了CPU，突然瓶颈又转移到了别的地方，然后你会想，'我以为瓶颈会出现在这里，结果却出现在那里。'好消息是，现在你可以采用分阶段发布的方式。你先测试这些变更，然后再调整，"他说。

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

"根据流量情况、一天中的时段、使用者是谁以及其上运行的产品类型，你可以独立扩展这些部分，并针对计算工作负载和存储工作负载的变化分别进行优化，"帕里克在新闻发布会上说。

帕里克表示，从GitHub自有数据中心迁移到Azure也提供了更多容量、地理灵活性和冗余能力，这是现有设施无法提供的。但他也强调，这项工作尚未完成，还包括对GitHub Actions进行进一步加固和扩展等额外变更。

"我们无法再增加容量了。在GitHub一直运营的那些固定数据中心里，我们没有那样的规模，所以迁移到云基础设施，能为我们带来灵活性、规模、地理位置选择、冗余、网络等各方面的优势，这对我们来说要好得多，"帕里克告诉The New Stack。

让免费仓库继续保持免费

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

戴格尔表示，将计算与存储分离，应该能降低存储Git仓库的成本，帮助GitHub在开发者及其智能体创造越来越多工作内容的情况下，继续维持访问权限。

戴格尔表示，GitHub对其社区负有责任。突然将开发者限制为仅有少数几个私有仓库，"这会打破GitHub存在的全部契约"，他说。

戴格尔表示，无论是写代码多年的老手，还是刚刚起步的新人，都应该在GitHub上拥有一个家。"一个仓库不应该被隐藏在你的笔记本电脑里，或者[成为]朋友之间共享的一个HTML文件，"他说。"我们有一个地方可以容纳这些内容。"

不过，他也区分了这一承诺与提供AI模型的成本之间的不同。他表示，GitHub无法为所有人提供无限量的免费Token，公司必须决定在哪些方面提供补贴访问。

重新思考Git与验证机制

除了GitHub自身的基础设施之外，戴格尔还看到了改变Git本身的空间。他希望公司能与社区合作完善其底层机制，并认为类似"在Git之上构建一个瓷层"的东西有其存在价值，他将其描述为一种简化底层系统访问的更高层接口。

戴格尔表示，GitHub需要"在社区中明确自身角色"，并与现有及新兴参与者合作，重新思考Git底层机制的一些问题。"这些机制在智能体变革之前就有点说不通了，"他说，"而现在则真的、真的说不通了。"

但同时，戴格尔对于这个智能体时代是否需要一套全新的版本控制系统，仍持谨慎态度。

"在我们行动之前，我想先确认我们确实需要行动，"他说。"我不认为我们已经用完了[Git]的潜力。我只是认为我们确实需要更加投入。"

"你实际上需要审查它，需要把它推送到生产环境，需要运行其他工作流，需要做AI安全扫描，"帕里克在新闻发布会上说。

戴格尔预计，验证——审查、测试并决定软件是否应该投入生产——将成为下一个瓶颈。

戴格尔预计，验证——审查、测试并决定软件是否应该投入生产——将成为下一个瓶颈。他认为，即使拥有无限的CPU资源，在每次智能体提交后都运行完整构建也并不可取。

"如果我同时运行5到10个智能体，我实际上并不想要，也不需要为了智能体本身而进行所有那些构建，"他说。"这需要智能体或相关人员改变行为方式。"

他提出的一些可能方案包括：对本地执行的构建进行签名，并随智能体的工作一并提交；挑选一组更小的相关测试；以及探索基于证明的开发方式。测试、评估与实时验证之间的正确组合，将取决于具体应用场景。

"如果你是一家汽车制造商，你不会说，'好吧，我让我的智能体去检查刹车卡钳是否已经啮合就行了'，"他说。