北京时间 10 月 12 日，云原生批流融合数据平台 StreamNative 获得 2300 万美元 A 轮融资，本轮融资由沙特阿美旗下多元化风投基金 Prosperity7 Ventures 与华泰证券旗下另类投资子公司华泰创新联合领投，老股东红杉中国、源码资本继续加码。

StreamNative 于 2020 年 8 月完成数百万美元 Pre-A 轮融资，源码资本领投、红杉中国种子基金跟投；2019 年团队创立初期获得红杉中国种子基金天使轮投资。

近日，StreamNative 联合创始人郭斯杰接受 InfoQ 采访，与 InfoQ 中国的掌舵者 Kevin 进行深度对话，为 InfoQ 的开发者们分享了 StreamNative 创业路上的艰辛、踩坑、梦想，以及对于开源项目、开源社区及开源商业化等方向的看法。

以下为郭斯杰采访文字实录，略有改动。

关于 Pulsar 的诞生

我叫郭斯杰，是 StreamNative 的联合创始人兼 CEO，是两个 Apache 软件基金会顶级项目 Pulsar 和 BookKeeper 的 PMC 成员，PMC 全称叫 Project Management Committee（技术管理委员会），主要负责 Apache 项目的一些技术路线，我可能算是在中国比较早一批参与到 Apache 软件基金会的开源项目的人。

在中国，开源社区是在 2008 年、2009 年的时候开始兴起的，也是 Hadoop 进入中国的时间点。我是 Hadoop 比较早期的代码贡献者，也曾经给 HBase、Hive、HDFS 贡献过代码，这也是我后来选择加入雅虎很重要的原因 ── 因为 Hadoop 是从雅虎出来的。接触 Apache 软件基金会让我对 Apache 软件基金会怎么运作的、开源是什么有了更加深入的理解。

我在加入雅虎之后，也借助这个机会自己去创建和孵化了两个后来成为 Apache 软件基金会顶级的开源项目，一个是 Pulsar、一个是 BookKeeper。BookKeeper 其实是最早的顶级项目，它是从 Apache 孵化出的一个分布式日志存储系统。我们孵化了 BookKeeper 之后，又在 BookKeeper 之上做了一个当时叫做雅虎内部的消息云，全称叫 Cloud Message Service（注：Pulsar 的原型）。这个 Cloud Message Service 在雅虎内部运行了大概有 4-5 年的时间，支撑了很多核心的业务，比如雅虎邮箱、雅虎金融等核心产品。

Pulsar 在支撑这些业务 4 年左右的时间后，2016 年雅虎把这个项目开源贡献给 Apache 软件基金会，最后变成了顶级项目，我的整个经历基本是跟 Apache 软件基金会的开源、消息中间件，还有数据系统相关的。

Pulsar：云时代的消息处理“跑车”？

StreamNative 是一家开源商业化的公司，由 Apache Pulsar 的创始团队创立而成。我们最主要的职责是做 Apache Pulsar 的商业化，把 Apache Pulsar 技术带到更多的企业去，帮助解决企业在消息系统、流数据系统碰到的一些扩展性、性能可用性的问题，帮助企业从这种消息数据、流数据里面挖掘出企业的价值，这也是 StreamNative 成立的初衷。

同时，我们也要推动 Apache Pulsar 项目的发展，把项目以商业化的产品卖到更多的企业内部，其实就是用公司的方式为这些用户提供更好的服务。

Apache Pulsar 是一个分布式消息队列，我们有时候也叫它分布式的流数据系统。消息跟流是不分家的，因为都是流动的数据。简单来说，消息队列通常会用在一些电商支付的交易场景中，需要一个消息队列去做流量的缓冲，起到削峰填谷的作用。

举个最简单的例子，双 11 大量的人会在同一个时间点抢单。如果网站的流量全部涌上来，直接怼到数据库，其实会把整个数据库打挂掉。所以它才会在前面放一个消息队列去缓冲你的所有的请求，流量会进到消息队列里去，后端再有相应的服务去处理相应的请求。这样的话，就能避免大量流量对整个数据库系统造成冲击。

Apache Pulsar 就是在消息队列领域里基于云原生基础架构设计的产品，它能够很好地在容器化环境里面去运行。上一代的传统消息队列 RabbitMQ、ActiveMQ 这些都是单机系统，单机系统随着业务增长是没有办法去支撑业务增长的。

这个时候就要装很多台的单机系统做相应的处理。装多台系统，就会带来更多的运维复杂度，比如去做容错。Pulsar 其实就是在这样的环境里面诞生的一个分布式的、可自动扩缩容的系统。根据你的业务可以去扩容跟缩容，你的业务运维团队也不用再担心说我最近要上几台 MQ 去做支持。

