0%

开源思考

目标

首先,开源不是活雷锋, 开源的原始动力就是要追求盈利, 今天,所有的大型开源软件,背后都会有一家或几家商业公司在运作在维持, 如果没有商业利益, 首先社区就会没有动力, 仅靠程序员的热情,是无法支撑一个社区高速成长。只有拿到商业价值后, 开源才能进入正轨,才能正向循环,自我升级换代。

另外, 对于像主航道上的技术, 我个人比较支持全力进行开源, 争取成为行业的主流标准,在我们公司, 有几块可以全力争取的, 1. 微服务; 2. 大数据处理; 3. 数据库; 4. 容器与调度;

但今天,业界已经在每个项目上有现成的开源标杆, 我们需要从这些现成主流开源标杆中拿下行业标准。现在公司很多开源做法都是融入到其他社区,其他大的生态中,帮助其他生态来发展, 但没有很强理念来打造自己的生态。对于这种做法,个人观点是当我们能力不强的时候,就这么玩,当我们能力强的时候,我们的目标始终是我们要成为行业标杆, 领头羊, 个人觉得这几个主流领域,公司都是完全有机会成为标杆,成为主流。

结论: 成为行业标准 盈利

挑战

开源如何盈利? 在回答这个问题前, 先看别人是怎么挣钱

现有开源盈利模式 云厂商, 云厂商,今天是开源领域中, 挣钱最多, 也是商业化最成功的模式。

aws, 微软,阿里巴巴, 腾讯, 华为,通过将开源软件包装, 做成软件即服务, 为开源软件在稳定、性能、成本、维护 上提供增值服务, 让用户能够更简单更便捷的使用开源软件。

今天,阿里巴巴数据库部门, 基本上盈利点全是来自开源软件, 我们自己的结果已经证明, 开源软件是可以挣钱。

软件公司(或咨询公司)

上一代的开源的运作模式,就是靠为其他公司提供 解决方案或咨询或技术支持 服务。 其实类似今天我们 售卖专有云的方式, 将软件打包成一个解决方案, 售卖给客户, 客户支持

Cloudera, Hortonworks, 甚至Redhat。

这种盈利方式,最大的弊端, 需要强大的销售, 超强的服务能力, 是一个2B 的生意, 需要的是人力上的大量投入, 很难获得长尾效应, 将一个方案横向自动扩张到更多的用户。

别人开源, 我们是不是收割就好了 今天要看到几个趋势:

趋势1: 数据库领域未来是开源软件天下

Gartner 研究报告称,70% 的新应用都将在开源数据库中开发,2018 年之前,50% 的现有商业数据库将转为开源数据库。截至今年上半年,数据库开源比例已经从四年前的 35% 上升到了 45%。

趋势2. 成功的开源软件越来越集中到云厂商中去

看看cncf 基金会, 基本上每个开源软件的背后都是云厂商, mysql 的拥有者oracle 也要推出云服务, spark 背后是databricks, k8s/tensorflow 背后是google, mongo 背后是mongodb 公司。

趋势3. 拥有开源软件的云厂商不会纵容其他公司进行收割

MongoDB修改MongoDB 协议, 从AGPL 3.0 修改为SSPL, 就是在堵住其他公司收割开源软件的路径。 RedisLab 也在修改协议,增加商业部分。 站在人性的角度, 没有人会愿意,自己的幸幸苦苦种的果实,被其他人给摘取, 肯定会想办法阻止。 今天国内公司在知识产权上还不够重视, 但未来,所有人还是要按规则行事。

结论:

当前别人的开源软件,我们是可以收割, 但未来(也许3到4年后)开源软件是无法收割的。

但一个数据库的开源软件需要好几年的投入,才能有一些结果。 mysql 至少用了10年才成为一个广泛认知的数据库, postgress 始于1986年, 研发超过30年。即使是最新的tidb, 也是从2016年就开始, 到今天为止,用户数也是极少。

策略 当市场出现新开源软件端倪时, 大公司直接采取 收购/山寨 的方式, 直接获取结果, 类似过去 大公司对创新一直采取的跟随战术。

当还没有先行者,或者还没有验证市场时, 采用小分队探索。

