科创人·StreamNative 翟佳：开源模式价值为王，基础软件的未来在国内社区

翟佳，StreamNative 联合创始人

Apache Pulsar 和 Apache BookKeeper PMC 成员，前 EMC 统一存储部门技术负责人，前 Streamlio 创始工程师。2020 年获选“中国开源先锋 33 人榜单”、2021 年荣获“OSCAR 尖峰开源人物”称号，开源技术布道者。

—

文 | babayage

编辑 | 笑 笑

天生偏好底层原则和长期主义

初识开源，信奉价值为王

与翟佳稍有接触，就能感觉到一份发自内心的笃定、坚实，友人评价他“知行合一，相信底层原则和逻辑，并且信了就做”。

谈起为何当初走上存储这条技术路线，翟佳坦言“谈不上梦想、使命这么高大上”，硬要找个理由，大约是出于他那种愿意钻研底层、研究基础理论的性格偏好：本科就读于计算机系统架构专业，到了研究生时期面前选项并不算多：通信或者存储二选一，毕业后，顺理成章加入了信息存储的代名词 EMC（易安信）。彼时，移动互联网浪潮尚未狂飙突进，能预判到存储将成为数字时代重要基础设施的前瞻者并不多，翟佳认识的只是一个浅显的大道理：“只要有 IT 就有存储，这是一件值得长期研究、学习的事情。”

在 EMC 期间，翟佳接触到了 BookKeeper，也由此迎来了事业人生的第二个关键词：开源。谈起最初对开源的感受，“跟现在肯定大不相同，最初对开源的理解就是公共代码，人人可以获取、可以使用，而且已经使用于一些比较先进的公司场景中、经过实践检验，各方面来说都是优秀靠谱的选择”。

每一位骨灰级玩家都有一段小白的曾经，翟佳对于开源的深刻理解也源自多年的积累与迭代。但与众不同的是，从接触开源那天开始，他就一直坚持“价值为王”的理念，对于一切将场景价值后置的理念、文化和宣言都不大感冒，“软件的价值在于解决世界上存在的某个问题，开源只是一种有效创造价值的手段”。

创业那些坑之一二：

选错模式，选错社区

回顾翟佳的创业生涯，很难绕过他的好友：StreamNative CEO 郭斯杰，二人在中科院计算机所是研究生同学，同样深耕于存储技术领域，共同参与 BookKeeper 开源社区……妥妥的官配 CP 既视感。

2016 年，翟佳自 EMC 辞职，开启了小半年的宅家模式。此时的郭斯杰已经走上创业之路，围绕“Heron+Pulsar+BookKeeper”的端到端方案创立了 Streamlio，听闻好友在家赋闲便力邀其加盟，翟佳略一了解后感觉“底层逻辑很靠谱，价值也很显而易见，那就试试看”。

然而，在 Streamlio 创建后的一年多时间里，他们不断尝试各种商业化手段却收效甚微，创始人团队逐渐形成了一个共识：基础软件的商业化推广需要消耗大量资源，是巨头的游戏；并且，缺乏场景价值实证的基础软件，技术再先进也难以得到市场认可。

于是，开源社区成为了 Streamlio 绝地求生的华山一路，但在开源社区的选择上他们却犯了又一个不大不小的失误：首先选择了开源社区最发达的美国社区，对此翟佳反思道：“做基础软件创业的企业，其实更适合发展速度快、变化大、数据土壤丰富的环境——也就是国内社区。”

稍做停顿，翟佳一字一顿地说了这样一句话：“对于走开源社区路线的创业项目而言，一定要充分考虑各方面的因素，慎重选择社区，因为除了极少数开创性技术项目，对大部分项目而言，社区同时扮演着生产力、需求池、推广渠道和护城河的角色——没有社区，就没有生命。”

2018 年 10 月，翟佳与郭斯杰在京沪两地举办了两场以 Pulsar 为主题的 Meetup，试水社区运营建设、推广，反响之热烈远远超乎预期。

同年，二人离开了 Streamlio，创建 StreamNative，打造基于国内开源社区的基础软件创业模式。

科创人：越来越多的创业项目选择开源模式，您能否分享下企业选择社区的标准？

翟佳：这个话题略大，我唯一能够明确建议的是，做基础软件项目的企业其实不妨试一试国内社区，因为国内企业的商业模式还是以业务驱动为主，增长快、变化大、场景丰富，只要你的产品足够优秀、足够高效，能够解决企业的问题，他们会很愿意使用。另外，其实社区营销和做 To C 营销没有本质区别，微信的营销对象是社交需求者，开源软件的营销对象是程序员，本质都是价值与人的连接。

“见着亮”的两个标志：

落地大厂场景，Meetup 爆满

在见证过技术原理出色的 BookKeeper 因为过于抽象而难以商业化，亲历过 Streamlio 时期在水面下憋气前行、不知道何时得以喘息，体验过自认为精妙的端到端解决方案在美国开源社区遭遇冷遇……一系列困难和挫折之后，翟佳却还是笃定地相信云原生存储这一技术方向，他认为：“环境、时机、决策、模式都可能错，唯独这个方向一定是正确的”。

