上个月回蚂蚁做了一场有关开源的分享，让我讲讲离开公司自己做开源创业后的感想。
正好借着端午节的时间，也更完整地回顾一下自己职业生涯 15 年来和开源结缘的经历。
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。我空下来时间就在捣鼓 Cappuccino，那时同事还发起了 CocoaHeads 北京的社区，我也去给大家分享了一下 Cappuccino，这也是我至今唯一一次参加的线下社区分享。后来 280 North 还出了一个 Web 版的 Xcode，虽然要收费，我也立刻去充值了信仰。即使放到今天来看，Cappuccino 的技术和设计品味都不过时，就连它商业化产品采用的名字也和 MongoDB 一样，都叫 Atlas。也后来没过多久 280 North 这家公司就被摩托罗拉以 2000 万美金收购了，而公司就只有 3 个人。去瞄了眼 GitHub 上 Cappuccino 的仓库，居然最近还有活跃。虽然项目算是黄了，我购买的 Web IDE 也打了水漂，但还是从项目本身学到了不少，也感受了一把大厂的钞能力。
工作中第一次深度接触的开源项目是 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 的影响力之大，几乎所有的技术文档都有它的身影。其实当时做完需求，我只是觉得这玩意真不错，居然能支持那么多协议，这也是我第一次在工作中用开源组件解决问题，算是尝到了开源的甜头。
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 上的回复：10 年来到硅谷，看到一个叫 Mongo 的开源 NoSQL 数据库在四处布道，看着它连事务都不支持的样子，作为 ACID 原教旨主义派的我是嗤之以鼻。而时至今日，MongoDB 已经是商业上最成功的开源公司了。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 项目们就会吞噬掉整个世界吧。当然也有可能是 AI 的开源项目们。