商业模式?

opensource 会不会丧失核心竞争力问题

竞争对手拿到开源后, 技术实力大增。

问题:对于像dubbo 这样的产品, 后续会把pandora boot/config server/diamond 等多个产品开源, 这样,对于小的电商平台,技术实力会大增, 对于京东也能支持更高的交易量。

回答: 对于电商来说, 核心竞争力, 在于 taobao/天猫是流量入口, 而不是技术。 另外,像京东, 腾讯这些电商系统,他们都有自己的实现。 对于像蘑菇街/唯品会 等小电商, 他们会技术大增, 但业界这些技术已经都有开源版本, 这些开源的版本迟早会成长起来, 只是一个早晚的问题 和谁来主导和参与的问题。

问题: 对于像华为/腾讯 这样的大公司, 拿我们的开源技术,封装产品和我们竞争, 比如现在华为,拿着dubbo 推出fusionstage 和我们edas 竞争。

solution:首先,开源的技术分为2大类,

第一个是辅助性的项目,比如工具类的,这些开源了, 对我们也没有多大的损失, 比如一些sdk或工具, 如fastjson, tair-client, spring-boot-starter之类的项目,

另外一类, 会涉及很多核心技术或对应有云产品, 对于这些项目这的确是一个问题, 但我们可以从几个方面来解决这个问题, 化劣势为优势:

持续创新, 如果我们团队拥有足够的持续创新能力, 越来越多的创新会成为我们的新的竞争力, 我们比对手更快的切入用户的痛点和下一代的布局, 我们的云产品必然会更快的响应开源的创新。 但持续创新是一件非常困难的事情,有2种方式达到这种能力, 第一,投入足够的人力支持, 并不断培养这些团队成员接触足够业界新的知识;第二, 让社区活跃起来, 当社区参与的contributor达到一定的数量后,众人拾柴火焰高, 但参与的人过多后, 会导致另外一个问题, 对社区的掌控能力会被大量削弱,如果保持社区一定的掌控能力, 则又会让社区的其他contributor只能参与边缘性工作, 创新的能力大大削弱。这需要一个不错的取舍和平衡的能力。 定位问题 开源重要的是卡位, 在一些功能上有实现, 实现的质量并不是关键, 更有甚者, 可以设计一些缺陷, 为云产品版留下提升空间。而云产品的竞争优势是稳定性和成本,如果保持云产品的这两点优势, 云产品的竞争力根本不会下降很多。因为打动用户的还是稳定性和成本, 而开源正好保证了上手容易。 增值服务 3.1 像rocketmq 这样, 把core 开源出去, 让外围系统并没有开源也是一种思路, 通过外围系统,提供完善的增值服务, 这些价值会直接给阿里云云产品带来竞争优势。不过,这种方式的一个门槛是, 外围系统也是需要沉淀和积累的,如果门槛较低,竞争对手,通过挖团队成员或实现外围的设计,那这种竞争优势也会丧失。 3.2 接口化设计, 内部是高性能, 面向海量客户端的设计, 外部是一个简化设计, 大家都实现同一套接口, 内部实现能大幅降低云产品的成本, 但外部竞争对手只能通过开源的简化设计, 其成本必然会高出一个量级。 这个方案有2个难点, 第一, 有的时候,开源项目为了追求开发速度或者抢占开源市场, 放弃了接口化设计的方案。 第二, 对架构师的要求比较高。 这两个难点,第一个难点可以在后期弥补, 所以归根结底还是要求我们架构师有很强的设计能力。 3.3 利用组合拳的方式,在开源项目种增加大面积埋点, 这些埋点和外围系统深度打通, 让外围系统能够第一时间做一些高附加值东西 提高项目的复杂度 当项目的复杂度越高, 我们对项目的把控能力就会越大。 将一些模块和另外一些模块,错综复杂的纠织在一起,将项目做大; 比如埋点一个项目, metrics 一个项目, rpc 一个项目, rocketmq 一个项目, taokeeper 一个项目, 而我们一个dubbo项目将依赖多个模块, 当项目庞大后, 一个中型公司都无法深度改造,即为成功, 但我们核心原则:让项目傻瓜化, 使用起来超简单, 还要留下一些模块,就是给开源社区去设计和实现的, 要让别人也有饭吃。

  1. 内部产品割裂