类比一个例子：对于数据库而言，MySQL 是一个很流行的数据库，但 MySQL 的缺点就是一个单机数据库。这时候如果业务一旦涌上来，就需要去支撑业务的发展。单机的 MySQL 是没有办法支撑业务的，这个时候就要引入像 TiDB 这样的分布式数据库。

如果你把 RabbitMQ 当做 MySQL，Pulsar 就是 TiDB。原来可能是你用一辆马车在跑，现在换 Pulsar 之后，变成用一辆跑车在跑。Pulsar 是云时代的处理消息的一个非常好的产品，是在云原生时代诞生的分布式的消息和流数据系统。针对于流动的消息和数据，Pulsar 是很优秀的数据管理系统。

关于融资：StreamNative 致力于打造世界一流的服务

做下一代的消息系统、流数据系统，需要有很多顶尖的人才，虽然我们有很核心的创始团队，但随着整个社区的增长，我们面对的业务场景的丰富度很大，在金融行业有人在使用，在零售电商也有很大的落地场景，还有现在很火的 IoT、自动驾驶……其实有很多的应用场景。

怎么把一个新兴的、基于云原生时代技术诞生的下一代产品变成一个流行的、能广泛应用在企业内部的系统，需要大量的研发人员参与其中，包括去开发相应的特性、改善系统的稳定性，还要同时做出世界一流的服务，能够服务世界 500 强企业，去帮助他们挖掘实时数据的价值。所以，我们希望这笔新融资能够通过资本的力量吸纳更多的优秀人才，帮助我们去推动整个产品的研发和相应的落地，最终还是希望能够把好的项目让更多的企业尽早地落地应用。

谈 Kafka - 每个时代都有属于自己的产品

首先需要讲一下 Kafka 与 Pulsar 各自诞生的背景。Kafka 是在 2010 年左右诞生在 Hadoop 的时代，初衷是为了解决一个很简单的问题，就是我有大量的日志，我需要把这些日志采集起来放到 Hadoop 系统里去。所以它的整个设计基于 Hadoop 时代的物理机，或者虚拟机这样的基础设施。

Pulsar 的诞生相对于 Kafka 会晚 2-3 年，它碰到的问题和 Kafka 不太一样。Pulsar 碰到的挑战是整个基础设施从物理机、虚拟机向容器化去转型，所以它是围绕容器化、云原生做的设计。Pulsar 和 Kafka 最大的区别就是两个产品诞生的时代不一样，面对的挑战也不一样。

Pulsar 之所以流行，很大的原因是我们处于时代变革的浪潮，从物理机、虚拟机的时代迁移到容器化、Kubernetes、云原生的时代，这意味着我们所有的基础设施都要升级。

就像我们现在已经修了高速公路，但却还在高速公路上跑马车。所以我们必须得搭配一辆跑车，才能发挥出高速公路最大的价值。我们可以看到这两者最大的区别，就是它们诞生的时代背景不一样，很多人会在纠结的问题是两个社区的差异相对较大，我们也承认。因为 Kafka 在 2011 年开源，Pulsar 在 2016 年开源，中间差了 5 年的时间。你拿一个跑了 11 年的项目，和一个跑了只有 4 年多的项目去比社区是没办法比的。但 Kafka 是一个相对比较成熟的项目，它已经到了生命周期的天花板；Pulsar 不一样的地方是，Pulsar 是一个很年轻的、欣欣向荣的项目，而且我们整个的社区增长是很良性的，我们基本上花了 4 年的时间，就已经达到了可能 Kafka 花了 7~8 年时间才可能构建出来的社区规模和增长速度。

当然，还有相应的 Adoption（落地），这是两者在社区上的区别，Pulsar 会更加年轻，但我们已经追上甚至可能越 Kafka 社区的规模。

在性能方面，通常我并不是一个会直接去讨论性能的人，因为从技术团队的 Leader 的角度来看一个系统，考虑的不仅仅是性能，还有稳定性、扩展性、运维……但是回到根本，所有的开发者都喜欢探讨性能。我们从很多第三方评测工具，比如说最近 OpenMessaging BenchMark，这是 Linux Foundation 下面的一个评测工具，都做了 Kafka 和 Pulsar 性能的对比，在普通业务场景下，Kafka 跟 Pulsar 的性能是持平的状态。

因为两者都可以把整个机器的性能打满，就是你的磁盘带宽、物理带宽、网络带宽都可以做到打满的状态，但是在一些关键业务场景，比如说支付交易，这种不允许丢数据的场景里面，Pulsar 相对于 Kafka 可能有 4-5 倍的性能优势。而且它的整个时延会相比 Kafka 更稳定、更低。所以从性能的角度，Pulsar 是可以碾压 Kafka 的。

