PingCAP CTO 黄东旭：开源与基础软件创业在中国

10 月 23 日，EGO 北京分会会员、PingCAP 联合创始人兼 CTO 黄东旭作为 EGO 线上分享第二季嘉宾，与超过 400 位 EGO 会员交流了自己在开源软件和创业方面的感悟。本文根据口述内容整理。

为什么要做开源和基础软件

我是黄东旭，PingCAP 联合创始人和 CTO 。今天刚好回想起来，我拥有第一台电脑是在 1997 年的，到今年 2017 年，我编程刚好 20 年。而且今天也是 TiDB 1.0 正式版发布的日子，在这个日子分享，我觉得蛮有纪念意义的。

我是一个基础软件工程师，一直在做分布式系统和数据库相关的研发，之前我在豌豆荚期间完成了一个使用比较广的开源分布式缓存方案 Codis ，很多朋友之前也是通过 Codis 认识我的。

缘起

我最早是在豌豆荚基础软件团队维护 MySQL 集群时有了这个想法。当时豌豆荚的整体技术架构比较朴素，上层用 Codis 支撑分布式缓存，底层数据库是 MySQL 和一部分 HBase 。当时 MySQL 大概有 16 个分片，就是最传统的分库分表。当时豌豆荚还没有全职 MySQL DBA ，维护 MySQL 就由我们基础架构团队负责。

当时我们非常痛苦，每一次数据库扩容和调整都感觉要掉一层皮。主生产库不能容忍停机，同时每一个分片有自己的储备，扩容一次不仅要把主节点拆分，还同时要在业务层上做拆分；而且在业务层有很多的工作，比如说语句的所有请求必须带着 Sharding Key ，不能做 Cross-shard 的事务或者稍微复杂的查询。当时大家很希望有办法解决这些问题。

我跟另一个合伙人刘奇，现在是 PingCAP CEO ，都在豌豆荚的基础架构团队，当时就想做一个 MySQL 中间件解决这个问题。这有点像 MySQL Proxy 了。我们做了一段时间，发现做出来既没有太多的创新，也不会彻底解决问题，当时干得还挺不开心。

那段时间我们看到了 Google Spanner 的论文，觉得未来的数据库应该是这样的。我们希望能够有这样的东西，解放后端程序员，解决关系型数据库在面对海量数据高并发时的扩展性问题。

然后我们就开始做这个数据库。

蹒跚学步

我们从第一天就坚定地要走开源路线。我们研究了国外有名的开源项目是如何发展起来的，包括 MongoDB 、Kafka 、Spark ，同时我们在 Codis 项目上也积累了一些国内社区运营经验。

公司头三个月都是三五个人的状态，早期员工都是我们三个创始人的前同事和朋友，没有依赖猎头，也没有依赖第三方的中介。早期我们的目标非常简单，就是写代码。整个阶段大概持续半年，我们开源了第一个 TiDB 版本。

说起来非常好玩，第一个 TiDB 的版本是不能存数据的，只开源了 MySQL 协议处理层跟一个简单的 SQL 优化器，数据只能存储在本地，并不是一个真正的分布式的数据库。当然了，现在我们已经是完整的分布式数据库。

我觉得做开源就是这样，不是一下子把所有东西做好，而是一步一步让开发者社区看到进展，这一点非常重要。所以当时我们就决定在第一个可以 run 的版本就把整个代码开源，看看社区有什么反馈，在社区发发声音，同时开始组织线下的一些技术 meetup 聚集人气。

通过持续的分享，我们逐渐在社区积累了外部贡献者，也有了几个试用的客户，比如当时华为的一个团队对项目非常感兴趣，也投入工程师参与开发。我们慢慢积累了社区影响力，2016 年底完成 500 万美金 A 轮融资。这时候，距离公司成立一年多，公司逐渐变得比较正规，不再是“软件作坊”。

小步快跑

A 轮完成之后，我们加快人员结构调整，开始扩大工程师团队。开源有个好处就是，好的项目会让很多人快速知道，在社区有影响力，很多能力不错也一直在贡献代码的工程师对项目非常感兴趣，他们本身是我们公司很好的人才储备。

我们从社区里“招安”了一些优秀工程师，吸纳到 PingCAP 开发团队。最开始的 10 个人持续了一年左右，从 10 个工程师到 50 个工程师也用了差不多一年，这段时间正好是项目从比较粗糙变得完整精致的转折点。到现在，每个核心组件有 10 到 15 人团队负责，他们本身是社区贡献者，同时是 PingCAP 员工，全职工作就是提交代码、在社区讨论、跟社区协作制定未来的开发计划。另外有大概差不多 20 人的工程师团队主要做商业产品、商业化周边工具等。

