GitHub：社区上的企业软件

June 21, 2024

GitHub 在 2018 年被微软收购时引起了轩然大波。很多人并不相信微软是合适的买家。GitHub 诞生于开源软件社区，在互联网 Web 2.0 的浪潮中快速成长，而彼时的微软还是一家以出售 Windows 和 Office 著称的老牌软件公司。事到如今，微软已经通过 Cloud + AI 成功转型，GitHub 也获得了 Copilot 这样的绝佳机遇。这是一家富有理想主义色彩的公司，其早期成长与它深深植根于开发者社区密不可分。但事实证明，这场收购并没有如很多人担心的那么糟糕，相反，GitHub 并不是一家简单的依靠社区用户自然成长的公司，其企业销售策略让它从一个几百万用户的垂直平台成为了 DevOps 的事实标准，也获得了 AI 时代的入场券。

Founding Story

2007 年 10 月 18 日，在旧金山的 Zeke's Sports Bar and Grill，Tom Preston-Werner 与 Chris Wanstrath 就一个名为 Grit ^[1] 的项目以及一个用于共享 Git 代码仓库的平台的想法进行了一次对话。这次对话的结果促成了 GitHub 的诞生。Chris 于第二天晚上 10:24 首次向 GitHub 的代码库提交了代码。

Preston-Werner 回忆当天晚上的场景：

我想我当时是独自坐在摊位上，因为我刚点了一杯新鲜的 Fat Tire，需要从酒吧后部灯光昏暗的长桌上的社交活动中休息一会儿。喝了五六口的时候，Chris Wanstrath 走了进来。我现在都记不清当时我是否将 Chris 和我归类为“朋友”。我们是通过 Ruby 聚会和会议认识的，但只是偶然认识的。就像互相说“嘿，我觉得你的代码很棒”之类的话。我不知道是什么促使我这么做的，但我示意他到摊位前说“伙计，看看这个”。大约一周前，我开始从事一个名为 Grit 的项目，该项目允许我通过 Ruby 代码以面向对象的方式访问 Git 存储库。Chris 是当时为数不多的开始认真对待 Git 的 Ruby 程序员之一。他坐了下来，我开始向他展示我的东西。虽然不多，但足以看出这激发了克里斯的灵感。意识到这一点后，我开始着手实现一个尚未成熟的想法，即创建某种网站，作为程序员共享 Git 存储库的中心。我甚至想好了名字：GitHub。我可能在转述，但他的回答非常肯定：“我加入。我们开始吧！”

最初的分工是 Wanstrath 主要负责工程代码，Preston-Werner 负责 UI，并继续开发 Grit。在最初 3 个月里，两个人投入了大量的时间打造产品，每周六见面讨论重大设计决策——在那个时候他们就已经开始讨论付费订阅计划。

大约 3 个月后，GitHub 的开发已经进入了内测 beta 阶段。资深软件工程师 PJ Hyett 作为第三位联合创始人加入了 Chris Wanstrath 和 Tom Preston-Werner 的团队。Hyett 此前已经与 Wanstrath 在另一家创业公司共事，他的技能和经验使他成为这个新项目的不二人选。2008 年 4 月 10 日，GitHub 正式发布。

Tom Preston-Werner 当时还在一家创业公司 Powerset 工作，这家公司后来也卖给了微软。当时他可以从微软拿到 30 万美元的 offer，但他还是决定放弃这个高薪机会，全职加入 GitHub 的创业：

2008 年 7 月 1 日，当我得知 Powerset 刚刚被微软以约 1 亿美元收购时，我还在 Powerset 全职工作。这是一个有趣的时机。随着这次收购，我将比预想的更早面临选择。我要么签约成为微软员工，要么辞职并全职加入 GitHub。我 29 岁，是三个 GitHub 成员中年龄最大的，而且积累的债务和每月支出也相对较大。我已经习惯了六位数的生活方式。更令人困惑的是，我的妻子 Theresa 即将从哥斯达黎加的博士实地考察工作中返回。我很快就会从假想的单身汉变回已婚男人。

Preston-Werner 是创始人中最热衷表达的，他在个人网站 ^[2] 上记录了自己的成长经历，从中可以看到，他内心细腻，充满意义感和使命感。他后来担任 GitHub CEO，直到后来因为性骚扰的指控 ^[3] 而辞职。在 GitHub 和 Powerset 之前，他还创办了一家曾经在 Web 2.0 早期很有名的公司 Gravatar，是一个开放的存储个人头像的平台，后来这家公司出售 ^[4] 给了 Automattic，也就是 Wordpress 的母公司。