从这两个角度来看的话，你也不难看出为什么 Pulsar 能在短短 4 ～ 5 年时间从一个相对比较年轻的项目变成一个增长发展特别快的顶级项目，因为一个时代总有属于自己的产品，目的是为了去解决不同时代所面临的问题。

时势造英雄：关于 Pulsar 的“新架构”

这个需要从两个角度去讲，第一个是从所有技术人最关心的架构角度。如上面所提，Kafka 跟 Pulsar 是两个时代的产物，最本质的区别其实也在架构，Kafka 是单体架构，就是计算能力和存储能力都在一个物理节点上，当需要去扩容的时候就涉及到搬迁数据。

搬迁数据是一个耗时，同时会导致系统不稳定、不可用的操作。Pulsar 的诞生在容器化时代，所以它采用了现在云原生相对流行的架构——存算分离。你的存储跟计算是分离的状态，你的存储节点有一组容器去负责，你的计算节点又是由另外一组容器去负责。这个时候当你需要存更多数据的时候，只需要添加相应的存储节点；需要服务更多的生产者、消费者，或者是计算的时候，只需要增加相应的计算节点。两个可以是完全独立扩容，再利用上像云原生时代 Kubernetes 这样的大杀器，你就可以很快地自动弹性扩缩容，所以这是两者架构上最根本的区别，或者称之为 Pulsar 很大的创新点。

第二是 Pulsar 做了很多上一代消息系统或者上一代流数据系统没有做的一些功能和特性，比如多租户管理、跨机房复制、层级存储这些特性，你在上一代的消息系统里面都看不到，但 Pulsar 都提供了。

拿其中的一个特性举例——跨地域复制，这是很重要的一个特性，尤其是在云原生时代。因为云原生时代，我们讲的很多的是企业要上云，而且上的不只是一朵云，可能是多个云。因为你要确保你不会因为一个云厂商给绑定，那你的数据就需要在多个云之间复制。有些企业可以很容易地上云，但是它不能完全上公有云，这个时候就会涉及到上私有云，但是它还是允许把一部分数据放到公有云，变成混合云的架构。

在多云跟混合云架构里，最重要的一个特性是如何在云和云之间进行数据的传输跟复制。Pulsar 内置的这种跨地域复制功能就能起到很好的作用。所以这也是为什么我们一直在说，Pulsar 的创新点。

中国有句古话叫“时势造英雄”，因为云原生的兴起带来了很多业务基础设施的变革，就需要有新的技术软件出来去适应云原生的架构，适应多云的场景、混合云的场景，所以这就是为什么 Pulsar 很吸引人的相对比较大的创新点。

社区是开源项目的基石

我觉得 Kevin 说了一句很好的话，“开源是整个商业化的基石”，如果没有很好的社区，就没有办法把商业化做起来，但我通常用另外一句话去形容 ──“开源社区是开源商业化公司最好的护城河”。很多人会觉得我的护城河是我的技术壁垒，但技术永远在不断迭代更新，可能 5 年一淘汰。社区才是最好的壁垒，因为社区可以给你带来很丰富的应用场景，社区也可以带来相应的贡献者。

贡献者可以带来很好的口碑，口碑可以帮助传播技术，让更多人去使用。当更多的人进到社区里以后，又可以回馈、帮助迭代产品。不断地迭代你的产品，你的整个技术壁垒就慢慢地构建起来。所以我通常会说“社区是商业化公司最好的护城河”，社区是最核心的东西。

我们从商业化公司的角度花了很大精力在整个开源社区上。我们不仅仅会写很多的用户案例、博客，同时也会组织很多的线下沙龙、线上的 TGIP（「Thank God, it’s Pulsar」系列直播活动）。同时作为 Pulsar 的商业化公司，我们也是 Pulsar 的全球会议 Pulsar Summit 的组织者，去年我们在北美、亚洲举办了两场 Pulsar Summit，今年还会再增加一个，在北美、欧洲、亚洲共举办三场 Summit。

同时，我们在今年五月举办了一场全球的 Pulsar 黑客马拉松，让全世界的开发者参与到 Pulsar 中点燃他们的一些想法、去迭代出一些新的 Feature 和性能。我们通过各种丰富的社区活动把开发者聚集在一起，鼓励他们去做贡献并给予相应的回馈，刺激这些开发者参与到社区，由开发者带开发者，形成病毒式的传播，把整个社区做大。

开源商业化——我们选择了适合自己的道路

