Home

GitLab: 集成者

GitLab 在 IPO 的时候，有两个特点被广为讨论，一是它坚持的全员远程办公的理念和遍布全球的团队，二是它自内而外的开源策略，不仅仅是代码，也包括公司内部的战略、目标和管理手册。这两个特点在很多初创科技公司身上并不难找到，难能可贵之处在于其创办十年之后仍然始终如一的坚持。这家公司的主要用户群是软件工程师，这种乌托邦气质当然为它带来了不少加分，但这只是一种情怀或是营销技巧吗？还是它可能代表了某种新的企业运作逻辑？GitLab 公布的 S-1 文件和它在网站上公布的 Handbook 成为了我们研究它的绝佳切入点。

发展历程：从开源到集成

在 S-1 文件中，这家公司这样回顾了自己的发展历程。

这个版本和 Handbook 中交叉对比后会发现，在 2014 年之前，还有 3 年的时间线没有出现：

  1. 2011: Start of GitLab - GitLab 的 CTO Dmitriy 在乌克兰的家中完成了 GitLab 的第一次代码提交，这个住所连自来水都没有，但是 Dmitriy 认为，开发一款好用的协作开发工具更加重要。
  2. 2012: GitLab.com - GitLab 的 CEO Sid 发现了 GitLab 的优越特性，并且在 Hacker News 上发帖征询社区反馈，tHub 的对标产品。在收到大量正面回应后，Dmitriy 发布了 GitLab CI 的第一个版本。
  3. 2013: “I want to work on GitLab full time" - 越来越多的大型组织使用 GitLab 并提出更多需求，Sid 和 Dmitriy 决定全职开发 GitLab。

不难看出，这三年时间正是 GitLab 还处于一个业务时间开发的开源项目的状态。如很多开源软件一样，最早的需求来自于创始人自己的痛点，而开源的特性能够让具有相似痛点的 Sid 发现 Dmitriy 的早期工作，并在相距万里的情况下开始协作。

在 2014 年成立公司之后，GitLab 很快分拆为两个版本：社区版和企业版。前者仍然保持免费开源的策略，后者则向企业提供商业服务。这就是所谓的 Open-core Model，这一模式的特点在于既能够保持软件的开源特性，从社区中吸收更多的智慧，同时也向需要更完善服务的企业用户提供付费支持。相比而言，它早期致敬的竞争对手 GitHub 采取了闭源的策略：任何想要使用 GitHub 的企业或个人只能选择它的商业服务——这个服务可能是免费的，但除了 GitHub 自己，没有人能够修改它的代码。

在 GitLab 的发展时间线中，2016 年值得注意：它把 SCM 和 CI 两个工具整合起来。SCM 即 Source Code Management 源代码管理，而 CI 则是 Continuous Integration 持续集成，前者是软件开发阶段管理大量的代码资料的工具，而后者则是软件发布阶段的管理工具。打一个不见得恰当的比方，前者类似是原材料或者半成品的管理，而后者则是完工品的管理，如果从传统制造业的角度来看，把两部分流程整合起来，用一套工具来管理，能带来不少便利。而在 GitLab 之前，软件开发的各项流程是用不同的工具来管理的。

不得不说，这种分散的「工具链」是由开源社区自下而上的去中心化特质决定的。开源软件中最为著名的 Linux 操作系统也秉持这样的原则：除了操作系统的内核，其余的工具都是分散独立开发的，每一个工具都有多种不同选择，用户可以自行选择，而每种工具也往往专精于某一类特定需求。这种满足单一目的（single purposed）的哲学深入整个开源社区的灵魂。

GitLab 作为一家软件企业的发展历程则是不断提供集成型功能的过程。与之俱来的，则是它被越来越多的大型组织采纳，ARR（Annual Recurring Revenue）超过 10 万美元的客户数量从 2017 年的首次突破，到 2021 年已经超过了 200 家。当企业客户希望找到一家可以提供全链路软件研发运维管理的解决方案提供商的时候，GitLab 是为数不多的选择。

集大成者

我们在《复杂性战争》一文中，曾经回顾了 Oracle 的发展之路。Larry Ellison 在当时把软件公司之间的竞争称为 War on Complexity：