可以说，GitHub 的创始故事充满了 Web 2.0 时代的理想主义色彩。

Product

GitHub 的核心产品是其基于 Web 的 Git 代码仓库，通过提供用户友好的界面和附加功能来增强 Git，包括：

代码仓库：通过 Git 访问的代码存储（Repos）。
协作工具：拉取请求（Pull Requests）、问题（Issues）和代码评审。
文档：Wikis 和 Markdown 文件。
项目管理：看板风格的项目看板和自动化工作流。
安全性：依赖漏洞警报和机密扫描。

Git 是一套分布式版本控制系统，由 Linux 内核的创始人 Linus Torvalds 开发，最初是为了解决 Linux 内核开发中版本控制的需求。软件工程极为复杂，特别是对于需要多人协作的大型开源软件项目而言，开发者往往远程工作，素不相识，也没有正式的组织结构和管理流程，版本控制系统本质上就是在这样的开放协作环境下对于工作结果的认定过程，可以说是软件项目管理中的核心步骤。

Torvalds 从 Linux 内核开发项目中汲取了大量经验，Git 被设计为一个分布式、多线程的开发管理工具，其中最灵魂的设计就是对于分支（Branch）和合并（Merge）的设计，虽然不是 Git 最初发明了这个想法，但它让分支管理更加高效，有助于不同开发者并行开发，互不干扰，最终又能整合到正式发布中。

Git 于 2005 年 4 月发布第一个版本，由于 Linus Torvalds 本人和 Linux 内核项目的巨大影响力，迅速获得了开源社区的支持。2006 年，Junio C Hamano）接管了 Git 的维护工作，并继续极大地改进了其功能和性能。

GitHub 正是在这样的背景下诞生的。其前身 Grit 这样描述 ^[1]：

Grit 为您提供通过 Ruby 对 Git 存储库进行面向对象的读/写访问。主要目标是稳定性和性能。

Ruby 在 Web 2.0 早期一度非常流行，因其优雅的语言设计而聚集了很多开发者，今天为人熟知的 Twitter、Shopify 等产品最早都使用了这门编程语言。

GitHub 的产品建立在一个活跃的开源开发者社区之上，天生满足几个条件：

开源软件开发需要极强的协作性，而 Git 自身的分支管理、版本控制已经提供了良好的基础，GitHub 的成功与开源软件运动的蓬勃发展关系密切。
Web 2.0 时期，基于互联网的软件开发进入活跃期，Ruby、Python、Javascript 等编程语言爆发式增长，这些更为现代的语言具有面向对象和解释执行的特点，分享和阅读代码成为开发者社区的一种流行文化。这些语言也都带有自己的包管理功能，开发者可以通过下载、导入别人的代码包来简化自己的编程工作。
GitHub 的网页图形化界面进一步简化了 Git 的使用，特别是把「拉取」（Pull）的功能演化成一个开发者之间交流的通信协议，因而让 Git 从一个较为晦涩的命令行工具转变为一个具有社交属性的代码共享平台。

Wired 杂志这样介绍 Pull Request 功能 ^[5]：

GitHub 的一大创新是“拉取请求”。这是你在 fork 某个东西之后要做的事情——GitHub 向软件开发人员发送的电子通知，上面写着：“嘿，我正在查看你的项目，我发现了一种改进它的方法。看这里，你可以看到我做了哪些更改；按下这个按钮，这些更改将成为你项目的一部分。”拉取请求让任何人都能轻松地修复文档中的拼写错误或软件程序中的错误，或为法律文件提出新的措辞。

在此之前，没有任何一个社交媒体平台提供过类似的功能。设想：在 Instgram 上，你发布了一张照片，几天后收到一条评论说，我拍了一个更好的版本，你可以点击按钮把这张照片发布到你的相册中。这可能难以想象，因为这不符合图片分享这个场景下的社交习惯。

这就是所谓的「社交图谱」（Social Graph）概念，它是每一个社交平台最关键的概念，必须遵循人类社会一般的社交习惯，比如：亲密关系和工作关系的差异，人类要保护自身隐私和面子的需求等。这些传统随着人类社会的发展而来，也因不同的地域、年代而呈现文化差异性，但总体上是稳定的。GitHub 并非发明了新的社交图谱，但它很好的捕捉了开源软件社区中的文化：其内核是倡导开放协作，遵循绩优主义（Meritocracy），近乎于一种人人平等，拿代码来说话的乌托邦。也只有在这样的文化下，Pull Requests 这样的交互功能才有可能被社区所广泛接受。

