开源商业化:满足各方底层需求

简介: 健康的开源项目需满足使用者、贡献者、商业公司等各方「名利双收」的商业化利益。

开源越来越向大众化和专业化。


健康的开源项目需满足使用者、贡献者、商业公司等各方「名利双收」的商业化利益。


开源已经是一种越来越清晰且可以走下去的商业模式了,大家对于“开源商业化”这个话题也已经慢慢接受了。抽象来看开源里面只有两类人,一种是开源产品/服务的使用者(消费者)更多的是企事业单位,一种是开源产品/服务的贡献者(生产者)多是代码文档等提交编辑维护者、社区治理与运营者。这两大参与者之间目前都有一些痛点需要被解决,我认为这些痛点很重要值得被关注,否则可能会影响开源的健康发展。


使用者端,一方面需要“物美价廉”的开源产品为其解决工作生产中的问题,降本增效,更进一步完全可以看到软件内部逻辑,它是一个白盒子,“看的明白用的放心”等众多优点。从另一面出发,使用者在使用一个开源产品时可能会担心在使用过程中遇到问题 Bugs 该怎们办,该找谁帮助修复,尤其是上线到生产环境出现问题呢。有的开源软件使用者认为,可以把问题反馈到开源项目社区等待社区人员解决,这是常规有效的方法,社区中贡献者可以帮助修复问题、测试、发布等,由于各种原因社区人员不可能像企业内部员工那样及时快速的去解决问题,也有可能永远都没有人解决这个问题,比如在提交问题时描述不清楚等,社区没法理解问题也就没法解决问题,这样不可控的风险会给企业带来不可估量的损失;有的开源软件使用者想,能不能雇佣专门的人员来维护使用的开源产品,初步看好像可以,然现在是“软件吞噬世界,开源吞噬软件”,每个企业使用了不止一款开源软件,难道都要请专门的人员来维护,最直接的就是投入高昂的成本,显然不可行。那么使用者的痛点是什么呢?我认为是“使用了开源软件可能会带来不可控的风险和高昂的成本”,需求应该是“物美价廉”的开源产品,包括可靠的售后支持与保障。


贡献者端,很久以来很多人一提到开源/开源爱好者都会闪现出“极客”、“情怀”、“热情”及“无私奉献”等等的词语,确实也创造出了很多好玩有价值的开源产品。随着近年来开源被更多人认识,有更多的人想去参与开源。根据 Stack Overflow 的调查,真正能参与到开源贡献里面的人并不多,调查显示很多的受访者表示他们将编码作为业余爱好,但是没有选择为开源项目做贡献。大致原因是`「开源思想无限制,但开源贡献有很多限制,没有时间,基本免费贡献」`,这样就导致很多人只是很业余的提交一些贡献,这些贡献不一定会被开源项目的维护者所采纳,随着快节奏的生活,很多人除了要高效的完成正常的工作之外,只能抽出空闲时间才做点开源贡献,而且很多开源贡献者没有从开源中获得经济收益,当然过程中真的是有“情怀”的爱好者极客会不在乎挤压自己的时间精力和没有经济回报,最起码他们这样投入之后可以在开源界收获到“名声”人脉也可以增强技术能力,然大多数人长此以往参与开发贡献的美好愿望可能会事与愿违。所以他们的痛点是“不能保证最大精力投入,长期免费产出没有经济回报”,需求是“名利双收”。


我认为开源项目中的两端痛点能否被解决,需求能否被满足,是决定一个开源项目能否长远健康发展的核心点。若不能满足使用者的需求开源产品就是个 Toy,不能满足贡献者需求开源软件就没法向前发展。


那么如何满足双方需求呢,我认为是更好的“开源商业化”,其实之前对于开源商业化我的理解是狭隘的,我简单粗暴的认为,商业化就是让开源背后的商业公司获得商业回报,才能让开源软件走的更好,现在看来我的理解是狭隘的。我现在认为商业化或者回报是通过专业化方式让开源软件的两端都能得到回报。


首先为了满足使用者的需求,出现了开源软件背后专业的商业公司,这些商业公司可以为使用者提供专业的「技术咨询」、「技术支持」、「源码解析」、「高效的 Bug 修复」、「个性化的定制开发」等等,让使用者售后无忧。当然使用者要为商业公司支付专业的服务费用,这无可厚非,根据以往经验软件用的好,服务费用基本可以忽略不计。


其次为了满足贡献者的需求,我给出两种解决方案,

第一种,还是类似上面的商业公司出现,“收编”开源贡献者,让其全心全意的为开源项目做更多的贡献,商业公司满足他们的「名利双收」,比如,名,商业公司可以为贡献者提供发表、分享以及展示观点的机会与平台,使得贡献者被更多的人认识到,也会拓宽贡献者的职业范围;利,可以为贡献者支付比之前工作中相当甚至更多的薪水,还有不受限制的办公文化,Remote、不打卡等等,后面不一定都会这样,在这样「名利双收」做着自己喜欢的工作,产出会更高、开源项目会更加的活跃有保障。