Ellison 从未认为这是软件和软件之间的战争，这是复杂性之间的战争。一条路线是内聚所有的复杂性，而提供给客户一个简单一致的解决方案，另一条路线则是把问题交给客户，让他们各自处理各自的外部性。

Oracle 选择了提供复杂性：在 ERP 市场获得优势之后，Oracle 继续向客户提供整合的解决方案，包含 CRM、HRM 等多种方案打造了 eBusiness Suite，并且学习 IBM 向客户提供咨询解决方案，提供一揽子服务。这套战略的执行难度极高，eBusiness Suite 内部的复杂性为 Oracle 带来了不少麻烦。但结果证明这是一套极为成功的战略，Oracle 击败了包括 IBM 和 Microsoft 在内的众多竞争对手，保持了自身在企业软件特别是数据库方面的王者地位。

后来的 Salesforce 则抓住了 SaaS 的机会，基于自身在 CRM 上的竞争优势，通过自研 + 开放平台 + 并购手段，拓展品类，向企业客户提供更多类型的集成服务。去年，企业即时通信工具 Slack 以 277 亿美元的高价被 Salesforce 并购，更显示出 Salesforce 在此类战略上的坚定绝心。

集成战略不仅仅是一种交叉销售、提高客单价的方法，更是让企业客户把更多数据资产、业务流程甚至是管理文化都沉淀下来的提升生命周期黏性的办法。

这个战略在最新一代的企业软件中仍然在持续上演。它只是有了新的外表。在 Kevin Kwok 的 Why Figma Wins 一文中，他用下面这种简单的手绘图表明了 Figma 如何在设计工具这个细分市场中逐步走向成功。

这个图本来是一张动图，包含三个阶段：

  1. Cloud-first tech：云端优先的技术，Figma 基于浏览器提供软件服务，而不是为不同 OS 开发客户端软件。
  2. Enterprise sales, cross-side network effects：从个人使用者到面向企业销售，让企业中更多部门的人开始使用 Figma，形成跨边网络效应。
  3. Plugins, communities：开放第三方插件市场，拓展产品使用功能和场景，形成开放平台。

这三个阶段中的第一个个阶段往往是赢得初段竞争的关键，在不同的时代有不同的做法，往往是当时技术领先趋势驱动的。而第二个阶段则是要加速形成规模，比拼企业的实力。到了第三个阶段，则是锁定胜局的时刻，通过开放平台策略，打开第三方生态，自此，软件功能就不完全由第一方定义，而是可以无限扩展。

这是一种「开放的闭环」的战略（这句话我最早是在王兴的饭否上读到的）。开放的要素自然容易理解，但它最终是一套闭环：第三方提交的插件需要遵循第一方定义的标准，基于兼容性创造了垄断。当赛道中出现了这样的企业的时候，我们几乎就可以预判，这个赛道的竞争要告一段落了。

开放平台往往被比喻成是生态系统。其中，「开放」和「生态」两个词都暗含着某种善意。但真实情况是，所谓「开放」，是为了竞争，所谓「生态」，实质是生存。物竞天择，适者生存，是这背后的进化论本质。任何的「开放平台」或「生态系统」，其基本策略都是 Incentivized to Compete，即激励竞争。平台策略越是接近这样的设定，生态就越活跃，企业的护城河也就越深。

因此，集成既是手段，也是目的。无论是 Oracle、Figma 还是 GitLab，都需要通过集成来赢得足够大的市场份额，而在此之后，也需要集成第三方来巩固千辛万苦取得的胜利。从闭环到开放的过程，就是平台构建的旅程。

Open Core

我们在本文开头提到，GitLab 信奉开放之道，对于企业内部的秘密极度开放，甚至把自家的战略、OKRs 和 KPIs 等核心信息都公开在 Handbook 的网站上。有趣之处在于，这个网站自身也是用 GitLab 的 DevOps 产品维护的，从版本管理到部署发布，成为 GitLabs 产品的优秀演示案例。

在这一点上，GitLab 和其它的 SaaS 企业有一点不同：它的主要用户群体是软件开发人员，GitLab 为这些人打造流程管理的工具平台。基于此，GitLab 把自己的战略飞轮以下图表示：