播客 Acquired 认为，GitHub 的社交属性更近似于 LinkedIn，是很多开发者的一张社交名片。GitHub 个人页面的一个标志性设计就是用深浅不同的绿色来展示每周开发者提交代码的数量，对于很多开发者而言，这张图连同代码仓库的星标数量足以成为一份有说服力的个人简历。

GitHub 的另外一个核心功能是 Issues，可以理解为是一个代码仓库的评论区。开发者（或普通用户）可以在这里提交对代码仓库的各种问题或讨论议题。很多开源软件的 Issues 讨论非常热闹，对于开发者而言，这是一个获取用户反馈的渠道，能有效的帮助他们改进代码。

代码需要文档，GitHub 也提供了 Wiki 和 Pages 功能。它甚至于还提供了一个免费的静态页面发布功能，允许开发者在 GitHub 上构建自己的网站。Preston-Werner 在自己的个人网站上写道 ^[6]：

10 月 19 日星期日，我坐在旧金山的公寓里，喝着一杯苹果酒，头脑清醒。经过一段时间的思考，我有了一个想法。虽然我没有接受过专门的散文写作训练，但我接受过代码编写训练。如果我从软件开发的角度来写博客，会发生什么？那会是什么样子？首先，我的所有写作都将存储在 Git 存储库中。这将确保我能够尝试不同的想法，并探索各种帖子，所有这些都可以在我喜欢的编辑器和命令行中轻松完成。我可以通过简单的部署脚本或提交后挂钩发布帖子。复杂性将保持在绝对最低限度，因此静态站点比需要持续维护的动态站点更可取。我的博客需要易于定制；来自平面设计背景意味着我将始终调整网站的外观和布局。

Preston-Werner 的网站就是由 GitHub 的静态页面生成器 Jekyll 发布的，这意味着，只需要向自己代码仓库提交新的 Markdown（近似于纯文本文件）文件，GitHub 就会按照预先设定的样式自动生成新的网页。这个功能最初被认为是一种非常怪异的在互联网上发布内容的方式，但它的好处是成本低，性能高，同时还能用 Git 来记录所有内容修订的版本。除了代码之外，大量的文档也可以用这样的方式进行管理，这就为后来白宫入驻 GitHub ^[7] 创造了条件。

GitHub 在 2010 年到 2011 年间，接连面向企业和组织推出 Organizations 功能和 GitHub Enterprise，进一步加速了其增长。

GitHub 的企业版分为 Cloud 和 Server 两个版本。前者使用 GitHub 的云服务，后者允许企业进行私有部署。代码仓库是企业的核心知识资产，私有部署满足了企业保护私有数据的诉求，同时也能更贴合自身的业务流程进行定制。GitHub 企业版的直接竞争对手是 GitLab，后者基于开源软件打造，面向企业提供一整套 DevOps 解决方案。两者的核心价值定位相近，都是帮助企业节省昂贵的研发成本。关于 GitLab 的分析，可以参考之前的文章《GitLab：集成者》。

GitHub 的 AI 产品是 Copilot，它基于 OpenAI 的模型加上 GitHub 丰富的代码语料库训练而成，能够大大提升开发人员的代码效率。它同时也集成在最流行的代码编辑器 VS Code 中，把代码编辑、代码管理等功能集成到了一个界面中，增长迅速，已经超过了 130 万付费订阅用户，和 5 万名企业用户 ^[7]，ARR 已经超过 1 亿美元。

Market

GitHub 运营在软件开发和 DevOps 市场中。它是开发者、科技公司和开源项目的重要工具。GitHub 瞄准了个人开发者、初创公司和大型企业，将自己定位为版本控制、代码评审和项目管理的必要平台。随着各行各业对软件开发的重视，合作平台的需求也在不断增长。

根据 Statista 的数据，2023 年全球软件开发者估计只有 2770 万，不到全球人口的 0.5%。在美国，每年只有大约 3 万名计算机科学专业的毕业生。

除了教育，软件开发者面临的另一个限制是工作的复杂性。一个公司的技术栈可能高达 10万美元 ^[8]，并且由数十种不同的工具组成，涵盖整个软件开发生命周期。成本和复杂性都限制了新开发者的能力，他们在快速上手方面面临重大障碍。