现在开源商业化的挑战永远是在于免费跟收费之间。开源商业化经历了三个阶段，最出名的是 Linux 商业化，RedHat 就是一个，我们把它叫开源商业化 1.0，是卖技术服务，卖 Linux 的发行版本，随着发行版本附带相应的技术服务。

到了 2.0 时代，更多的是 Open Core 的方式，Open Core 的方式是很典型的模式。像 Elastic，它就是很典型的 Open Core，就是说我有开源免费版本，在开源免费版本之上再去添加一些付费的特性变成商业化版本，用卖商业化版本的方式去迭代。

今天我们到了云时代，而 1.0 跟 2.0 都是物理机虚拟机的时代。今天到了容器化时代，到了云时代，可能很多人还可以做 2.0 的生意，或者是甚至可以做 1.0 的生意，但会有一定的局限性。

很多新兴的开源商业化公司，比如 Databricks，它全部抛弃了 Open Core 的模型，直接做 SaaS，SaaS 是开源商业化 3.0 的模式。对我们而言，最大的挑战并不是赚钱，最大挑战是究竟应该选哪条路，因为我一旦选了第一条路，那么构建的模型需要招很多的 Support Engineer 进来，整个公司架构就会发生变化。

但是如果走第二条路的话，我首先要考虑的问题是如何平衡我的开源版本跟商业版本的边界。这个问题如果调整不好，就会带来反作用，开发者社区可能就会背离你。因为我们如果把大量的 Feature 全部放成商业版本，开发者开源版本用得不爽，就没有理由给你贡献代码。所以第二种模式很大的挑战是在于怎么均衡商业化和开源核心的关系。

第三个模式是 SaaS 的挑战。它是完全新的 Model，需要很多的这种云的人才，需要懂 Kubernetes、需要懂不同的云。

我们最大的问题，是对于道路的选择。因为目前 Pulsar 最开始的项目社区相对比较小，所以我们把第二条路 Open Core 给排除掉了，这么小的规模，如果去做商业化，就会起副作用，会让别人觉得你把大量的特性给闭源了，我为什么还要使用 Pulsar，这还是一个年轻的项目。所以一开始我们要进行收费的话就可能并不友好，但是开源商业化的最终目的还是商业化。

我们觉得云时代 SaaS 是能凸显出 Pulsar 特性的事情，所以毫不犹豫地走了 SaaS 这条路，但也面临着很大挑战，我们怎么让原来更多在做开源项目的团队做云？我们需要招人，甚至让已有的这些人去学云、学 Kubernetes，我觉得这个是在开源商业化这条路上面临过的比较大的挑战。

道路想清楚了以后，前行就不是很困难。我们在（备注：采访时间为 2021 年 5 月）过去 6-8 个月的时间，基本上已经把整个的云服务给跑起来了，付费客户也从 0 增长到 25 个（备注：整个增长相对较快，不是最新数据）。我们现在其实能够很好地均衡开源社区和商业化，能让这两个部分形成一个飞轮互相带动。现在的结论就是非常明确的 StreamNative 的商业模式。

“先出洋、再本土”── 实现共赢才是根本

“关于如何实现开源商业化？”，这是很好的问题，现在所有开源项目（商业化）最后会面临的拷问就是：你的社区用户在哪？你的付费用户在哪？别人为什么要为你的东西买单？

我们目前的整个商业化进程基本是在海外，在中国更多的是社区用户，当然我们这一年有一些早期的商业化的尝试，在中国的商业化尝试更多的偏向金融行业，有一些证券跟银行相关的客户在接触，我们可能会在今年落地一些商业化的案例，但大部分的商业化用户是在欧美、印度。

因为我们是一家 SaaS 服务公司，所以基本上（客户）买的是公有云上的服务，我们目前公有云的服务覆盖了三大云厂商，包括谷歌云、AWS 跟微软云，都是国外的云。我们也在去年年底在国内推出了免费版本的阿里云，我们也会在接下来的几个月的时间，在阿里云上推出相应的付费版本。同时也有像腾讯云的规划，我们在国内除了探索潜在的一个商业化模式，也会把相应的 SaaS 服务把服务带回国内来，带到国外去。

我们大部分的付费用户是来自于欧美，有 40% 的用户来自欧洲，50-60% 的用户来自于北美，我们的客户基本上来自三个行业，第一是金融跟银行相关行业，像 Hedge Fund 对冲基金、Stock Broker 这些做股票交易的公司，这些公司集中在美国的波士顿、芝加哥地域，我们有很多客户都是来自那里。

第二个来自于电商跟零售，还有市场相关的 SaaS 服务，大部分的用户（更多的是美国用户）在零售电商行业有一家印度的顶级电商 Flipkart，号称“印度的 Amazon”，它是我们的付费客户。我们正在帮他们将基于 Kafka 的整个消息平台迁移到 Pulsar 上来，这个是第二大类。第三大类叫 IoT，Manufacture 制造业，还有自动驾驶这个行业会产生大量的 Sensor Data（传感数据）。