我们在 2016 年 12 月发布了 RC1 版本，今天（ 2017 年 10 月 16 日）正式发布了 TiDB 1.0 版。现在也基本完成了美国的分公司的事情。

为什么要出海？

在中国，大家会遇到 MySQL 的扩展性问题，在美国也会遇到。所以这两个市场对于基础软件公司来说，不会像 C 端产品公司那样难以复制或者难以进军海外。基础软件领域是没有国界限制的，这是我们的优势。

开源项目怎么运营

在过去很长一段时间理，中国都没有在世界范围内的特别成功的开源项目。

我觉得这是有原因的。很多早期知名的开源项目，比如 Linux 、MySQL ，都是国外草根开发者出于个人兴趣而投入大量时间和精力做出来的；运转过程中，开发者重度参与开源项目，也都是自发和出于兴趣。我称之为开源 1.0 。

这种模式不适合中国国情。在国外，整个社会是类似于 community 为主的文化，开源社区里的协作模式跟现实生活非常像。而中国是没有类似的文化背景的。另一方面比较实际，国外工程师的时间挺多挺宽松，国内工程师和开发者很难凭兴趣爱好在业余时间重度参与非常庞大的项目。另一方面，技术能力和语言可能也是一个问题。

最近几年，开源社区构成有了非常大的变化。很多主流开源项目背后都有商业公司支持，甚至项目本身就是商业公司发起，比如 Spark 背后的 Databricks 、Hadoop 背后的 Hortonworks 和 Cloudera ，以及最近上市的 MongoDB 背后的 MongoDB 公司。这一类开源项目，我称为开源 2.0 。这时候，开源软件的发起不是纯粹的开发者个人兴趣，而是有商业公司把开源作为很好的开发模式和市场手段。

回到开源社区的运营，我觉得 OpenSource 并不是简简单单的 Source Open —— 把代码开源出来、把代码放到 GitHub 上就行了。

介绍一下我们早期是怎么做的：

• 在项目开始阶段，我们的文档比代码还要多。这个阶段需要把项目的理念和设计详细的展示给社区。- Day 1 开始国际化，最早的 TiDB 没有中文文档，所有的注释和每一个 commit 提交记录必须是英文，所有的设计文档都要放到 GitHub 上。早期使用者有问题会直接微信或者邮件联系我，我也建议他们把问题放到 GitHub。我甚至会帮早期提出 issue 的人，把中文翻译成英文。

• 珍惜每一个 contributor 。即使提交非常小的 Pull request ，可能就是改一行文档、改一个标点符号，我都会亲笔为他写一个明信片，还有赠送水杯或者T恤。没多少成本投入，贡献代码的朋友会有荣誉感。

• 严格的 Code Review 流程，摆在社区面前，通过 CI 和代码测试覆盖率量化代码质量。

开源项目怎么挣钱

这个问题是我被问过无数遍的。

每一个开源项目的挣钱路径是不一样的。代码本身一毛钱都不值。一个开源项目挣不挣钱，不取决于是否开源，而是取决于项目本身面向的市场是什么样的、面向的人是什么样的、背后的商业价值是什么样的。举个例子，比如 Docker 的挣钱路径一定是跟 MongoDB 、MySQL 和 PingCAP 不一样的。这很好理解，容器跟数据库是两个不同的类别，它本身的商业价值跟开源没关系。

有了这个前提，讲一下我们认为数据库或者存储资领域的商业模式是个怎么样的。现在主流的盈利模式大致有两种，一种是内核开源，企业版和周边商业工具收费，比如 Dashboard 、数据导入导出迁移工具、安全、审计、自动化部署的套件。

开源的数据库本身是可以随意使用的，如果在核心生产系统里面用到关键数据库，业务数据非常重要而你用的是社区版数据库，这时候很多公司要不成立 DBA 团队，要不就找商业公司购买服务。这种模式是比较传统的卖 license ，或者卖服务的模式。这种模式的大的问题在于，基本上是一锤子买卖。我卖一批 license ，后续就只能收维护费，维护费可能跟 license 不太对等。