在回答这个问题前, 先解释3个概念: 开源体系, 内部体系, 云产品体系, 3套体系的人, 必然会有3套不同的做法,因为3套人员会有不同的侧重点,

开源体系, 最核心的理念是卡位, 在某个功能上有一个快速的实现, 这个实现可能并不是最优的,但可以解决问题。 其面向的客户是大量的创业公司, 小型公司, 需要的是能够快速将一个系统搭建出来,来满足业务的快速迭代。 而一个成功的开源项目通常都是一个傻瓜化的项目, 因此也需要足够的易用性。 内部体系, 需要的完全的掌控能力, 能够在各种量级, 轻量, 中性, 海量上都能解决问题, 对性能和成本的追求 对易用性是没有什么追求。 并不是所有的创新,都是由内部触发的, 只是高精尖的需求是由内部驱动的。 云产品体系,稳定性第一, 无论是阿里云的每个产品对必须为自己的稳定性背一定的指标, 另外, 可靠性也是打动客户最重要的元素, 这个是最重要的1,没有这个元素, 后面再多的功能都是无效的,另外, 成本第二, 客户需要因为使用我们的云产品而降低维护成本 ,

我想表达的是, 开源体系和内部体系 肯定是割裂的, 是很难统一起来, 首先, 需求是不一样的,因此解法也是不一样的; 其次,从上一节核心竞争力上,内部体系很有可能也会和开源不一致。比如, google的内部系统和开源系统,是完全不相同, google 不会把外部开源系统直接拿过来,也不会把内部系统直接开放出去,都是经过消化和吸收。

一个云产品, 必须要要经历内部使用过后或者开源大量使用过, 才能进入云产品, 因此云产品体系, 可能是靠近开源体系, 也可能是靠近内部体系,这个是由商业化来决定的, 比如emr 就是完全靠开源, 中间件基本就靠内部。 不过,目前现在阿里的做法,基本上都是云产品体系和内部体系较为接近; 内部先使用, 使用好了,然后开始转为云产品, 因此,内部需求和云产品需求基本上能够吻合在一起, 另外一个重要重要的原因,基本上2者都是一拨人在做, 做完内部做云产品, 或者云产品做完向内部推广,或者二个交叉来实现。

具体解法:

一个项目, 如果在架构师设计和产品经理,这个层次是大家share,产品经理控制需求, 架构设计师进行顶层设计,在顶层设计一致的情况下, 在一些细节上,为了追求核心竞争力和增值服务,可以差异化。 比如定义好接口,不同的人,实现不同的方案。

  1. 人才冲突

因为有2套或3套 实现团队, 开源团队, 内部团队, 云产品团队, 因为,做开源的同学,会专注于技术,不用每天操心一些琐碎的日常运维, 也不用担心去客户现场,也不需要投入大量精力做一些重复性工作, 会让开源团队成员的自我认同感和成就感不断爆棚,会存在慢慢将内部团队或云产品团队人才吸引过去。

灌输一个理念, 家家都有本难念的经, 做开源,需要更多的精力和社区沟通,写邮件交流, 对英文要求会更高, 也会要求一定的表达能力, 并不是十全十美的项目。 定期轮岗机制, 相互直接盘活人才。

  1. 如何成为标准

分为3个步骤, 第一,赢得信任,第二,掌控社区, 第三,赢得战争

5.1 如何获得社区信任

