实录 | 黄东旭：开源与基础软件创业在中国

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 轮融资。这时候，距离公司成立一年多，公司逐渐变得比较正规，再也不是“软件做坊”。

小步快跑

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

咱们从社区里“招安”了一些优秀工程师，吸纳到 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

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

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

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

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

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

咱们是特别典型的异地协同公司，差很少一半工程师是分布在全球各地的。我以为这个问题会因公司而异，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 ；测试成功仍是失败，代码覆盖率是多少，一目了然。若是代码审核没有经过，那么代码合并按钮是没法显示绿色，是没法点击提交的。一切须要人工保证的流程，咱们尽量把它变成自动化和用工具实现的。