这些传感数据是以流式的方式进来，我们需要对它以流式的方式去处理跟分析，在这个行业里面，我们有一些典型的客户，比如 Toyota 欧洲。除此之外，美国有一家做制造芯片的厂商叫 Applied Materials（应用材料），他们也是从原来的 MQ 迁移到 Pulsar 上来，所以你会看到我们的整个商业化更多的还是在海外。

这跟国内有很多的开源商业化公司很类似，比如：Kyligence、涛思、PingCAP……其实大家都在讲一个故事，就是出洋。我在中国有很大的开源社区，通过开源社区磨练出来的产品，怎么到海外去卖到欧洲、卖到美国，相对于这些中国本土起来的开源商业公司不一样的地方是，我们先做的是美国的、海外的市场，然后再回过来做中国的市场，这是两个商业化不一样的地方。

在国外人群，欧美人群的付费意识相对比较流程化、标准化。换句话说，（截止到采访时间）我们整个公司目前没有一个销售，但是我们能把客户从 0 做到 25 家，并不是因为没有销售就不能做任何的商业化，而很多的时候是因为开源社区已经帮你囤了一大堆的用户群体，这些用户他需要一些商业化服务，这个时候他就会找开源项目背后的商业化公司去购买相应的服务。

一旦找到这个公司，SaaS 服务又是一个很标准化的环境，标准化的计费，所以很快地就能把整个的商业化给做起来。社区已经把你的项目品牌、信任度、市场做好了，所以最后采购就是顺理成章的结果。目前我们大部分客户还是来自于国外，国内比较少，虽然有一些公司在使用，但用的还是开源版本。在国内，我们社区用户特别多。

我们的用户大部分来自于中国顶级互联网公司，比如腾讯在 2019 年年初的时候就使用 Pulsar 来搭建了它的整个计费平台。换而言之，你现在在微信上发的任何一个红包，可能都需要通过它的支付平台经过 Pulsar，所以 Pulsar 在整个腾讯的业务中扮演了很核心很重要的一个组件，同时因为腾讯规模特别大，也证明了 Pulsar 是经历过中国互联网规模的考验和验证的。

除了腾讯，也有很多比较顶级的互联网公司，像知乎、伴鱼、BIGO、苏宁、VipKid 等都是 Pulsar 的用户和合作伙伴。在中国，大的互联网公司贡献了很多新鲜的血液到 Pulsar 社区里面去，帮助 Pulsar 的项目去迭代整个产品，我觉得它其实像是交换，我把这个软件给互联网厂商去使用，互联网厂商作为回报投入了相应的工程师资源去帮你开发，帮你迭代相应的产品，所以究竟付不付费并不重要。

因为我们的客户群体并不是这些顶级的互联网公司，我们的付费的群体可能更多的是二线、三线或者是传统行业公司，他们没有那么大的开发能力，所以这是我们作为商业化公司能给企业带来的真正的价值。

换句话说，我们和腾讯（的合作），我们对腾讯的帮助其实是微乎其微的，腾讯已经有很优秀的人才了。换个角度看，我们可以提供的是作为核心开发者，能在一些特性的研发 RoadMap 上带来的指导，就是引路人的角色。

但很多的时候，除了引路人的角色之外，是社区互助，大家一起共同把整个市场做大。所以说，顶级的互联网公司，就算有钱，购买我们产品的意愿并不大，但是他的顶级的研发人员可以帮助我们去完善产品。我们再把这些完善的产品，去交付给那些没有那么大研发能力的一些公司，帮他快速使用，所以这就形成了非常良性的循环。

一旦这个模式形成，就是一个巨大的飞轮，因为有互联网公司为它的场景背书，这个背书会形成巨大的效应，把这些二三线的研发能力相对较弱的传统行业的企业带到社区中来。而一旦进入到社区以后，我们作为一个商业化公司，就能提供我们的商业价值，这是一个很好的互动双赢的状态。我估计这也是很多人愿意投入到开源的项目里面，又基于这些开源的项目去做商业化产品的很重要的原因。

做产品——从 0 到 1 的凤凰涅槃

我们是做 Pulsar SaaS 服务的公司，对于整个核心的项目是以开源协作的方式去开发的，然而 SaaS 产品可能是不大一样，我觉得对我而言最大的里程碑，是怎么从 0 到 1，这对我们来说是很大的挑战。因为我们团队大部分人最开始只是做消息系统或者核心软件的部分，原来也没有做过 SaaS 类的服务，第一个挑战是要上公有云，每个公有云可能都不大一样，都需要对每个公有云的这些 API 文档不断的钻研理解。