开发人员的生产力决定了产品的构建速度。越来越多的领先科技公司，如 Uber、亚马逊、Facebook 和 Gitlab，都在寻求通过了解依赖关系、识别故障的根本原因、让新工程师加入团队以及减少收集上下文信息所花费的会议时间来跟踪和提高开发人员的生产力。

据预测 ^[9]，到 2028 年，软件开发工具市场价值将达到 7335 亿美元，主要增长驱动因素包括 (1) 对工作效率的需求，(2) 基于云的解决方案的日益增长趋势，以及 (3) 物联网 (IoT) 技术使用的增加。

软件开发工具的市场规模有可能因为 AI 代码生成工具的崛起而面临收缩的影响。由于软件代码具有很强的规则性和结构性，更容易被大语言模型学习，代码生成的模型能力越来越强，软件开发团队的规模可能会缩小，进一步降低对软件开发工具和相关项目管理工具的需求。

GitHub 进入市场的时机较早，抓住了 Web 2.0 爆发的时间点，通过对 Git 的改造，提供了一个界面更加友好的代码分享和管理平台。它拥抱开源软件社区，也很好的利用了社区中的开放分享文化，帮助自身找到了早期的 PMF。热心社区用户的参与和共享为 GitHub 的早期成长奠定了基础。

Javascript 是 Web 2.0 时代呈现爆发式增长的编程语言，这个原本用于网页开发的脚本语言随着 Web 应用快速发展而获得了越来越多的关注，但它自身也存在很多设计缺陷，并不适合大型软件项目的开发，包括 Google、Facebook 在内的大型科技公司为了推动自身生态的发展，都开始鼓励基于 Javascript 的程序框架。Node.js 的出现也让这门语言能够承担服务端开发的工作。在 Working in Public 一书 [^10] 中，作者 Nadia Eghbal 写道：

而且由于 JavaScript 必须保持跨浏览器兼容性，其官方核心库比大多数其他语言的库都要小。因此，开发人员不得不自行定制，编写自己的软件包来填补空白。因此，每个项目都趋于更小、更可抛弃，就像可以拼合在一起的乐高积木，而不是用石头雕刻的城堡。

同时期流行的 Python 等编程语言也有类似的现象出现。这是一个容易被忽视的范式迁移：代码门槛变低了，参与进来的开发者变多了，软件包如「乐高积木」一样的组合式进化替代了传统的「城堡」式大型工程，如同互联网上内容从长变短而卷入更大的用户规模，GitHub 增长的背后也有类似的趋势。

GitHub 采用了 Freemium 模式，用户可以免费创建公共代码仓库（pubic repos）——所有的代码及未来发布都要公开，这吸引了大量的开源软件项目入驻，这些项目通常拥有很多协作者，既包含贡献代码的核心开发者，也包含很多参与社区建设维护者——比如帮助开源项目管理 Pull Requests 和 Issues，或者维护文档等。Nadia Eghbal 写道：

项目越大，就越难保持项目开始时的创新。突然间，你必须考虑数百种不同的用例。一旦活跃用户超过几千人，你就会注意到帮助用户比实际处理项目花费的时间更多。人们提交各种各样的问题，其中大多数实际上不是问题，而是功能请求或疑问。

这本书以 GitHub 上的开源软件项目为例，分析了社区中复杂的协作关系是如何相互配合来完成体量惊人、结构复杂的软件开发项目。对于 GitHub 来说，这些免费的开源项目为其带来了无可比拟的影响力，如果 GitHub 能够管理这些项目，那么很有可能就能管理企业中的软件项目。而在 GitHub 上管理私有代码仓库（private repos）是需要付费的。这一方面鼓励更多人开放自己的代码仓库，另一方面也为 GitHub 建立了商业模式的雏形。

2012 年，GitHub 上的代码仓库已经超过 200 万个。2015 年底，GitHub 拥有 280 万用户和 460 万个代码仓库。其中，Facebook 拥有 102 个代码仓库，分支超过 15,000 个，而 Mozilla 拥有 687 个代码仓库。GitHub 的目标是成为最大的开源软件平台，并开始国际扩张。

2020 年 4 月，GitHub 宣布面向开放大部分的核心功能给团队开发者：

这意味着团队现在可以在一个地方共同管理他们的工作：CI/CD、项目管理、代码审查、软件包等。我们希望每个人都能在开发人员喜爱的平台上发布出色的软件。

而面向企业的功能则保持付费状态：

需要高级功能（如代码所有者）、企业功能（如 SAML）或个性化支持的团队可以升级到我们的付费计划之一。

