15 年开源路，从大厂搬砖到创业挖坑
- 2023-09-12 09:10:00
- Bytebase-陈天舟 原创
- 1799
正好借着端午节的时间，也更完整地回顾一下自己职业生涯 15 年来和开源结缘的经历。
邂逅 Cappuccino
08 年参加工作后，第一个投入精力的开源项目是 Objective-J 和 Cappuccino 框架，因为我的第一份工作是 Mac 应用开发，使用的是 Objective-C + Cocoa 框架。Objective-J 和 Cappuccino 是 Web 版的 Objective-C，Cocoa。这个对于我这样一个不想再单独学习 JS, CSS 这些，但又想开发 Web 应用的人来说很有吸引力。尤其是项目背后的公司 280 North 还专门做了一个网页版 PPT 软件 280slides.com 来展示他们这套方案的能力。
280 North 这家公司的名字取自 280 公路，它是连接硅谷核心地带和旧金山的两条高速公路之一，另一条是 101。但因为 280 沿途风景优美，所以大家更喜欢走 280。
去瞄了眼 GitHub 上 Cappuccino 的仓库，居然最近还有活跃。
集成 libcurl
工作中第一次深度接触的开源项目是 cURL，更具体的说是它的库 libcurl。因为当时要实现一个通过脚本去调用 Web 服务的能力，而因为我们的产品需要同时支持 Mac, Windows 以及 iOS，所以就需要找一个 C 语言系跨平台的库。调研了一圈，发现了 cURL 以及 libcurl，看着支持各种协议，就决定选它了。
在产品里集成 libcurl 是那时工作以来挑战最大的一个任务，因为是添加一个底层框架组件，然后这个任务据说是 CTO 接到了用户需求，临时加塞进来的，实在没人了，就交给我这个 Junior 做。我还好对 Cocoa 框架熟悉，于是就照着它里面的 NSURL，NSConnection 设计了一版。记得印象很深的是 deadline 最后一晚，还在公司搞交叉编译，弄到半夜才搞定，没人 review，只好先提交完代码，结果开车回去，闯了个小路上的红灯，被埋伏在那里的警察逮个正着，吃了张巨额罚单。第二天到公司，QA 组长群发邮件，说 test build 坏了，一看果然是我干的，交叉编译的环境还是漏了，再给大家回了封致歉的邮件。修好后，QA 刚准备开测又疯了，因为 curl 本身支持各种协议，集成了 libcurl，就天然支持了各种协议，那理论上 QA 就要把各种协议都测一下。
所以后来讨论了一下，就缩减到第一版只支持 FILE, HTTP 这两个协议。随着工作年限的深入，我才知道 curl 的影响力之大，几乎所有的技术文档都有它的身影。其实当时做完需求，我只是觉得这玩意真不错，居然能支持那么多协议，这也是我第一次在工作中用开源组件解决问题，算是尝到了开源的甜头。
维护 MySQL & PostgreSQL 分支
13 年去了 Google，做的是数据库云计算服务 Cloud SQL，一开始它提供的是基于 MySQL 的云服务。Cloud SQL 团队自己维护了一个 MySQL 分支，我后来成为了分支的主维护者，负责每次同步上游的新版本。到 Cloud SQL 要推出 PostgreSQL 服务时，我也负责整个研发，第一步先是把当时最新版的 PostgreSQL 在 Google 内部的 Blaze 系统进行编译，而这个过程中最折腾的是 PostgreSQL 的 PostGIS 插件，这个插件是 PostgreSQL 的杀手级组件，一定要有，但是这个插件本身又依赖另外几个处理 GIS 数据的开源项目，所以就又扯上了 Geo 部门。
之后 Google 的 MySQL & PostgreSQL 分支一直就由我在维护着，我们本身提供的是原生的 MySQL & PostgreSQL 服务，所以对于内核的改动不算太大。但这个职责让我和上游社区有了更多的接触，同时和 Google 内部的开源管理团队打了一些交道。
旁观开源
2018 年回国后入职蚂蚁，首先加入的是 OceanBase 的 DBA 团队。OceanBase 现在是开源的，在我加入前也曾开源过，不过我在团队的那段时间正好在闭源阶段。后来我还先后去了研发效能部和体验技术部，但我负责的那块正好也都没有采用或者维护开源项目。不过那段时间海外的几家头部开源公司都跑通了商业化，国内也有像 PingCAP 这样的开源标杆，大厂也越来越重视开源这块，蚂蚁也成立了开源技术委员会，我也代表所在部门参与其中。蚂蚁也是优秀开源项目云集的地方，突出的像前端的 Ant Design，数据库的 OceanBase。可惜在蚂蚁的时候，没有契机参与到开源项目中。而从旁观者的角度看，蚂蚁和 Google 很类似，作为各自地区开源领域的标杆公司，既是开源很大的受益者，也是开源很大的贡献者。不同的是，相比于 Google 有相对充足的开源支持资源，蚂蚁投身开源的同学业务压力更重，经常要用爱发电，殊为不易。
虽然在蚂蚁没有参与过开源项目，但是几个不同部门任职的经验帮我找到了创业的点子，而且我知道最好的路径就是通过开源。
创业做开源
在蚂蚁呆过 3 个团队，也做了 3 块业务：数据库工具平台，开发者工具平台，生产力协同平台。而现在做的开源项目 Bytebase 便是这 3 者的结合，一个围绕数据库开发活动，帮助开发者和 DBA 协同的开发者工具 - Bytebase。
也有人会和我讨论，从商业角度考虑，Bytebase 是否并不需要开源，对方的观点也有逻辑，业界也有 Snowflake, Datadog 这样的闭源成功案例。但我从一开始就相信，开源的 Bytebase 是更优的商业选择。或许正好是我接触的开源始终是和商业结合在一起的，第一段提到的 280 North 其实是 YC 早期投的一家公司，也是 YC 历史上第一个比较大的退出回报。贴上当年 YC 掌门人 Paul Graham 在 HN 上的回复：
MongoDB 的官网设计也是开源商业化公司的典范，字体颜色的搭配，既专业也不失亲切。
大厂和创业做开源的异同
在蚂蚁分享了 3 个点，「以终为始」，「大鱼大池」，「无与伦比」。
以终为始
圈内有一个认知是「技术」->「产品」->「商品」这三点不能正着连，而是要以终点「商品」开始往回连。这个对于像 Bytebase 这样的开源商业公司是没错的。但是对于有其他主营业务的大厂来说，则完全就不是这条线。因为即使拿全球最成功的开源商业公司 MongoDB 来说，它一年的营收可能只是蚂蚁这样的公司几周的利润。所以大厂做开源的「终」不是靠开源产品本身挣钱，还是回到赋能自身业务，赋能品牌上。
大鱼大池
要么做基础核心软件，要么做全球市场，最好是兼而有之。大厂有资源从一开始就投入基础软件的研发，并且直接面向全球市场。而创业公司资源有限的情况下，尽量能选其一，或者再退一步，有到达其一的实现路径。
无与伦比
开源没有疆界，基本是赢家通吃，一张 SSS 卡 > 一箱 SS 卡。开源有很多的品类可以做，Apache, CNCF 一个品类下也有不少的项目。
但基本每一个品类往往只有一家最多两家的机会。Kubernetes 让 Mesosphere 和 Docker Swarm 都消亡了，Prometheus 始终统治着监控的江山，一将功成万骨枯。大厂开源项目多，但却很难孵化出 SSS 级的项目。因为战略的错位，使得无法保证持续的投入，没有持续投入，就很难做出精品。反倒是团队从大厂出来单飞后更能做成，像离开 LinkedIn 后的 Kafka / Confluent，脱离 Uber 后的 Temporal。 无论是在大厂还是创业，投身开源的同学多少都带着点理想主义，去业务线做个纯粹的 CRUD boy/girl 往往晋升更快，拿钱更多。但大家做开源，是因为在帮公司创造商业价值的时候，也想帮自己实现自我价值。希望自己写的代码不只用于营销场景，去套路一个个的用户，也能间接地驱动一个太阳能设备，探索一片空间，灌溉一方水土。
最后
蝴蝶扇动翅膀，万里之外飓风。假如 15 年前的我没有通过 Cappuccino 接触到开源社区，很可能现在的我也不会以开源为业。若是当年 Cappuccino 背后的 North 280 没有被摩托罗拉高价收购，成为早期 YC 投资的标杆案例，或许也没有后面出自 YC 的 Sam Altman，以及现在 OpenAI 引发的新一轮技术革命。 而在这一轮的 AI 革命中，开源将扮演更加重要的角色。即使 OpenAI 逐渐不再 Open， AI 领域的开源项目依然欣欣向荣。前有 Auto-GPT，后有 GPT Engineer，各种开源模型每天还在竞相刷新纪录。之前顶尖开源项目的增长趋势在 AI 开源项目下完全不值一提。
很可能在自己来到下一个 15 年之前， 开源的 AI 项目们就会吞噬掉整个世界吧。
文章分类
联系我们
| 联系人： | 北柠 |
|---|---|
| 电话： | 17554229565 |
| Email： | beining@chandao.com |