第二个挑战源自 Kubernetes，我们选择了 Kubernetes 作为基础设施去跑整个 Pulsar。我们用过 Kubernetes，但是如果你要把 Kubernetes 拿过来作基础设施，去卖云服务还是会有很大的挑战。

我们最开始说要做商业化，是在 2019 年底琢磨要怎么去做商业化，但整个云产品其实原定的里程碑是 2020 年 4 月份，4 月份的时候我们要举办第一场 Pulsar Summit。

我们本来是想在 Pulsar 峰会发布我们的产品，但是因为经验不足，导致了我们对于整个时间的把控、没有把握它的交付的节奏。最后我们并不能够按时地在 4 月发布相应的服务，最后总共经历了 8~9 个月，一直到 2020 年 8 月份，才完善了整个产品。

这个产品相对还是一个基础的雏形，但它有基本 Foundation 了，在 Foundation 上再去加特性再去扩展到其它云，就变得特别容易。最开始从零到一的过程，其实是比较痛苦的过程，当然对我们来说是挑战，也有很大的收获。

包括中间的设计阶段，最开始我们做了第一版的设计，我们已经按照这个设计，做了两三个月的研发。但最后发现整个 Foundation 并不是很牢靠。我们后来在 2020 年二三月的时候，从微软云招了一个原来的技术 Leader，他加入我们以后，我们把原来的架构推倒，重新再建，最后确定了相对比较好的 Foundation 去做。在整个流程中，我觉得 StreamNative 的产品研发最早期从 0 到 1 的过程是很重要的。

从 0 到 1 之后，我们在 2020 年 8 月上了 Google Cloud Platform 、11 月底上了阿里云、今年 1 月初上了 AWS，虽然是免费版本。但起码能在阿里云上提供相应的服务，后面可能会上微软云和相关的其它小云。

我认为一个软件产品延迟交付应该是常态，是因为我觉得所有的工程师都过于自负，都觉得我能在两个礼拜完成事情。但事实上需要四个礼拜完成，因为工程师可能只考虑到这个代码写完就结束了，但是代码写完并不代表结束，还需要写文档、测试、验证……这些是工程师不会去想的事情，但是一个好的产品经理，是需要为产品负责的。

从一个全工程师的团队转型成需要有产品理念、产品概念的团队，我觉得这个对我们团队而言，算是一段凤凰涅盘的经历。两年多来，不仅仅是这个产品上要实现从 0 到 1 里程碑式的发展，在整个团队的协作上和整个思维模式的转变上也都面临着比较大的变化，这是初创公司必经的一个阶段。

StreamNative 的产品未来

SaaS 我们已经完成了从 0 到 1，接下来的规划会有几个相对比较大的产品特性的发布，会在接下来几个月的时间发生，一是达到云的覆盖，要让我们在每个云上都有相应的服务，上腾讯云、阿里云的付费版本，这是很重要的我们需要在国内做 SaaS 服务的里程碑。

其次，Apache Pulsar 是一个新兴的项目，但很多老牌的项目像 Kafka、 RabbitMQ 在市场上已经有大量的应用。那么我如何让这部分用户可以无缝地迁移到 Apache Pulsar 上来？以 Kafka 举例，我们在 Apache Pulsar 上做了一个项目，Kafka on Pulsar（KoP），就是基于 Apache Pulsar 的 Kafka，项目的整个研发和部署都是跟国内的一些顶级互联网公司像腾讯、BIGO 去合作的，因为腾讯有大量的业务场景规模能够帮我们打磨 Kafka on Pulsar 这个项目。

目前 BIGO 跟腾讯基本上在用 Kafka on Pulsar 去迁移它们大量的 Kafka 的应用，所以我们可能在接下来的几个月的时间会有一个 GA 版本的发布，这个是 Kafka on Pulsar。

最后一个是对我们整个公司特性的愿景，我们觉得消息数据跟流数据，如果有一个系统能够采集接收这个数据，并把它存下来，会是一个很好的系统，这样就能解决很多的问题，但要给企业带来真正价值，还是需要计算，因为计算其实是挖掘相应的数据价值。

Apache Pulsar 内部有一个 Serverless（无服务器） 的框架叫 Pulsar Functions。它能做一些很轻量化的计算，对于复杂计算的话，我们其实在做的一个事情，就是把 Flink 所谓的下一代的批流融合的计算引擎，引到我们的一个产品里面进来，做一个无缝的集成。从用户的角度来说，可以使用 StreamNative Cloud，也就是说基于 Apache Pulsar 打造的一个批流融合的产品，去做相关的批流融合的计算。这是整个公司下一个阶段特别大一个里程碑式的 Feature。

