开源正在重构商业模式

2023年 1月 4日 47.0k 0

Adobe 以 16.7 亿美元收购 Magento,微软以 75 亿美元收购 GitHub,IBM 以 340 亿美元收购 Red Hat,开源原来也是一门好生意。本文主要是关于开源的一些记录和思考。

1. 什么是开源

1.1 发展史

1969 年,贝尔实验室将 Unix 代码共享给社区,为开源奠定了重要基础。1984 年,Richard Stallman 离开 MIT,发起 GUN 项目,希望使用自由代码构建一个类 Unix 的操作系统。此后,Stallman 创立自由软件基金会(FSF),发起 GNU 通用公共协议证书(GNU General Public License, GNU GPL),开发了 GCC、Emacs 等一系列重要产品。1991 年,Linus Torvalds 在 GPL 协议下发布了 Linux 操作系统内核。1995 年,Apache 诞生,随即占据 Web 服务器大部分市场份额。2000 年,开源延伸至移动和云领域,由 Google 等大企业驱动,影响技术发展路线和市场格局。2008 年,Github 等代码托管平台,采用 pull/request 等方式协同合作,将开源推向了新高度。2014 年,Google 开源 Kubernetes,获得极大关注。经过几年发展,Kubernetes 成为事实上的分布式架构平台。伴随着这些事件,还有一系列基金会被创立。这些基金会通过内部优先、资金资助等形式,有力地推动了开源运动的进展。值得说明的是,自由软件和开源基本上指的是同一范围的程序。它们的区别更多在价值观上。

1.2 开源协议

开源协议用于维护作者和贡献者的合法权益,保证开源项目不被商业机构或个人窃取,从而影响项目发展。下面这张图,对主流的六种开源协议 GPL、BSD、MIT、Mozilla、Apache、LGPL,进行了清晰、简洁的讲解。

2. 开源带来的好处

2.1 更好的宣传

对于销售人员来说,开源是非常有利的优势,代表着开放、先进的研发理念和技术。对于招聘人员来说,开源可以吸引更优秀的工程师。在社区中,开源项目会引起更多人的关注和讨论,是宣传产品的机会,能提升组织在领域的影响力。项目开源也能增强用户的尝试意愿,没有太多风险。用户早期几乎没有成本,深入使用之后,还能修改源码定制。开源项目具有透明性、可信任、可持续的特点。

2.2 更好的开发实践

通常,开源项目的代码质量更高,文档更完善,中断风险更小。传统的开发模式中,项目代码封闭在公司内,很少会有人查看。开源之后,项目面向的是整个社区。无论是代码,还是文档,开发者都会更加严谨、负责。同时,开源意味着更多人的参与,推动内部人员规范化开发流程,对外进行输出。参与开发的外部人员,由于亲身参与,也会对项目赋予特殊情感,更愿意去使用和推广。

2.3 更有利于整合上下游

通过开源,开发者还可以快速获取上下游的反馈信息,对产品进行调整、改进,有利于产品迭代。开源也意味着开始经营上下游的生态圈。如果一个项目,没有上游的支持和下游的使用,那么它也就没有生命力。构建更大的利益共同体,扩大项目的影响力,占领相关领域才能构筑强大的竞争优势。

3. 开源的盈利方式

开源不会成为赢利点,需要其他途径补贴。

  • 销售云服务补贴开源

对于用户来说,部署、维护、升级都是成本。通过服务便捷,可以获得收费机会。常见的模式有两种: SaaS 模式和 IaaS 模式。SaaS 模式直接提供远程服务,计时计量收费,例如 Sentry。IaaS 模式通过公有云平台服务商整合服务,销售 IaaS 资源。

  • 发行多版本

开源只提供了核心模块的源码,无法满足全部的企业需要。定制化开发、功能增强型开发会成为收费点。通过发行社区版、企业版、高级版等梯度产品,社区版作为试验区,逐步向收费版本引导。

  • 运维服务

对企业真正有价值的是软件运行时,而不是静态的代码。各种运维场景,故障处理,层出不穷的安全漏洞和补丁解决方法,都可以成为付费点。

  • 培训、认证、授权

通过相关培训、认证、授权等,可以作为赢利点。

  • 销售周边

除了看不见的服务,还有看得见的周边。比如,销售公仔、文化衫、纪念品等,也可以作为收入来源之一。

  • 被收购。独立的组织,被巨头收购也是一个不错的归宿。

4. 开源需要做些什么

并不是每个产品都适合开源,商业开源是为了生态。我观察到有些商业公司,在 github 上开源项目,获得了高星。但是,他们没有持续运营,代码提交主要集中在数年前的半年内。我认为,这样的项目没有开源的必要。一个好的商业开源项目,应该做好这几件事:

  • 领先的方案实现

开源的正确打开方式是,一定要在领域提出先进的方案,并完成核心实现。开源只会锦上添花,不会雪中送炭。只有项目本身具有价值,才能吸引大家广泛参与。

  • 完善的文档

文档是极其重要的项目说明。一份清晰、详细的文档,有利于其他人的参与。

  • 热衷传播

酒香不怕巷子深的时代已经过去,同类的竞品层出不穷。如果不主动地宣传、布道,项目很容易错过风口期,最终导致失败。我们应该主动地宣传项目,与同行,与用户,更多的交流。进行传播的同时,开发者也能获得反馈,进行优化,形成良好的口碑

  • 维护核心用户群

在项目还没有很成功时,经营好核心用户群非常重要。产品是需要不断打磨、迭代才会成为精品。这个过程中,不仅需要开发代码,更需要用户参与。核心用户群是产品第一用户,也是社区口碑的传播者。

  • 记录 FQA

早期阶段,让开发者直面客户人群进行 QA ,有利于产品快速迭代。当产品打磨到足够稳定时,我们应该记录 FQA 。记录常见问题可以降低对开发者的干扰,引导用户回答用户问题,回归社区。

  • 定期分享

没有哪一个行业像 IT 一样,如此热爱分享。最近几年,我观察到,各种社区活动越来越多,开发者也开始从线上至线下参与其中。社区活动就是产品宣传的机会,如果有资源、有一定影响力,也可以自行发起活动。线上线下持续地运营,聚拢用户,形成圈子,越来越重要。

  • 生态合作

开源最终拼的是生态。生态也会给开源组织带来更多变现的可能性。生态的建设应该围绕着合作共赢的思路建设,比如平台开发商提供平台、构筑应用市场,应用开发商开发应用在平台上销售挣钱,平台因为有这些应用更加具有竞争力。

5. 参考

  • http://crva.io/documents/Comments-on-Risks-of-Open-Source-Projects.pdf
  • https://www.gnu.org/philosophy/open-source-misses-the-point.zh-cn.html
  • http://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html

相关文章

KubeSphere 部署向量数据库 Milvus 实战指南
探索 Kubernetes 持久化存储之 Longhorn 初窥门径
征服 Docker 镜像访问限制!KubeSphere v3.4.1 成功部署全攻略
那些年在 Terraform 上吃到的糖和踩过的坑
无需 Kubernetes 测试 Kubernetes 网络实现
Kubernetes v1.31 中的移除和主要变更

发布评论