GitLab 把它描绘成是一个「双飞轮」。

GitLab has two flywheel strategies that reinforce each other: our open core flywheel and our development spend flywheel. In the open core flywheel, more features drive more users which in turn drive more revenue and more contributions which lead to more users. The driving force behind the flywheel is that by using a DevOps platform to replace multiple point solutions, GitLab customers can achieve cost saving and efficiency gain. Therefore, when GitLab develops more features to improve the product maturity, it becomes easier to replace point solutions and GitLab will attract more users.
GitLab 有两个相互促进的飞轮战略：我们的开放内核飞轮和我们的研发投入飞轮。 在开放的核心飞轮中，更多的功能推动了更多的用户，而更多的用户又推动了更多的收入和代码贡献，从而带来更多的用户。 飞轮背后的驱动力是，通过使用 DevOps 平台来取代多个点解决方案，GitLab 的客户可以实现成本节约和效率提升。因此，当 GitLab 开发出更多的功能来提高产品的成熟度时，取代单点解决方案就会变得更加容易，GitLab 也会吸引更多的用户。

这段话没有解释其中的 Development Spend 研发投入飞轮，我想应该 GitLab 觉得这一点比较传统，没有做单独解释，而把笔墨放在了 Open Core 开放内核飞轮上。这个飞轮就是 GitLab 的起源：由开源社区贡献驱动的内核研发。GitLab 的产品不断吸引研发人员使用，而这其中有一部分人会向内核贡献代码，从而增加或改善原有的功能。GitLab 公司既是这个开源社区的建设者，也是它的维护者，并最终提供更为专业的服务，向自己的客户收取费用。

这就像是一家为工匠打造锤子的公司，会不断的收到工匠们对锤子的修改建议，甚至有人会直接提供设计图纸、样品、模具等。这在实体产品的设计、研发和制造中是困难的，但是对于软件而言，这个方法完全可能实现。不仅仅是 GitLab，大量的 Open Core 模式的公司都遵循类似的模式。它似乎是对传统的知识产权概念的挑战：开源社区的代码贡献被用于商业化，是否在权益上有所侵犯。但它的反面是：作为公共产品的内核，是所有人共有的，正如公民广场上的小摊贩，只需要缴纳正常的税收或摊位费即可。

这两个飞轮到底是谁在主导 GitLab 产品的演进呢？根据 S-1 文件，2022 年，GitLab 共有 1350 名员工，而社区贡献者超过了 2600 名。这里应该说明的是，大部分的开源社区贡献者并不都是在写代码的人，其中相当一部分是在提建议、回答问题等（可以参考 Nadia Eghbal 的 Working in Public 一书对开源软件社区的描述）。在 GitLab 的代码仓库中，有超过 25 万词代码提交（commit），浏览最近的一些记录，大部分提交都是来自于员工。这就说明 S-1 中公布的两个数字可能有不少的重叠。尽管如此，仍然有一些热心的社区贡献者在其中穿插活跃，为社区带来外部视角。

Open Core 是一种由企业主导的社区协作模式：一方面，它把内核开放出来，赋予开源社区使用和改进的权利，另一方面，它以企业经营的方式主导了大部分产品迭代，并将其商业化，以达到持续经营的目的。社区运营和商业经营，是两种组织生产的方式（或者说是两种生产关系），它们各自有各自的节奏，Open Core 试图将两者合二为一。

GitLab vs. GitHub

GitHub 并没有选择这样的模式，虽然它成立比 GitLab 更早，最初也是基于开源的代码管理工具 Git 建立的。根据创始人 Tom Preston-Werner 的描述，他是在一个线下聚会上碰到了他的合伙人 Chris Wanstrath 而产生了开发 GitHub 的想法。