退租办公室，全员远程——StreamNative 的 cool 文化

其实我们最开始的初衷，并不是想打造一个全远程办公的公司。当然，虽然我有这样的一个想法。因为我在硅谷待了有十多年的时间，对于远程办公这个事情，整个硅谷可能还是相对比较适应的状态，但我们最开始在做公司的时候有很多的团队成员来自于国内，来自北京。

国内整个环境来说的话，对于远程办公并不是很能接受，所以我们在 2019 年的时候是有办公地点的，在北京海淀上地，从 2019 年到 2020 年初都是集体办公的状态。当然 20 年初的疫情打乱了整个节奏，当时因为疫情的原因迫使很多人都在家办公。我们当时想，疫情过后是不是要回去办公？我的担忧是整个中国团队能不能很好地适应远程办公，但疫情迫使每个人都在家办公以后，我们发现整个团队的工作效率并没有下降，反倒是提升的，因为你省掉了很多通勤的时间，就能够避免中间被各种打断，也能够分配更多的时间去工作。

发现这个情况之后，我们觉得可能也不需要开一个办公室，所以在整个 2020 年到现在，我们北京办公室都是关闭的状态，最后把办公室退租了，所以现在处于分布式办公的状态。当然，最重要的事情就是沟通，如何让沟通最大化。现在的手段很多，有视频会议，因为我们是 Global（全球） 的状态，用的是 Zoom。

国内可能有些小伙伴会用腾讯会议，有 Slack 做即时的通讯，有邮件，所有的工作其实都是 GitHub 开源协作、Google Docs 作为文档协同的办公方式，在互联网时代其实提供了所有能够用于远程办公的工具。

所以我们并不担心协作的问题，但唯一需要灌输的一个理念是，远程办公它意味着是异步办公，要强调异步办公的重要性，同时能够以某种机制去激励每个同学的自我驱动性，我们基本上是用 OKR 的方式去给整个团队定目标。让每个人去定目标，只要确保每个人的工作是跟公司的目标吻合，至于你怎么去安排时间，怎么跟团队协调时间，都是相对自由的。

这样就会产生最大化的能动性，我们发现这个是很不错的效果，当然对我们招人有很大的挑战，就是招到的人的思想一定要跟公司文化相吻合，而且员工需要有很强的自我驱动的能力，如果招到一个不合适的，他进来就会拖慢整个团队的进度，这是第一个问题。

第二个问题是凝聚力的打造，远程办公虽然有视频，但是其实跟面对面还是不大一样。我们定期举行集体办公，我们在北京的团队执行的比较好，因为大家都知道中国疫情控制比较好，我们从去年五六月份就开始基本一个月或者一个半月就举办一次集体办公。可能是 2~3 天的时间，大家聚在一起一起讨论问题、一起吃饭，增进整个团队的协作能力。到了 2020 年的下半年，后来我们有 HR 同学加入，我们开始探索更多样化的一些手段，比如说云团建，基本上是每几个礼拜会组织一个云团建，这个云团建会有一个主题，比如说过年的时候会聊聊每个人的家乡和家乡的风俗，通过这种云团建的方式可以让团队能够更加互相了解。

除了工作之外，还能够加深一些相互了解以及增强整个团队的认同度，这是中国团队的情况。但美国团队因为美国疫情的原因，我们没有办法实行这所谓的线下办公或者集体办公。但我们今年有一个目标，希望把整个全球团队，在某一个时间点聚到某一个地方，大家集体办公。定时集体办公是一个很好的拉近团队凝聚力的手段。

分布式办公——自驱力才是最强王者

我觉得最开始不顺畅的地方是在整个中国团队从集体办公变成远程办公状态的时候，还是会有磕绊。因为大部分的中国员工适应了一个环境，习惯做事可能需要按某一个时间节点来，当一下子变成没有人监督的情况，很难能够自主地去做相应的事，我们发现有一些同学，在从集体办公变成远程办公的时候，整个效率在下降，或者换个角度讲，他可能跟不上整个团队的节奏。

在这种情况下，公司虽然是一个创业公司，但创业公司也有自己的容忍度，就是说我可以试错，可以容忍每个员工有相应的调整期，整个公司也会去配合员工并给予一定的帮助。但如果员工无法习惯，我们也不会勉强让他一定要待在这个公司里面，他可以选择更好的一个办公方式。这对创业公司是一个巨痛，会有一定的人离开，但它是一个短痛，它会筛掉那些自驱力不是特别高的，留下那些真正能够有自驱力的人。