第一原则是, 消除外部顾虑, 外面中小客户,最害怕的事情就是阿里后续不支持项目, 直接取消项目, 未来不发展。 如何打消外部用户顾虑, 下面列举几个手段: 1.1 将项目捐献给一些著名的基金组织, 比如apache基金会, eclipse基金会, linux基金会,软件自由管理委员会等,因为这些组织运营的第一原则都是社区大于代码,社区会尽量让一个项目不会受一家公司的控制。 1.2 不断的投入人力去经营社区, 社区就像一颗树, 是从一颗小苗慢慢成长起来, 需要不断灌溉和施肥。 积极回答社区的问题, 定期发布milestone, release 版本, 定期组织线下活动, 搞多了,慢慢就成长起来了, 公司的contribute 慢慢大家就看到了,就会放下戒心。 1.3 发展云产品, 如果云产品使用了开源技术,也就客户已经在为这项技术进行买单, 买单后,也就购买了一些服务, 是不能任意中止服务。 1.4 未来公司成立阿里开源基金会, 对阿里的开源项目分等级, 对于黄金项目,对外承诺即使阿里不用了,也会保证3年的技术发展。 要留一些事情给其他人做, 不能全部把好活,快活给做了, 一定要留一些模块给其他人来设计, 尤其是和用户使用相关,要让其他人也能在这个里面有收获。 一定要重度参与社区的建设, 一个社区的活跃度,是很容易通过代码提交频率,社区答疑速度, 文档完善程度, release节奏等指标看出, 只有保持足够的社区活跃度, 社区才能让别人也开始参与进来。

5.2 开源产品控制权争夺

facebook的策略是, 如果不是facebook 掌控的, facebook是不会参与社区的建设, 不会为别人的项目做贡献。

google 在公司在开源上, 重兵投入在一些关键路径上, 旨在控制一些标准或api, 而且基本上,都是降维攻击,迅速征服市场。

做任何一个开源产品, 都必须直面开源产品控制权的问题, 想好一系列策略来面对开源产品控制权;另外对开源控制权把控特别严格,又会削弱其他人的参与程度。 这是一个非常tradeoff的问题。

来看看flink社区的做法, 非常鼓励其他公司或个人,为社区做贡献,现在是非常开明和开放,而且积极与这些contributor进行讨论, 也很积极提升contributor到committer 这个级别,但就是不提升committer到pmc, 不是pmc也就没有投票权,如果哪天社区真正到了投票pk的时候,基本都是他们说了算, 现在就算发pmc 也只会发一个人, 绝不允许一家公司拥有多个投票权。

来看看spark社区的做法, pmc里面有一半的人是databricks,而且在sql这个核心模块中, 就只有databricks的pmc, 基本上databricks 决定了spark的走向。 而且现在,提升的pmc或committer中, 有一半的人是databricks。

有几种玩法:

真正掌控一个社区, 需要培养一个灵魂人物, 这个灵魂人物, 就是社区的精神象征,通常这个社区就是这个灵魂人物创建者,他在这个社区有足够的影响力, 比如calcite的Julian, storm的Nathan, vue.js 的尤雨溪, 这种例子数不甚数, 这个灵魂人物决定了社区的高度, 如果灵魂人物不够powerful, 那社区的影响面就会比较小。另外,这个里面有一个约定俗成的东西, 就是开源社区会特别尊重社区的创始人, 大家如果有分歧,要么自己成立项目单独再去做, 很少在这个老项目里面,抢夺控制权。 这个灵魂人物,需要参与社区的方方面面, code review, 设计讨论, 用户答疑, release note 等等, 基本上,如果是一个人来做, 那这个人就是一个超强执行力的人; 另外这种项目都是短小精悍型项目, 基本上一个牛人可以把控住项目的主体。 如果是我们来做这个事情, 我们可以通过一个团队来塑造这样的一个人, 来达到超强能力的一个人。 对投票权的授予是非常小心的, 基本上就不怎么授予投票权, 像flink的做法。 一家公司人员投入上的绝对碾压, 会让其他公司的人感到虎口夺食是相当不容易的。

5.3. 如何和开源其他项目竞争

在中国市场上, 坦白讲,我比较有信心,

关键,如果要成为行业主流, 我们如何赢的docker/spring/kafka的竞争,

重兵投入是第一个前提。 创新是根本,借助换道超车,挖掘用户一个新的痛点后,迅速实现并落地, 并借此进行炒作一个概念, 洗一波概念。 慢工出细活, 想想qq, 为什么能够赢得im的战争, 就是不断借鉴对手的优点, 不断优化细节,做一些小创新。 中国人的执行能力是优势很大,另外,小细节的创新也是问题不大(看看深圳原来的山寨机)。 对于像docker/spring/kafka这么强大的对手, 一开始就要想好长久打算, 持久战。

打法和执行路径