另外一种我比较推崇的商业模式类似于订阅。比如和云厂商合作或者私有部署，你在云上可以无限制地使用我的数据库或者开源软件，你要为占用的资源付费，有点像订阅模式 —— 我每个月或者说每半年有一个 subscription 。乍看之下跟卖 license 差不多，对于创业公司来说，subscription 能保持比较健康的现金流。

我们的类似 subscription 的模式目前不限制用户环境下的使用规模。我已经订阅了，那我用 1 G 和 100 T 都是一样的价格，我可以把尽多的数据放到你的平台里面。这种模式对大的用户更加友好如果我们的维护和支持自动化程度越高，1 G 部署和 100 T 部署区别不大，而且对我们来说更能锻炼产品，对用户来说更放心的使用，不用担心用超了。如果是 license 模式，业务缩减了，购买了 10 个 license 却只用着三个，对用户来说是浪费。订阅模式是更符合时代的、新的商业的模式。

代码本身并不值钱，只有用户在使用、用它解决问题的时候，你提供的服务、你提供的价值能被用户长期认可，你的开源项目提供了什么东西能让用户有黏性，这是值钱的。

中美企业服务市场的差异

大家都基本上去默认中国的企业服务市场是并不挣钱的，但是我倒是觉得这个假设可能快过时了。

我先分析一下为什么大家觉得过去中国的企业服务市场不挣钱，或者说不是一个特别好的生意。过去，中国做企业服务的厂商基本都是软件集成商，这样的大型 IT 经销商的竞争力是做产品的整合和周边开发。简单来说，他们的商业模式是卖人，招一些工程师，快速把产品做出来满足用户需求，算是外包模式。外包模式的问题是他难以复制，或者说很难扩展。因为每一家的需求都不太一样。

中国没有 Oracle 这样的大公司，有几个原因。一是过去 20 年中国开发者整体水平不是太高，很难做出有核心技术竞争力的产品，另外就是过去中国不够尊重 IT 知识产权，盗版是一个长期问题，还有就是过去大家都喜欢自己造轮子，因为中国工程师在过去非常便宜，对于公司来说，我养一个团队、我自己去做，整个成本反而是更低的；我在外面找到软件供应商，产品质量也参差不齐，还可能涉及到跨公司跨项目协作的各种扯皮。

这就导致过去中国软件行业基本上是渠道导向、销售导向甚至关系导向的市场，并不是产品导向。这样活生生把毛利特别高的企业软件行业变成了毛利特别低的行业。

美国商业环境比中国好，法律制度非常健全，公司都比较具有契约精神，这是第一。第二就是，销售本身虽然重要，但核心还是产品。在美国，可能是一个很小的公司，如果你的产品确实满足客户需求 —— POC 阶段可能在客户那边做，测试持续时间可能会比较长，但是一旦测试通过的话，基本上事情就成了。

而且在美国，软件预算不会跟硬件绑定，为软件付费的概念是在国外是比较根深蒂固的。

不过我们观察到在，中国在发生一些变化。第一个变化是互联网公司有钱了。过去很多人都奉劝我，不要做互联网公司的生意。但是我发现，现在很多 CTO 和 CIO 都会算账，产品质量和服务都不错的情况下，自己造轮子的成本跟购买技术软件提供商的成本对比一下，很明显的购买服务是更划算的。

另一方面，也不是一下子能招到合适人选，何况工程师薪水也是水涨船高。第二个是，中国的人力成本慢慢向美国靠拢，这就给企业服务带来巨大机会。美国的企业服务市场是中国的 20 倍，中间存在巨大利差。过去中国不太接受企业服务是因为人太便宜，当人力成本上升到企业主不能忽视的级别时，购买软件服务会成为主流。这是中国的优秀企业服务公司的好机会。

而且，PingCAP 目前的付费用户大多数是互联网相关行业的公司。

如何看待云的崛起

现在中小型公司完全上云是大势所趋，称得上是“标准答案”。技术软件公司必须顺应云的时代，云化自己的产品。很多开源软件作者一直认为，公有云是开源软件最大敌人。举个例子，Oracle 从 MySQL 挣的钱，根本连亚马逊从 MySQL 上挣的钱的零头都不到。那么 AWS 给 MySQL 贡献了多少代码、投入了多少工程师维护？很少很少。有人说公有云有点像吸血鬼，一边在用开源软件，一边大把挣钱。