而他的坚持也最终见到了回报，以充分试错、迭代的经验为燃料，StreamNative 终于顺利启航。在创建 8 个月之后，StreamNative 举办了一场 Meetup，翟佳至今还记得那天的情景：从早上 9:30 持续到下午 6:00，参与者有来自腾讯等大厂的国内伙伴，有自雅虎日本特意飞来的海外伙伴，“快到结束的时候我才发现，我们已经能够撑起整整一天的 Meetup，那天我是发自内心的觉得这个事业见亮了”。

更直接的信心来自灯塔客户的肯定，腾讯计费平台与短视频应用 BIGO 分别成为了 StreamNative 在线上业务场景和线下数据分析业务场景的灯塔案例：

腾讯计费平台不单对系统扩容有要求，同时也对数据服务质量要求严苛，腾讯计费平台利用 Apache Pulsar 处理日均 100 亿+ 交易请求，日均消费 10T+ 数据，承载了腾讯集团每日数亿收入大盘，托管账户总量达 300 多亿；BIGO 的案例是基于大家在流场景中经常遇到的集群运维这一痛点，BIGO 借助 Apache Pulsar 与大数据生态系统的良好融合构建了实时推荐和分析系统，助力业务快速发展，降低了原来 Kafka 集群运维成本与难度，特别是扩容缩容的人力成本。

翟佳对早期客户表达了诚挚的感谢之情，在他看来“合作的本质是达成共识，基础软件要真正成功，必须要达成大范围、大规模的共识，否则何谈‘基础’？正因如此，基础软件的商业推广成本奇高、难度奇大。通过开源社区，快速落地高信任度、高难度的场景价值，这是最好的信任状，也是开源模式的优势所在”。

创业的那些坑之三四；

事儿推人，误判需求优先级

科创人：创业这一路走来，有过哪些颠覆过往认知的经历？

翟佳：很多，随口就能说出好几个（笑）。

第一个就是被事情推着走，很多创业企业都经历过人少事儿多的阶段，一忙起来就只顾着“干活”，经常忘记为了什么干，也顾不上人才培养。

但坑踩多了就知道这是不行的，解决方法有两个：一是建立规划，明确行动目标，所有的事情都要围绕目标构建行动、筹备资源，即使缺乏资源也做出规划，比如缺人才，那我们需要什么样的人才能做成这件事？想清楚就去找人；二是充分授权，人不够就找，找来了就要相信战友。

规划做出来了，新的大坑也来了，创业阶段最常见的问题：资源有限，客户需求和战略规划哪个优先级更高？起初我们认为满足付费客户的需求是正确的，客户是上帝、拿人钱财就该给人干活，但最终我们发现这样是不对的，“客户提需求——我们满足”这个模式存在一个根本问题：客户提的需求，未必是问题的最优解，最佳解决方案更有可能就在我们的战略规划中，因为我们才是这个领域的技术专家，更了解它现存的问题和未来潜力。所以我们增加了与客户沟通优先级的过程，帮助客户了解“按照我们的规划进行，问题能够更有效地被解决”。

事实证明，客户选择你是因为信任你，信任你的人也愿意信任你的判断，只要沟通清楚就好。

科创人：《科创人》分享过很多科创前辈的授权经验，也请您分享下您授权的实操经验？

翟佳：我的风格是坚定甚至激进的授权，充分信任同事，在执行前我只负责与同事们确定规划、对齐目标，之后具体事情一概不管，鼓励同事们大胆做、放心走，出现问题了我再来帮你复盘、思考如何解决，没有问题就一直做下去。

基础软件的未来在国内

科创人：在 StreamNative 的创业历程中，是否有过战略层面的摇摆？

翟佳：有过，但不是在技术层面，而是在市场策略层面。StreamNative 拥有一批海外用户，这些用户的付费意愿、使用场景都与国内不一样，他们更接受 SaaS 收费模式，而国内用户更需要解决具体问题，并且倾向于私有化部署。这时就会有不少不同的声音，比如有人会建议，你在海外已经可以通过 SaaS 模式获取客户，国内这些客户还有没有必要？

StreamNative 慎重考虑过只走“海外市场+商业化 SaaS”这条路，但最终还是决定坚持自己的价值主张：最重要的不是什么模式赚钱多、赚钱快，而是哪种模式与产品的未来真正结合在一起——国内客户场景丰富、数据量大、发展快，StreamNative 会以国内社区和用户的场景打磨产品，反哺 SaaS 产品。

当然，也不能否认国外用户的付费意愿确实比国内好很多，也给予了我们很多鼓励，但 StreamNative 更希望能够看到国内环境不断好转，现在，国家层面也越来越重视开源，StreamNative 也必将参与到国内整体的数字化进程中了。

未来规划：产品线统一

科创人：谈一谈下一阶段的规划和目标？

翟佳：核心工作是实现整个产品线的统一，我们希望所有产品内部使用同一套框架、同一套代码。

在整体方向上，还是要把控好在消息（MQ）和大数据流处理这两个方向上的优势。最近在做的一个方向是更加贴近大数据管道场景，我们正在和 Flink 社区探讨如何将 Pulsar 应用在批流融合的场景下，充分发挥 Pulsar 存储计算分离的云原生架构优势。

在消息（MQ）方向上，大家对各种消息协议解析比较关注，我们也在跟社区的其他小伙伴一起努力，将这一部分的生态变得更加丰富。