GitHub 的模式有很强的开创性和独特性：它把社区与企业软件两个看起来风马牛不相及的产品结合到了一起，前者吸引用户加入，然后自底向上的影响和渗透，最终获得企业软件的订阅收入。这个过程其实并没有看上去的那么自然。2013 年，Erica Anderson 已销售运营总监的职位加入了 GitHub，当时 GitHub 的用户量只有几百万，2018 年（也就是微软收购的那一年），这个数字涨到了 3100 万 ^[11] 2023 年 Anderson 离开 GitHub，用户量已经超过 1 亿 ^[12]。可以说，后期的快速增长与面向企业的销售密不可分。

而在一次对 Erica Anderson 的访谈 ^[12] 中，主持人（KPCB 的 Go-to-Market 合伙人 Joubin Mirzadegan）和 Anderson 有这样一段对话：

Mirzadegan：在 GitHub 成立初期，有人在一次采访中问过您的 CEO，他说，您能否用 50 个字或更少的字说服读者开始使用 GitHub，这是采访者提出的问题。而您的 CEO 说，我认为我做不到，我也不想。我宁愿您自己尝试一下，探索一些开源或为别人的项目做贡献。GitHub 自己销售自己的水平比我要高。我认为如果您尝试一下，您会非常喜欢它……这句话非常能说明这些自下而上的公司的许多 CEO 和领导者对销售的看法，销售？产品会自己销售自己……所以 GitHub 实际上是最早采用自下而上的公司之一。当您加入时，他们是否采用自上而下的销售方式？销售是否仍然是一种耻辱？请说。

Anderson：是的，非常如此。是的，当我刚开始工作时，有少数人以混合角色从事来自企业的入站销售，他们有自己的开发人员，他们在开源个人世界中使用 GitHub，并在任何公司大加赞扬。虽然开始出现内部销售（Inbound Sale），但实际上没有自上而下的销售……我认为关键的一点是，我们可以从下往上看到，你可以看到 XYZ 公司的所有独立团队，你可以看到他们所有的口袋，就好像这些人没有互相交谈，他们都在独立使用这个产品。你需要有人去交谈并建立这些联系，将这些团队聚集在一起，而 GitHub 平台的力量就在于人们一起工作。所以我认为自下而上的数据有很大的力量，因为你可以真正看到我们所有的口袋，我们只是你能想象到的世界上最大的公司的独立团队。我们在使用 GitHub，但他们并没有一起使用它。我认为这最终是一个真正令人信服的案例，让我们这样做。让我们从上到下把它们整合在一起，我们显然可以让我们的业务更健康、更强大，但这对开发人员来说也更好。

这段对话把 bottom-up 和 top-down 两种销售方式如何结合起来讲得很清楚：销售团队的作用在于把客户组织中那些自发开始使用的散点连成网络，当然产品本身也可以展现这一点，让客户意识到一张网络在内部已经存在了，而激活它就能释放出更大的效果。Mirzadegan 提到：

在 Dropbox，组织内 3% 到 10% 的使用率是一个临界点。在 Twilio，两到三个部门使用该服务是一个临界点。

Top-down 的销售方式在转化企业客户过程中起到的关键作用（via Erica Anderson）：

是的，我认为其中一个是围绕品牌，而且与开发者相关的销售和营销仍然有很多意义。所以我认为当时有很多关于我们如何做到这一点并维护我们的品牌的讨论，这个品牌非常注重开发者。这是其中之一。我认为第二个可能是普遍缺乏理解，企业购买技术不是一个人做出的决定。有采购、法律、安全和合规团队。我认为这就是这种演变，不仅仅是某个人能够做出这个决定。如果你真的想让所有开发者（包括公司的开发者）都能使用 GitHub，那么就需要自上而下地进行，由那些精通如何做到这一点并与该规模的客户合作、能够推销愿景并与他们一起成长的人来推动。我认为这是我们开始看到的另一件事。客户的需求由支持组织或服务组织提供支持，以确保您可以帮助客户，无论他们踏上什么样的旅程。

Erica Anderson 后来加入了 Notion 担任 Chief Revenue Officer。她在 GitHub 建立的这一套企业销售能力往往被忽视，但这才是让 GitHub 脱颖而出的另一个关键要素。

Fundraising and Future Development

在被微软以 75 亿美元的股票收购之前，GitHub 进行了几轮重要的融资：

A 轮融资：2012 年由 Andreessen Horowitz 领投的 1 亿美元。
B 轮融资：2015 年由 Sequoia Capital 领投的 2.5 亿美元。