话虽然如此，但是云化是不可逆转的趋势。我是坚定地相信云，相信未来一切都是在云上的 —— 开源也好，闭源也好，公有也好，私有也好，IT 基础设施一定是在云上。所以要做的就是，怎么让你的开源软件来适应云，你不能说我的软件只能跑在我的专用机房或者我的专有硬件，一定要是云化的，Cloud Native 的。

眼光再放稍微长远一点，未来大家一定都把基础设施网云上迁移，但是真正有钱的企业和大企业不可能把自己绑定在一个云提供商上。他一定需要在几个公有云 Vendor 之上提供一套独立第三方的统一的数据访问接口，它不可能被一个云的私有方案绑定。这就是开源软件或者说开源公司的比较大的机会。开源软件的优势，是独立于云、独立于云提供商的解决方案，比如说我可以去用 AWS 的数据分析服务，但是我也可以去用 Spark 来做分析，用 Spark 的话，我可以平滑的迁移到 Azure 或者 GCP 上。或者，我的数据可能是跨云存储的，一来提供了更大的灵活性，二来对云服务提供商有了更大的议价能力。

比如摩根斯坦利没有选择 AWS Redshift 而是选择了 Spark —— 如果它完全绑定 AWS ，它以后就丧失了很多话语权，比如它想切换到 Google Cloud 就很难。所以跨云的数据同步和跨云的需求方面能产生很多的开源软件，而且这是开源软件独有的东西。这上面可以做很多文章。

我的观点是，需要想办法跟云做好沟通或者说保持合作关系，并不是说云就是你的敌人，或者云会把你吃掉。我觉得还是需要合作，这种合作的态度比较重要。

Q & A

你在 PingCAP 创业踩过什么坑吗？怎么解决的？

我可以分享两个坑，一个是技术上的，一个是商业上的。

第一个是技术上的坑。我们当时打算把 SQL 层写出来以后直接对接 HBase ，对外发布第一个版本，投入了我本人一两个月的精力一直在去做事情，但是后来没有什么效果。后来想想，在 HBase 上去实现第一个分布式的存储引擎，基本是无用功。我得到的启示就是，开源项目一切都要维护围绕主线目标。很多人会告诉你我需要 A 功能、我需要 B 功能，我的需求非常急迫……经常会有这样的诱惑，而且大家不好意思拒绝，这就可能导致错误地投入到并没有什么收益的方向上。好在我们看到问题后及时止损，果断转回主线方向。

第二个是商业上的坑。我跟刘奇（ PingCAP CEO ）都是码农，我们没有在国内做商业化的经验，也没做过生意。当时国内不少集成商和一些比较传统的企业来找我们，说一起合作或者搞些什么，经常有比较虚的合作。在早期没有判断得特别准确，投入了一些精力。在早期阶段精力是非常宝贵的。至少到现在为止，我们最重要的目标是技术、产品的质量和社区。比如当下能挣快钱的事情 —— 我们以前可能会妥协，现在不会了。创业公司贵在专注和快。

公司团队异地协调一直是个难题，想问一下咱们开源公司是怎么解决的？有哪些软件、工具或者方法？

我们是特别典型的异地协同公司，差不多一半工程师是分布在全球各地的。我觉得这个问题会因公司而异，PingCAP 本身的产品形态是数据库，可能跟其他公司会有不少区别。

文档协作全部采用 Google Docs

远程协作团队的沟通成本非常高的，不可能每件事情都 face to face 地沟通，甚至多说几遍也无所谓。我们的文档协作全部采用 Google Docs ，不同的人可以 comment ，还可以大家协同编辑。同时讨论结果必须得转成 Markdown 文档放到 GitHub 上，要求一切讨论都需要落地。

重度依赖 Slack

Slack 是我们所有消息的中转平台，包括项目持续集成、GitHub issue 、跟社区成员的交互信息都会汇总在 Slack 。它既是我们的聊天工具，也是公司内部的 Dashboard 。同时，我们也在用 Trello ，用于追踪客户进展和做重要的会议记录，它可以很好地跟 Slack 做整合。

以自动化和工具化替代人工操作

我们花了很多时间做持续集成、自动化测试和 code review 等东西。我们现在基本上做到了，每提交一行代码，不需要找人 code review ，不需要找人手动测试，一切环节和流程都是自动的。你提交了代码，马上就在 GitHub 上看到自动化构建的项目在 run ；测试成功还是失败，代码覆盖率是多少，一目了然。如果代码审核没有通过，那么代码合并按钮是无法显示绿色，是无法点击提交的。一切需要人工保证的流程，我们尽可能把它变成自动化和用工具实现的。