About a week earlier I’d started work on a project called Grit that allowed me to access Git repositories in an object oriented manner via Ruby code. Chris was one of only a handful of Rubyists at the time that was starting to become serious about Git. He sat down and I started showing him what I had. It wasn’t much, but it was enough to see that it had sparked something in Chris. Sensing this, I launched into my half-baked idea for some sort of website that acted as hub for coders to share their Git repositories. I even had a name: GitHub. I may be paraphrasing, but his response was along the lines of a very emphatic “I’m in. Let’s do it!”
大约一周前，我开始了一个叫 Grit 的项目的工作，它允许我通过 Ruby 代码以面向对象的方式访问 Git 仓库。Chris 是当时仅有的几个开始认真研究 Git 的 Ruby 开发者之一。他坐下来，我开始向他展示我的成果。虽然内容不多，但足以看出它在 Chris 身上激发了一些东西。有感于此，我开始了我那半生不熟的想法：建立一个网站，作为编码者分享他们的Git仓库的枢纽。我甚至想到了一个名字：GitHub。我可能是转述的，但他的反应是非常强烈的“我加入。我们开始吧！”

两个人很快就投入了工作，并在 3 个月后发布了测试版，再过 3 个月，正式版发布。GitHub 很快吸引了大量软件开发者的青睐，但这些人并没有办法直接向 GitHub 产品本身提供修改。GitHub 把代码访问和修改的权利限定在企业内部，换句话说，它选择只用了 Development Spend 研发投入这一个飞轮。

2018 年，微软宣布以 75 亿美元换股的形式收购了 GitHub，并把它作为 Azure 云服务的一部分，同时承诺其独立运营。起初，这起交易引起了开源社区的担忧，一些人认为微软并不理解如何运营一个开源社区。从今天来看，GitHub 并未选择纵向集成之路，而是横向发展成为了一个开发者社区，微软是那个集成者，GitHub 是 Azure 的一部分。

我们不能简单的判断，最初碰面的形式决定了企业模式的选择。GitLab 的合伙人们是在开源代码仓库中相遇的，这种默认远程的假定让 Open Core 几乎成为了一种必然路径。GitLab 在这条路径上逐步覆盖了 DevOps 的整个工具链，并且走完了从初创公司到 IPO 的全过程。

此刻，谁也不能判断哪一条路线的最终优势。GitLab 的快速成长也伴随着巨大的亏损。它还需要证明从 DevOps 切入能够逐步深入到软件研发和企业经营的更多环节中，需要面对 Amazon 和微软等企业云服务巨头在更高维度的集成方案竞争。

GitLab 认为，企业将可能倾向于选择多云策略来管理成本和风险，因此，更可能会选择独立专业的 DevOps 解决方案，而不是用云厂商提供的集成方案。这个假设当然有待验证，但它听上去也合理：工具和工地很可能是分离的，工地可以有很多块，但工具可以用一套。这就要考验对市场定义的精准刀法：既深又准，才能游刃有余。

鉴于 GitLab 是一家上市公司，本文不构成对它或任何公司的投资建议。实际上，也有不少人质疑它的商业模式，毕竟你可以在网站上下载一份完全免费的社区版，自己安装部署。悖论在于，越是技术能力强的公司，越可能认识到 DevOps 的需求，也越有能力自行部署。

The Diff 的 Byrne Hobart 认为，工程师时间是最为昂贵的生产要素，企业在面临竞争压力的情况下，将越来越倾向于支付 SaaS 费用来节省自己的工程师时间。

这是 GitLab 定价能力的一个组成部分：它所做的事情对客户来说既是关键任务，又是昂贵的工程师时间的替代品 ... 这并不纯粹是因为公司可以为此收取更多的费用，也是因为雇用工程师是客户的一个瓶颈。DevOps 所需的资源越少，就意味着有更多的资源可用于交付功能，所以这样外包的公司往往会发展得更快。

企业竞争归根结底是对生产效率提升的追求。福特的流水线和丰田的精益管理都是在复杂工程环境下的杰出发明。效率改进不仅仅体现在成本降低和周期缩短上，也体现在如何消除人类易犯的错误上。集成带来了协调和一致，减少了误差和浪费。

在软件工程越来越复杂的时候，参与协作的工程师越来越多，而人们自己往往就是整个系统最大的缺陷。此刻，软件工程需要自己的「流水线」，而这正是 GitLab 在自己的网站首页上放的这张图表的真实含义。

← Back to Newsletter Archive