第二种,即使有商业公司,有些贡献者可能出于种种原因不会加入商业公司,那么怎么保障他们的「名利双收」呢?根据经验我认为,比如,名,基本和第一种差不多,除了商业公司为了宣传开源项目更好的发挥他们的商业服务,可以让更多的贡献者也参与到宣传中,贡献者自己也可以主动的为自己的“名”发声。利,我目前推荐如下:商业公司做好商业生态,牵头做「开发者认证」,基于开源项目的特点推出商业的「Marketplace」或「AppStore」或「众包」或「分包」的单个或者组合的模式,即贡献者可以自己决定除了自己开源贡献之外的产出是否要变现,比如 Plugins、Apps 等是要免费提供给使用者,还是明码标价付费才能使用。这样如果跑顺,我认为「名利双收」也是指日可待。


通过上面可以看出只要出现专业的商业公司好像就能完美的解决开源项目中的双方痛点与需求了,但是我们想一想为什么要出现一个商业公司才能解决呢,从长远来看这个商业公司还有其他的什么目的或者影响吗?比如可以猜测一下,他们会不会完全控制了这套开源软件?开源软件的走向完全由其掌舵?甚至是让开源不再开源等等?我觉得可以这样思考,在开源软件与商业公司之间又出现`「Open Source Foundation(开源基金会)」`,也不一定说商业公司一定是先于开源基金会出现。开源基金会的最基本的属性是“中立”,职能之一是通过法律等手段让开源项目不受某个商业公司的控制,让使用者和贡献者可以放心的参与,不要担心自己的利益受损失。


关于开源基金会内容很多这里不详述了,可以参考其他的资料。如果某个开源项目能很好的解决两端的痛点满足各方需求,则开源基金会是非必须的。


目前基本上通过「使用者」+「参与者(开源贡献者、商业公司、开源基金会)」+ 类似与“开发者社区专委会” 就能帮助开源项目以及开源文化向前进。

目录
相关文章
|
13天前
|
安全 Anolis
龙蜥社区落地开源生态发展合作倡议,构建开放兼容的操作系统生态
通过共同努力,三个社区基于服务器操作系统场景,在操作系统内核等关键共性技术链统一方面达成了一致。
|
存储 SQL 弹性计算
元数据驱动的 SaaS 架构与背后的技术思考
在抽象能力以及沉淀了产品的基础上,把所承载和沉淀的业务能力快速输出,贡献给整个行业。
9029 11
元数据驱动的 SaaS 架构与背后的技术思考
|
Kubernetes Cloud Native 安全
阿里云携手开放原子开源基金会倡议发起云原生工作委员会,两大开源项目达成捐赠意向
阿里云携手开放原子开源基金会倡议发起云原生工作委员会,两大开源项目达成捐赠意向
|
消息中间件 边缘计算 Kubernetes
让开源和标准成为云原生的确定性力量
标准和开源加速了云原生,也推动了云原生的全面落地。阿里云通过大量的投入开源,建立更多的技术标准,帮助百万开发者使用更先进的云原生技术,让社区生态和云之间建立起非常好的连接,助力企业和云协同发展。
让开源和标准成为云原生的确定性力量
|
存储 分布式计算 供应链
隐语:打造安全易用、社区共建的数据密态时代技术基础设施
7月4日,蚂蚁集团宣布面向全球开发者开源可信隐私计算框架“隐语”。这是蚂蚁集团经过6年多的研究打磨,推出的集成当前主流隐私计算技术的通用框架,具备安全可验证,对开发者和使用者友好易用的设计。“隐语”开源背后蚂蚁有什么思考?蚂蚁隐私计算对未来的预期是什么?蚂蚁集团副总裁兼首席技术安全官、隐语开源社区技术指导委员会主席韦韬博士在“隐语”开源发布会上做了分享。
933 0
隐语:打造安全易用、社区共建的数据密态时代技术基础设施
|
云安全 Cloud Native 架构师
PingCAP DevCon 2021:预见数据技术的未来生态
PingCAP DevCon 2021:预见数据技术的未来生态
175 0
PingCAP DevCon 2021:预见数据技术的未来生态
|
消息中间件 弹性计算 Kubernetes
开放下载 | 支撑全球最大规模云原生实践的云产品,究竟有哪些独特之处?
本电子书聚焦云原生12款核心产品,覆盖容器产品、微服务产品、消息中间件产品、Serverless产品等。
5599 8
开放下载 | 支撑全球最大规模云原生实践的云产品,究竟有哪些独特之处?
|
算法 安全 Serverless
何为真正的 FaaS ?阿里舜天平台做了四大创新
数据中心和云计算的超高增速,AI、视频、基因测序等应用对于算力的无尽渴求和摩尔定律发展事实上已经停滞的现实,均给异构加速带来了巨大的应用潜力和商机。但 Faas 解决方案仍有较高的门槛,今天,我们一起了解 Faas 的难度在哪里?以及在阿里,我们如何做到真正的 Faas?
1854 0
何为真正的 FaaS ?阿里舜天平台做了四大创新
|
Kubernetes 安全 Cloud Native
蚂蚁王旭:开源协作如何提升业界的安全?
开发者、组织、业界机构的共同努力,让开源项目和社区,乃至整个世界变得更加安全。
蚂蚁王旭:开源协作如何提升业界的安全?
|
OceanBase 存储 索引
首度公开!OceanBase存储系统架构的演进历程及工程实践
OB君:作为一款100%自研的分布式数据库,OceanBase历经了近十年的发展历程。近十年来,OceanBase的存储架构经历了多次演进,以解决业务越来越复杂苛刻的存储需求。本文整理自赵裕众(花名陈群)在2019 SACC中国系统架构师大会中的演讲。