导读:
拿自由/开源软件/硬件去挣钱?“挣钱嘛,生意,不寒碜”(让子弹飞),但如何“站着,还把钱挣了”?为何用户吐槽裤子都脱了就给我看这?为何会被人怼“既当又立”?为何Google明令禁止员工使用某些协议的开源项目。当公司开源项目遇到外部开发者,为何把工程师关进小黑屋由律师监视进行开发?你以为下载了代码就能为所欲为?小心下载一时爽,官司火葬场。还能不能回到当初那个纯真年代,单纯的享受写代码的快乐了?历史的车轮滚滚向前,发展中出现的问题只能靠发展来解决。
自由/开源是一种理念和价值。当它得到很多人的认可,就会演变为影响力(impact)和话语权,进而反过来为理念和商业化加持。商业案例也许在几年内就能大起大落,而其背后的理念和价值则会穿越时间前行。
目录
- 前言
- 开源项目商业化的前提条件
open core 商业模式
- open core 的基本模式
- 宽松授权模式的利弊
- open core模式的取舍
dual license(双授权)商业模式
- dual license 并不新奇
- dual license 的基本模式
- dual license 与 open core 的区别
- dual license 公司以及争议:嘴上都是主义,心里全是生意
- 走自己的路让别人说去吧
- 如何获得外部贡献者代码版权
- 当公司无法获得外部贡献者代码版权
- 律师监视工程师在净室(clean room)封闭开发
- 下载一时爽,官司火葬场
专业服务(Professional Service)商业模式
- 从Cygwin到Redhat再到IBM
- 坚持情怀,站着把钱挣了
托管/应用商店(hosting/marketplace)商业模式
- 人之初,性本懒,钱难挣,屎难吃
- 当自由/开源软件被云服务厂商白嫖
利用硬件的开源软件商业模式
- 捆绑销售
- 给有趣的灵魂找个好看的皮囊
自由/开源硬件的商业模式
- 硬件不是代码,也能遵循开源协议?
- 欧洲核子中心(CERN)的开源硬件协议
- Apple和特斯拉都在用的硬件商业模式
- 不要山寨!不要山寨!不要山寨!
- 不忘初心
前言
就像人不恰饭会死,任何一个项目(包括个人爱好者的业余项目)没有持续的投入也会死。
取得商业上的成功,对于自由/开源软件/硬件项目来说并不是精神分裂的表现,反而是非常重要的。商业成功会产生收益进而继续支持项目的开发。纯粹用爱发电很难长久。
从自由/开源软件/硬件诞生的那一刻起,人们就在不断探索围绕它的各种商业模式。好在现在已经2021年了,在互联网上不难找到人们总结的各种开源商业模式。下面的内容并不完全是原创,而是结合了互联网上前人的一些文章(三个链接见文末)和自己多年在开源/自由软件/硬件领域的实践所见所想。内容不一定100%正确,仅供参考。
下文中会提到“授权”,“协议”,“license”这些词,他们都是指在你下载或者购买软件/硬件时需要同意的那份文档。虽然开源软件与自由软件在定义上并不完全重合而是需要区分的(详见RMS的信以及之前的文章),但当前互联网语境下,两者基本指向同类事物,下文不再严格区分。
一. 开源项目商业化的前提条件
在谈怎么赚钱(商业模式说白了就是怎么赚钱)之前,需要先谈必要条件(非充分)。就像要谈如何哄女朋友开心之前,首先你需要有一个女朋友。
条件1:用户基数足够大
事实:大多数开源公司开放了如果不是全部也是大部分代码/文档,而绝大多数他们的用户都不会付一分钱。大多数开源公司能做到的转化率(把免费用户转化为付费用户)都是个位数,甚至是很小的个位数。
这就是为何需要你的项目接受度(也就是用户基数)必须足够大,这时即便是很低的转化率也能产生足够的收入。而提高项目的接受度需要在推广方面大量的投入,这也是为何今天很多流行的开源项目都是来自大公司 (雅虎的Hadoop/HDFS,Linkedin的Kafka,Google的Kubernetes), 大学/学术界 (Berkeley的Spark),或者有大风投支持的创业公司。
条件2:得到社区的认可
这个条件的意思是:当用户对项目有问题需要寻求帮助,或者有定制化需求时,你应该是第一个被想到要求助的人。如果你就是开源项目的作者或者主要贡献者,那么一般说来不在话下。
当你不是项目作者/主要贡献者时,你仍然可以尝试商业化你的服务。也就是说,虽然你并没有创造和贡献一个十分流行的开源项目,但是如果你对一个流行的开源项目玩的66666,大家公认你是这方面的专家,那么你也是有可能提供商业化服务的。这方面的例子是,(合并前) Hortonworks公司(市值/估值$1.23 billion, 营收$262 million , 5倍),Cloudera公司 (市值/估值$1.73 billion , 营收$367 million, 5倍)。这两个虽然都是搞hadoop的公司,但他们并不是hadoop项目创建者。市场对他们的估值并没有大大超出营收,也许是为了更大更强,Hortonworks和Cloudera已经合并。
作为对比,项目的创建者、主要贡献者具有更高的商业成功潜力,因为贡献和能力会被天然的认可。这方面的例子是Elastic公司(市值/估值$4.59 billion, 营收$160 million, 29倍),MongoDB公司(市值/估值$3.97 billion, 营收$155 million, 26倍)。这两家都是各自开源项目缔造者和围绕开源项目的商业公司。市场对他们更加看好,估值远超营收。
下面正式聊各种围绕自由/开源软件/硬件的商业模式。
二. open core 商业模式
open core 的基本模式
顾名思义就是只开源核心(core)部分,而一些周边是非开源的而且是需要付费的。周边的作用可以是:
- 增加用户的易用性,比如用户界面。帮助用户协作。或者干脆就是自己部署了云供用户远程使用,无需下载安装。
- 大规模商用所需要的周边。可扩展性,安全性,管理性,系统集成,性能监控,备份/恢复等。
- 为一些有需求的用户专门定制开发的周边。
严格和狭义的讲,open core模式的公司所用的core部分的代码,开源社区和付费用户应该是同一套代码。并没有开源一套core代码,付费是另一套写的更好,性能更强大的core代码。open core这套core代码的授权模式(license)是可以很宽松的(very permissive license),比如Apache 2授权,拿去商用完全没问题。也就是任何有能力围绕这套core代码做付费周边的公司都可以做,不光是这套代码的开发者可以做。
宽松授权模式的利弊
如果采用很宽松的授权模式,别人可以自由的拿去进行非开源的商用,项目开发者还怎么挣钱?的确宽松授权模式有这样的弊端,但也有好处,其是一把双刃剑。最大的好处就是大大提高你项目的接受度。之前说过,项目的接受度对于商业成功十分关键。没有大量用户,一切都无从谈起。而授权模式太严格的话,比如像“病毒性质”的GPL,AGPL,对于项目接受度会产生一定负面影响。因为有些人/公司会对采用这些license的项目敬而远之(后面会说到Google),因此项目的接受度也就往往不如宽松授权模式的项目。采用宽松许可证获取大量用户,再加以项目创始人/主要贡献者的独一无二的地位,才会有较好的商业化基础。
open core模式的取舍
open core模式的好处是开源和非开源模块界限分明,难在取舍和度的把握。如果开源的部分太弱,用户觉得鸡肋(裤子都脱了就给我看这?),那么项目的接受度就会受到影响,商业化也就无从谈起。如果开源的尺度太大,那么显然就会影响非开源周边模块的售卖。
有时候人们会把open core模式和dual license(双授权)模式归为一类。严格来说,open core模式和dual license(双授权)模式从理念上和实践上是完全不同的。把他们归为一类,可能原因是很多公司在商业上采用open core和双授权的混合模式,令外人难以区分。下面就先来讲讲纯粹的dual license(双授权)模式,以及它和open core模式的区别。
三. dual license(双授权)商业模式
dual license 并不新奇
“双授权”这个名词乍一听不明觉厉,但其实没那么玄乎。这里用一个也许不太恰当的例子谈谈我的理解。这种模式的本质就是“我的地盘我做主”,“我的作品我做主”。比如你在社交媒体上发了一张自己拍摄的很漂亮的照片,你的朋友争相转载和欣赏,你会很高兴,也并不会想着向下载和欣赏的朋友们收钱。但如果这时一家全国性的大媒体把你的照片用在了他们新出版的一期有关的文章里,你是不是就觉得他们凭什么白用我的照片?于是在你的脑海中一种朴素和原始的双授权模式就诞生了:个人用于欣赏和交流免费,商业组织使用需要付费。
当然扩展开来你也可以为你自己的作品定义一个“千人千面”的授权模式,比如把个人,10人以下企业,100人以上企业等等区别对待,所谓混合授权或者多授权。
dual license 的基本模式
双授权模式的开源软件一般会选取一个非常严格的开源协议,比如AGPL。粗略来说,该协议要求:如果你要用这个开源软件,那么当用了这个软件的产品(实物产品或者云服务)交给客户时,你也必须附送客户一份该软件的源代码(包含你对软件的修改)。这种协议意在严格维护人们对于软件的四个自由:自由运行程序、自由获得源代码、自由发布复制程序、自由修改程序并将自己作出的改进版本向公众发行传播。这四个自由,是自由软件运动发起人RMS给定义的。这里并没有限制软件的商用。如果你遵循软件采用的开源协议,商用完全没有问题!
但很多公司虽然想使用某AGPL的开源软件打造商用产品,但并不想把源码连同产品(实物或者云服务)一起交给用户,因为传统商业公司还希望对自己的产品在技术方面进行严格保密。这时公司就可以看看那个开源软件公司是否可以以非开源协议授权那套代码。其背后的逻辑就是,如果开源软件公司拥有开源软件的全部版权,那么它可以自行决定对何人采用何协议。例如采用AGPL协议开源软件的代码,对于不想接受AGPL协议的用户则采用普通的付费非开源授权(license)。而这个非开源授权(license)不会再要求客户交付产品给自己的客户时附送源码。对于开源软件公司,这即是双授权模式。
dual license 与 open core 的区别
由此可见,双授权模式下,代码库不存在像open core模式那样开源部分和非开源部分的划分。这是它利于被用户接受的一个优势,因为如果用户同意开源协议,即可得到全部代码,不存在只得到部分core代码而仍需要付费周边代码的情况。当然,缺点是极大地方便了“白嫖”党。
dual license 公司以及争议:嘴上都是主义,心里全是生意
采用双授权模式比较成功的有两家公司,MongoDB和Elastic。前者最初采用对云服务限制较为模糊的AGPL协议,后期变更为对云服务限制更加严格和明确的的SSPL协议,后者最初采用宽松的Apache 2.0协议,后期也变更为SSPL协议。网络上关于他们采用的开源协议以及后来的协议进一步严格(SSPL协议)有较多的争论。大家可以搜索"MongoDB SSPL协议"。
争论的焦点一般会落脚在:“你采用变态严格和传染的AGPL协议或更严格的SSPL协议的目的就是强迫不想遵循这个协议的人购买你的非开源license,这是打着开源的旗号赚钱,目的不纯!”借用谍战剧潜伏里谢若林经典语录:嘴上都是主义,心里全是生意。
我个人的观点是:以上的攻击说辞大都来自想要白嫖的公司和个人。这里的白嫖是指:想使用AGPL/SSPL协议下的软件,但又不想按照协议向自己的用户公开自己的代码及所做的修改。采用AGPL/SSPL协议,客观上极大地促进和保障了人们对于软件的四项自由权利。至于采用这种开源协议的动机是什么,我觉得外人无权也无法猜测。每个人都有自由选择的权利,你不喜欢别人采用AGPL/SSPL协议,可以不用这个软件,而不是诟病别人采用这种协议。比如Google就有明确的公司级别的指导,哪些开源协议的软件可以用于Google的工作,哪些不可以。APGL及其类似协议SSPL首当其冲:https://opensource.google/doc...
还有一种攻击说辞是:既然你已经采用AGPL/SSPL协议来坚持软件自由,那么就不应该售卖非开源的license,因为非开源license本质上与软件自由的目的是背道而驰的。
这种说法的确是有一定道理。但法无禁止即可为。也许双授权很难站上自由软件运动的道德制高点,但它在客观上以开源协议的方式向世人展示了一种技术的软件源代码,并且允许认同开源协议和自由软件的人自由的修改和使用,这本身已经是对这个世界很大的贡献。至于同时售卖非开源license,我个人觉得完全OK。因为软件开发的人力成本是很高的,你是希望他们收入很少或者没有收入而难以维系开源软件开发呢?还是他们可以靠售卖非开源license来反哺开源软件的持续性开发呢?
走自己的路让别人说去吧
从上面的分析可以看出,采用类似AGPL/SSPL协议进而采用双授权模式,有时候会产生“两边不讨好”,被人说“既当又立”的效果。一边是想用这款开源软件的个人和公司(尤其大公司)对于协议的严格限制和传染性有顾虑,比如Google干脆明令禁止员工在工作中使用AGPL/SSPL协议的软件。另一边是自由软件社区的原教旨主义者或者伪装成“原教旨主义者”的“白嫖”党,对于你售卖非开源license会颇有不齿,说你的非开源license与自由软件精神背道而驰,目的不纯。因此,采用AGPL/SSPL协议的双授权模式,其实不太利于软件被广泛的接受和认可。
那为何有些项目还是要坚持采用这种模式呢?比如MongoDB和Elastic,还有我们软件无线电领域的srsLTE(现在改名叫srsRAN了,因为5G来了,已经不只是LTE了)。个人觉得,就是因为这些项目开发水平高,在开发者心中的地位很难撼动,具有很大的不可替代性。所以有水平就是任性,就是喜欢看你们不爽我但还不得不和我合作的样子。对于商业用户来说,合作一般即意味着会购买非开源license。
如何获得外部贡献者代码版权
双授权模式需要注意的是,你必须完全“拥有”那个软件的版权,才能决定如何对外授权那个软件。当你的项目有许多外部贡献者时,情况就会变得复杂起来。比如Linus本人就无法声称拥有Linux内核软件的版权,从而自己决定如何对外授权Linux内核。这是因为Linux内核项目现在已经有太多太多贡献者了,每个贡献者只拥有自己所写的代码的版权,并不拥有别的贡献者代码的版权。因此Linux内核项目本质上是所有贡献者共有的,而不是属于某个人或者某个公司,也就无法走双授权模式。Linux基本已经是全世界的公共产品,已经具有公共属性。
因此采用双授权模式的项目大都是公司完全拥有项目的完整版权。想做到这一点,最直接的办法是全部代码都由公司员工编写,没有外部贡献者,版权完全属于公司。当有外部贡献者想要提交代码时,通常做法公司会要求外部贡献者签署一份CLA(Contributor License Agreement)协议。签署这份法律协议意味着外部贡献者同意公司也拥有对他代码的版权,并且公司有权决定任何使用方式(包括更换license对外授权卖钱)。这样,即便项目有外部贡献者,只要他们都签署了CLA协议,那么公司依然拥有项目的完整版权,进而可以走双授权模式(或其他任何模式)。和CLA起到类似效果的还有 DCO(Developer Certificate of Origin),DCO是一种“轻量级”的CLA实现,也正被越来越多的项目所采用。具体CLA和DCO的对比已经超出本文商业模式讨论的范畴,网上可以找到更多的讨论,比如:CLA vs. DCO: What's the difference?
与外部贡献者的关系,也是双授权模式不容易被广泛认可和接受的另外一个原因。外部贡献者可能会想:我自愿免费贡献了代码,你转身就拿去赚钱?但有时候,这也是项目拥有者所希望达到的效果。因为和外部贡献者进行技术讨论,合并他们的代码,并且长期维护(外部贡献者可能几年后完全离开了这个领域),是需要资源投入的。而当外部贡献者很难贡献高质量(被项目主导者看得上)的代码时,和外部贡献者合作是得不偿失的。有些项目的作者本身就是这个领域的王者,水平相当之高,当然也对于外人随便进来项目里裹乱并不感冒。
当公司无法获得外部贡献者代码版权
如果由于某些历史原因,开源项目里包含了某些外部贡献者的代码,但他们并没有签署CLA,这时候如果项目所属公司想要出售非开源license,有三种选择:
- 联系外部贡献者,补签CLA。签署后,公司即拥有了项目的完整版权,可以自行决定对外授权模式。
- 如果外部贡献者不同意签署CLA,或者联系不上,那么可以尝试从项目里去除外部贡献者的代码,去除后,公司即拥有了项目的完整版权。
- 如果外部贡献者的代码十分关键,无法去除,可以采用净室(clean room)/(Chinese wall)模式,由公司内部人员开发类似功能的代码来替代外部贡献者的代码,然后公司即拥有了项目的完整版权。
律师监视工程师在净室(clean room)封闭开发
净室(clean room)/(Chinese wall)开发模式在美剧“Halt and Catch Fire”中有详细展现。具体来说,你需要找一个公司内部没有看过那个外部贡献者代码的工程师,一个房间,一个律师。然后工程师向律师写一份声明,声明自己从没有看过那个外部贡献者的代码。所以这个工程师一般说来需要新招募,因为公司内部工程师很可能都看过外部贡献者代码。然后那个工程师和律师一同进入那个房间(clean room),房间断网或采取其他措施保证工程师在房间内工作时看不到那个外部贡献者代码。工程师在律师的全程监视下,经过一段时间完成类似功能的开发,并替换外部贡献者的代码。如果不采用净室(clean-room)/Chinese-wall开发,那么万一将来被人起诉你在售卖的非开源协议软件中使用了开源协议代码(那个外部贡献者的代码),就会面对法官百口莫辩。如果采取了净室(clean-room)/Chinese-wall开发,那么你就可以请当初的律师向法官解释整个开发和代码替换的过程,从而避免输掉官司。
下载一时爽,官司火葬场
是的,用了开源软件却不遵守开源协议是可能吃官司的。早期最有名的官司就是围绕思科收购的Linksys公司的WRT54G WiFi路由器展开。该WiFi路由器采用了Linux操作系统,但拒绝公开路由器内固件的源码,违反了Linux所采用的开源协议,被人发现并告上法庭。最后思科败诉,公开了路由器源代码,由此也催生了最为广泛使用的路由器开源操作系统项目OpenWRT。在欧洲,主要是德国,每年关于违反开源协议的官司都有不少。开源软件的作者或者相关的组织(比如FSFE--自由软件基金会欧洲)会去追踪这样的案例,并和专门的律师一起对违反协议的公司提起诉讼。在美国自然是FSF(自由软件基金会)以及一些其他民间组织(例如Software Freedom Conservancy)拿起法律武器捍卫软件的自由。这些自由软件组织一般都是非营利性的,运作主要依靠捐款,而捐款的公司不乏一些大公司。所以不要认为自由/开源软件开发者都是散兵游勇,可以随便欺负,站在自由/开源软件背后的是拥有一定财力和专业律师团队的自由软件运动组织。
四. 专业服务(Professional Service)商业模式
从Cygwin到Redhat再到IBM
专业服务模式的典型代表现在是红帽子Redhat(被IBM以340亿美元收购)。以前的Cygwin(在Windows下模拟GNU软件运行环境)其实更早采用这种模式,Cygwin也许是最早采用“卖服务”模式并取得很大成功的开源软件公司。后来Cygwin被Redhat收购,不确定Redhat现在的模式是否是吸纳自它收购的Cygwin。
卖服务模式可以比较容易的开始商业化,毕竟如果你的软件有很多人用,那么在使用过程中遇到问题,其中一部分用户会寻求你的帮助,这时你就可以开咨询公司提供咨询服务了。缺点也是显而易见的:
- 如果你的用户需要你的服务,无论是安装、运行还是配置等,那么这其实是和软件的易用性有点背道而驰的。因为如果软件十分容易部署和使用,那么理论上就不太需要你的服务。
- 这是一个重人力的模式,并不容易扩展和大规模复制(产品尤其软件产品,一但定型就很容易大规模复制)。本质上咨询服务出卖的是公司内部工程师的工作小时。想要提高公司营收,就必须招募更多工程师出卖更多小时。而越多投入在服务上(进而提高营收),则越少投入在开发上,又是一对矛盾。
- 产生稳定的付费服务收入,你需要一些公司将你的软件用于他们稳定的核心业务,且公司权衡之下乐于将服务外包给你,而不是培养自己的专门维护团队。
基于以上原因,卖服务的商业模式并不太被资本看好。因为它利润率比产品要低,且不容易规模化。但Redhat却为何如此成功?它或许是目前唯一比较成功的基于付费商业服务的开源软件公司。其实根本原因是Redhat已经不单单是卖服务,而同时也卖“产品”,即代码,比如及时的漏洞修补代码,bug修复代码,OS和软件工具的代码版本升级,优先体验和部署新特性的代码等等。这些“产品”和传统的专业服务打包在一起形成“订阅”模式,从而产生稳定收入。还有就是Redhat是围绕自己的Linux发行版进行商业化,经过多年的努力,这个Linux发行版已经被许多公司用在核心基础设施,粘性很大,也由于现在Linux及其之上软件的复杂性,再加上云服务的大规模性,公司专门养活一个维护团队有时候得不偿失,不如从Redhat订阅一个一揽子计划,解决后顾之忧。
以纯卖服务起家的Hortonworks(即前述和Cloudera合并的公司),目前也已在“订阅”套餐中加入了更多的服务之外的产品相关的内容。纯卖服务的公司在公开市场并不太被看好,一般市值也只有营收的1~3倍,而卖产品的公司通常可以达到10倍以上。
坚持情怀,站着把钱挣了
专业创造价值。这个价值可大可小。每个人和公司的追求不同,并非所有人都会奔着上市,做大而去。小而美,坚持自由软件的初衷,满足于细分领域的精耕细作也不失为一种商业选择。sysmocom (sysmocom - custom-tailored mobile telephony solutions),即Osmocom创始人创建的公司就是这样一个“站着把钱挣了”的公司。如果你不知道Osmocom,但是如果你玩软件无线电,就不可能不知道“电视棒”和openBTS/openBSC(前些年GSM伪基站的组成部分),这些都出自Osmocom社区。该公司在柏林维持10名员工的规模,主要依靠提供专业服务来生存,并对目的不纯的open core和dual license嗤之以鼻。我计划专门写一篇关于sysmocom的文章。等不及的可以先看看他们的About(About sysmocom background and company culture)和Jobs(Job offers)描述,你会理解我说的。
五. 托管/应用商店(hosting/marketplace)商业模式
人之初,性本懒,钱难挣,屎难吃
在托管的商业模式下,开源软件公司不但提供开源软件源代码下载,也提供已经部署好该开源软件的云服务。这种商业模式实际上是在开源软件本身的基础上进一步结合了传统云服务商业模式(SaaS),因此也更受资本的青睐,估值更高。软件也主要集中于大规模数据处理,大规模协作软件(例如git)等特别适合部署于云端的领域。其基本逻辑也是利用了“人性本懒”。开源软件已经有了,你可以下载,然后自行购买或者租赁服务器进行部署和使用。然而,如果开源软件公司也提供软件的托管服务,你无需下载软件自己折腾,只需要点击几下,就能立刻在开源软件公司的服务器上按照你的需求部署好了你所需要的软件/服务,不香吗?相信大家都想到了,被微软收购的github就是典型的托管商业模式,github除了免费的个人用户,也有付费用户,也帮各种组织(大学、公司、政府)部署和托管仅供他们内部使用的github。
其实托管也好,前面的专业服务也好,任何商业也好,都是“把别人的辛苦变成自己的辛苦,把自己的舒适变成别人的舒适”。这是薛兆丰在某期奇葩说里说的话。钱难挣,屎难吃。世界上最难的两件事,一是把自己的思想装进别人的脑袋,二是把别人的钱装进自己的口袋。话糙理不糙。
当自由/开源软件被云服务厂商白嫖
你可能已经想到了,传统云服务厂商,例如AWS不也可以在他们的云上部署开源软件然后以SaaS模式卖云服务吗?的确,前些年,AWS这种大鳄不讲武德,把一些流行的开源软件,例如MongoDB和Elastic直接部署在自家AWS上,成为AWS云服务的一部分。这对于那些开源软件的作者公司来说,无疑是眼睁睁看着自己的辛苦到头来却是为他人做嫁衣。这也是为何近几年面向大规模服务的开源软件纷纷把协议升级为SSPL协议,进一步明确限制用于云服务。
由于新协议只会影响协议变更之后发布的代码,所以协议变更后,那些白嫖开源软件的云服务厂商有两个选择:继续使用不受新协议限制的老代码软件,或者与开源软件厂商合作(我理解就是从白嫖变为乖乖交钱)。继续使用不受新协议限制的老软件,会面临随着时间的推移用户流失问题,毕竟新协议下的软件仍旧在不断发展和进步,大部分用户还是希望一直使用最新版本。这时候想继续白嫖并且有实力的传统云服务厂商(比如AWS)就会动用自己的研发力量,在老协议下老代码基础上不断研发,紧跟新协议下原厂软件的功能,并努力做到API层面的兼容,留住自己的云服务用户。对于不差钱,而且也比较顾及形象的云服务厂商,和开源软件厂商合作则是一种合理选择。例如MongoDB变更开源协议后不久,阿里就宣布和MongoDB达成合作,在阿里云上继续部署MongoDB。
marketplace/应用商店模式的典型代表就是Google的Android了,这个无需多说,用户为王,生态为王。
六. 利用硬件的开源软件商业模式
捆绑销售
首先硬件本身可以成为自由/开源软件的一种商业模式!比如,我见到过曾经把硬件限制写入软件License的:WARP(Wireless Open-Access Research Platform)项目中规定,源代码可以免费下载,但硬件必须使用Mango WARP V3平台:802.11 - WARP Project,因为项目收入是依赖于硬件售卖的。
给有趣的灵魂找个好看的皮囊
硬件可以成为软件的载体进行售卖。这可能源于人类毕竟已经在现实世界生活太久,天生觉得实实在在的摸得到的东西才有价值,越大越重越有价值。虽然内心知道这未必正确,但感官冲击往往会影响心理。你一定听说过某设备故意往内部加铁块/铅块配重而使用户觉得物有所值的传说。软件以硬件为载体进行捆绑售卖的典型例子有某些“硬件防火墙”,“Linux交换机”。用户买来是一个黑黑的大方块,看起来的确是防火墙和交换机的样子,但其内部只是一台装好了各种专业软件并进行了配置优化的PC。当然,不排除有技术实力的厂家真的把部分功能做进硬件/芯片来提高响应速度和性能,此时价格也就和PC架构的不可同日而语了。
所以,如果在你的开源软件应用场景中可以找到硬件载体或者硬件绑定,有时候售卖硬件也会是一种不错的商业模式。毕竟,购买纯软件在上古时期还能得到软盘或者光盘,而现在其实只是得到一串软件序列号而已,而开源软件连序列号也省了。如果用户能购买到一大坨硬件,也许付费时心里接受起来更容易一些。
缺点是,软件项目涉足硬件会分散精力,影响主业。涉足多深,是完全自己搞定、部分外包还是只贴牌,各有利弊,需要根据实际情况而定。
七. 自由/开源硬件的商业模式
硬件不是代码,也能遵循开源协议?
近些年,自由/开源硬件方兴未艾,尤其随着RISC-V以及各种开源EDA工具(KiCAD,yosys,nextpnr,SymbiFlow)的兴起,越来越多的公司也步入了开源硬件领域。谈到开源,无论是硬件还是软件,采用何种开源协议是绕不开的。我曾在Libreplanet 2021大会上提问FSF执行董事(Executive Director)怎么看开源硬件(毕竟FSF是自由软件基金会),他的回答有一定道理:软件是关于代码,硬件是关于文档。所以开源硬件本质上是关于文档及其遵循的协议。
的确,硬件的制造本质上是一堆图纸(比如PCB原理图、版图和机械3D建模文件)和设计文件(比如设计芯片用的Verilog/VHDL硬件描述语言),可以归类为文档的撰写,而不是代码的编写。在硬件描述语言(Verilog/VHDL)被广泛应用之前,数字电路/芯片设计就是靠工程师在图纸上将一个个门电路画好连接好。后来在硬件描述语言被应用的初期,人们为了方便,甚至将之前的画好的电路,重新用HDL语言描述一番,归档。文档,可以看做是一种创作,类似创作绘画,照片和文艺作品,自身在诞生的那一刻起,便有了版权。在创作领域,目前用的比较多的是CC协议 (Creative Commons),知识共享”协议。
但进一步引申开来,我觉得软件本质上也是一种文档,从法律上讲的确如此,因为软件也有版权,受到著作权法保护。从技术上讲我觉得也可以认为软件也是一种文档。这是因为软件本质上还是按照Specification去实现功能,而这个Specification本身就是文档,比如3GPP的移动通信标准,IEEE的WiFi标准,都是成千上万页的文档罢了。各厂家按照标准去实现,有些厂家选择一些功能在软件里实现,另一些厂家选择那些功能在硬件/芯片里实现。所以软件和硬件都可以看作是实现文档描述的功能的手段。
欧洲核子中心(CERN)的开源硬件协议
在欧洲核子中心(CERN)建造大型强子对撞机的过程中,为了节约成本和回馈社会 DIY了不少硬件,CERN基于他们的实践经验制定了开源硬件协议CERN Open Hardware Licence。它的第二版也被OSI(Open Source Initiative)认可为一种开源协议。OSI也就是认证了GPL等一大票开源协议的组织。
前面提到在云计算方面引起很大争议的SSPL协议也希望被OSI认可为一种开源协议,也许是因为争议很大,迟迟得不到认可。干脆,SSPL的制定者MongoDB宣布不再试图被OSI认可。
Apple和特斯拉都在用的硬件商业模式
如果硬件项目主要是用硬件描述语言的代码构建,那么其商业模式基本可以照搬开源软件项目的模式。已经被工业界广泛认可和流行的硬件描述语言有Verilog/VHDL,比较新的硬件描述语言有Chisel/SpinalHDL/nmigen等。基于这些硬件描述语言,github上有各种各样的项目,比如各种IP core,RISC-V的core,ARM和其他RISC CPU 的 core,等等。当然也少不了我们的openwifi--开源WiFi芯片项目。目前已经是github verilog主题第三名:Build software better, together ,竟然比一大票RISC-V项目的排名还高。
如果一个开源硬件项目真的要产出硬件实体并且交付给客户,那么商业模式就会十分简单清晰。卖一块硬件,挣一份钱。简单、直接、高效!就连现在市值最高的Apple,也主要依靠硬件商业模式,卖一台设备挣一份钱。风口浪尖的特斯拉,也是如此,卖一台车挣一份钱。所以不要小看这种古老的商业模式,它可以取得非常大的成功!当然前提是你的硬件要真的很受欢迎,也许是因为开源和无后门,也许是因为做工,也许是因为外观,也可以是因为它可以运行某些软件(比如iOS和App Store),最高阶的也可以是因为你的硬件更有Bigger和情怀。
等等,你的硬件设计文档全部是公开的,我为啥还要花冤枉钱买你的硬件,自己照着你的文档DIY不好吗?你当然可以根据公开的硬件文档自己造硬件,但估计超过99%的人都不会这么干。首先“人性本懒”,其次大部分稍微复杂点的硬件即便有了设计文档,制造依然不是那么容易,需要有很多经验,以及元器件采购、机械件加工、PCB打板、焊接、组装调试、良率爬坡等一大堆工作。这会吓退超过99%的人。对于基于Verilog/VHDL硬件描述语言的项目,估计更是超过99.99999%的人不会自己下载代码,然后去流片。。。。。硬件制造是一个尤其体现“把别人的辛苦变成自己的辛苦,把自己的舒适变成别人的舒适”的工作。你只需要下单,然后收快递,开箱,打开电源,即可享受硬件成品带给你的快乐,不香吗?当然不排除一些高手拿到设计文档,自己把硬件造出来是没问题的。尤其在我国,这样的高手有很多。
不要山寨!不要山寨!不要山寨!
基本上热门的开源硬件项目,例如USRP,HackRF,Airspy SDR等,都能找到比原版相对更便宜的山寨版。而这些山寨版大都来自我国的民间高手。有时候在twitter上,一些用户分享的照片中显示了他在使用购买的山寨版硬件,下面会引得一堆老外吐槽。有一些山寨版,对原版做了一些改进,有些许正面意义。但总的说来,公开售卖的山寨版无疑会伤害原作者的利益,并进一步印证我山寨大国的地位。
有一种例外情况是原作十分欢迎和鼓励山寨硬件,那就是某些芯片原厂的参考设计。你会发现在他们的文档中说欢迎大家学习并制造自己的硬件。因为芯片原厂的商业模式是售卖芯片,越多人利用这些芯片打造硬件越好,无论是照抄还是改进还是创新,最终都要用原厂的芯片。当然,山寨芯片则另当别论。
和下载开源软件一样,打算根据开源硬件文档自己DIY硬件之前最好先研究一下它的文档中的规定或者开源协议,是否允许自制自用,是否允许自制然后售卖,自制过程中对于设计的更改是否需要公开,等等。否则,和不当使用开源软件一样,同样可能惹上官司。
不要山寨不等于不能学习人家的设计,其实按照开源硬件的设计文档来自制硬件就是一种最好的学习硬件设计的方法。当领悟了人家的设计理念和精髓,就是时候考虑如何将这些知识用于自己的工作,或者创新出自己品牌的硬件。创新可以是硬件性能、成本甚至针对新应用场景的裁剪或扩展。简单的将micro USB替换为USB type-C,这也许很难称得上创新。
当然,国内的硬件领域已经有不少原创的作品,而且已经拥有很多用户。考虑到国内的市场规模和用户基数,这些原创公司也都活的不错。但进一步想,未来的发展空间依然很大。主要有两方面:有没有可能把硬件里的芯片(或者FPGA里的代码)也进行原创设计,我知道一些高水平的硬件公司已经在这么做;如何利用开源的理念,将原创硬件的用户生态做大,做到全世界。
八. 不忘初心
商业力量的强大,可以超越国界和民族,成为大国影响力(impact)的重要组成部分。下面的两张照片拍摄于10年前2011年在德国旅游时,冷战期间的东西德交通咽喉查理检查站。Apple和麦当劳已经占据了东西德两侧美国大兵cosplay和苏联大兵照片背后的空间。在当时的2011年(可能现在依然)原东德部分明显要比原西德差一些,但不妨碍东西两侧都被美国强大的商业力量所渗透。
自由/开源软件运动的领袖们,固然首先是情怀满满,但他们其实从未反对和忽视商业化,相反他们很清醒商业化的力量并践行商业化(例如前面说到被Redhat收购的Cygwin的创始人之一John就是EFF电子前沿基金会创始人)。
归根结底,自由/开源软件运动也好,基于这些软件的商业化也好,最终目的都是捍卫软件的自由。这是一种理念和价值。当理念和价值得到更多人的认可(无论出于何种目的),会演变成影响力(impact)和话语权。而影响力和话语权,反过来又可以为理念和商业化加持,进一步互相放大。具体到个体商业案例也许在几年内就能大起大落,而其背后的理念和价值会穿越时间持续前行。
个人的亲身体验是,国人基数甚大导致我们有多得多的更加聪明和勤奋的人,这些人才大都扎堆在国内一线城市,也有很多远赴欧美。我国也因此工程师红利在设计和制造领域取得了非常大的成就。还有就是我们常被教育要“实干兴邦”,因为“空谈误国”。也许是时候稍微改变一下,在埋头干活的同时也思考一下如何攀爬理念和价值的高峰,该空谈时也要谈。我们有非常扎实的实干基础,若能在此基础上,通过理念和价值来更好的将我们的工作输出到全世界,那么在影响力和话语权方面,我们也将会有一席之地。
共勉!
https://medium.com/blossom-capital/successful-open-source-business-models-2709e831e38a
https://blog.timescale.com/blog/how-open-source-software-makes-money-time-series-database-f3e4be409467/
https://en.wikipedia.org/wiki/Business_models_for_open-source_software