2018 年 6 月，微软以 75 亿美元收购了 GitHub，引发了褒贬不一的反应。许多用户表达了担忧，并考虑迁移到其他平台。然而，GitHub 的行业地位和功能确保了其持续的相关性和增长。

在微软收购之后，GitHub 与微软 Azure 生态系统的更深入集成，投资于人工智能和机器学习（如 GitHub CoPilot），以及扩展企业服务以推动大型组织的更广泛采用。虽然面临来自 GitLab 等竞争对手的挑战，但 GitHub 仍然保持了行业领头羊的地位，也与微软的云计算和 AI 战略高度契合，可以说是一笔成功的收购。

在被收购之后不久，几位创始人拿到了大笔的微软股票，陆续离开了 GitHub。Chris Wanstrath 创办了一家游戏发行公司，而 Tom Preston-Werner 则从事技术方向的早期投资，PJ Hyett 投身心爱的赛车运动。

Nat Friedman 一度担任 GitHub CEO 直到 2021 年。Friedman 曾经创办跨平台开发工具 Xamarin 并被微软收购。离开微软 / GitHub 后，Friedman 活跃于科技投资领域。

GitHub 在非代码方向的发展并没有如预想的那样发展迅速：它曾经试图引入诸如法律、政策甚至艺术方向的内容进入自己的社区，但这些尝试并没有充分展开。这与它较早的出售给微软有关，也可能是增长过程中企业内部资源的自然聚焦使然。代码实际上是人与机器之间的沟通语言，而在 AI 时代，这个语言界面正在快速的向自然语言靠近，代码生成是一个显然的方向，但在非代码的空间里还存在大量的可能性有待展开。

在 AI 产品，也就是 GitHub Copilot 在软件开发中的角色定位上，2022 年底加入的 CPO Inbal Shani 这样 ^[13] 看：

不，让我说得更清楚。你不能裁员。你必须让人参与其中。副驾驶（Copilot）是副驾驶，不是飞行员（Pilot）。我一直在重复这句话。我认为公司需要意识到的第二件事，也是我们最近进行的另一项开发人员体验调查，多年来，我们给单个软件开发人员增加了如此多的任务。从编写代码、编写、测试、与人互动，每周与 21 个人合作，参加会议，等待构建，深入研究遗留代码。所有这些都增加了他们需要编写代码的事实，这是他们的基本工作。因此，大多数开发人员花费不到 25% 的时间，有人说不到 20% 的时间在编写代码上。所以如果我们能给他们半个小时的时间，第一，他们可以写更多的代码。第二，他们可以休息一下，喘口气，这样我们就不会让他们精疲力竭，他们会更开心。

我认为它是一种更好的协作工具，而不是生产工具。因为现在很多时候，我们看到表达想法的挑战在于沟通。这是思想的清晰度。因此，如果我们可以利用人工智能来改善协作，你基本上在 Copilot 中画一幅画，它有助于讲述你要求开发人员做什么的故事。它缩短了很多来回的周期。那么你的意思是什么？你是指这里的按钮，还是你想要粉红色的，或者你想要那个应用程序，或者你想要那个操作系统？因此，如果 Copilot 可以帮助改善沟通，那么它很可能成为市场上最好的协作工具，尤其是在我们所在的全球世界中，我们看到沟通是参与提出想法的不同人物之间持续面临的挑战，基本上，我们看到人工智能，在我们看来，Copilot 将成为下一个自然语言对话。正是这种翻译器帮助让每个人都达成共识，因为它创造了一种通用的对话语言，就像数学曾经是那样。

Shani 很好的表述了一个从社区生长起来的开发工具如何处理工具与人的关系：Copilot 是一种沟通工具，帮助人们更好的表达自己的想法，并加速其转化为现实中可用的产品的过程。

在 AI leads a service-as-software paradigm shift 一文 ^[14] 中，Foundation Capital 提出了一个 4.6 万亿美金的机会：

全球职位薪资（销售和营销、软件工程、安全和人力资源为 2.3 万亿美元；见上表），加上
外包服务和薪资支出——包括 IT 服务和业务流程服务（2.3 万亿美元，根据 Gartner）

和这个「服务即软件」的概念比起来，GitHub 或许过于强调人在工作流中的作用，AI 能否取代这价值几万亿美元的工作机会，还是未知数，但「协作」和「生产力」的界限和市场规模将在这场变革中被重新定义。

References

← Back to Newsletter Archive