咱们现在团队是有 40 多人，工程师比例接近 80% 。在工作管理中， Leader 怎么做，下属就会怎么做；CEO 怎么做，下面的人就会跟着是怎么做。

从我的角度来说，远程办公跟集体办公不大一样的地方在于你不应该设任何的条条框框，因为每个人因为是在家办公，每个人的办公环境不大一样，如果说我一定要让你 8 点 9 点开始干活，一直干到 5 点，这是不现实的。因为你在家会碰到各种情况，有可能家里面断网断电，或者是你有小孩，这些影响因素都会考虑在内，需要你的团队能够做到容忍环境变化。从 CEO 的角度来说，应该鼓励你的员工，如果你有什么其它紧急的事情应该先去处理其它紧急事情，再回过头来去按照你的规划做相应的事情。

我给你的是一个 Deadline，你在 Deadline 之前能够完成就可以了。很多时候，最开始可能很多人都会觉得我上班了，我应该跟所有人说一下“我上班了”，我下班了应该是跟所有人说一下“下班了”。但最后大家就会发现，CEO 不在乎你上班不上班，他只在乎你什么时候把这个做完。一旦你做了表率的作用之后，大家会知道整个公司的管理团队在乎的是什么。

我们在乎的并不是签到和打卡，是通过 Deliver（交付）好这种方式去向整个公司表达，这个团队究竟是什么团队。如果 CEO 变成了对每一个人我要看一下，即使是远程办公，也需要在某一个时间点去让你打开摄像头去看你在不在办公，其实你就把远程办公变成了一种变相的远距离的集体办公方式，它并没有达到你想做的效果。

所以更多的是 CEO 需要有能力能够去容忍，就是你能够容忍别人磨洋工，你才能通过这种方式去筛出真正有自驱力的人，让那些磨洋工的人在这种结果驱动的环境里面，把他的缺点暴露出来，然后让他去选择更适合他的工作环境。

StreamNative 的招聘新主张

是不是远程办公，或者会不会回到集体办公、混合办公，我觉得是跟每个公司的阶段有关系。如果是 100 人以下的团队，远程办公是很好的模式。当然 100 是我编的一个数据，我也没有理论，就是说在这种情况下，你招人的标准就是说基本上都有自驱力，有结果导向。因为远程办公，连面试都是远程的方式，我们怎么去考核标准？

我们会给应聘者下达一个任务，这个任务可能取决于你的职位是什么，如果你是开发核心的 Apache Pulsar 功能，我们会给他一个社区任务，这个时候你把任务丢给面试者，能够从某种程度上反映出他工作的状态，因为你不是在同一空间的面试场景，这个时候我们能很快地检验出他如何跟别人交流，如何去反馈他的进度，如何去表达和沟通。

所以远程办公让我们的招聘方式在改变，这就意味着我们筛选人的标准变了，我们很容易就能筛选出比较合适的人。另外，我们很多时候招人是从社区来。社区不仅给你提供了用户、客户，最后还给你提供了未来的同事，因为你在社区里面经过了长期的沟通交流已经知根知底了，你知道他的工作方式是什么，所以招进来的成本就会特别低，甚至你面试基本上都不需要什么时间，因为大家都很熟悉。

目前我们在进行大规模的招聘，从 40 个人到 80 个人，再到 120 人，因为整个公司会有层级的概念，并不是所有人都像你想象的那么自驱，这个时候怎么去做这个事情，你的制度就 OKR 的这种方式，怎么去给团队设定目标，怎么去驱动，我觉得这是一个根本的核心的事情。我需要保证我的整个 Leader 成员就是管理团队基本上是自驱型的。不管是再集体办公还是远程办公他都可以应付自如。

对于自驱力相对比较低的，比如说应届生，或者是一些工作经验比较少的这些人，我们可能会演化出这种混合的模型，比如可能会在不同的城市，开一个相对比较小的办公地点，我们叫 Hub，让在该城市的这些同学可以定期到 Hub 里面进行集体办公，通过这种方式它会变成一个混合方式，大部分的主体整体还在远程办公，但是还是会提供相应的办公场所，让我们同学能够聚在一起产生凝聚力，也能够帮助他去提高自驱力，改善工作效率。

关于 StreamNative

StreamNative 是一家开源基础软件公司，由 Apache 软件基金会顶级项目 Apache Pulsar 创始团队组建而成，围绕 Pulsar 打造下一代云原生批流融合数据平台。StreamNative 作为 Apache Pulsar 商业化公司，专注于开源生态和社区构建，致力于前沿技术领域的创新，创始团队成员曾就职于 Yahoo、Twitter、EMC 等知名大公司。

点击阅读原文，立即投递简历～