探索开源以及开源商业模式研究

开源为我带来了很多的成长，很多的成长经验和学习途径都是通过开源获取到并且学习到的。

这里有一篇我的第一次开源的成长指南：https://nsddd.top/zh/posts/open-source-contribution-guidelines/

之前，在深圳的 全球流量大会（GTC） 一些来自我对开源商业化的思考，感兴趣可以阅读先阅读这篇思考文章： https://nsddd.top/zh/posts/openim-open-source-business-journey/

第一次参与开源还是一个刚刚接触大学没多久 ~ ，调研了解到很多优秀的开源项目都会有很多业界大佬坐镇，因此会让大家以为只有“大牛”才能参与开源。实际上，开源社区经常会听到 “我是小白，我可以参与开源吗？” 这种声音，发出这种声音的同学往往是对开源感兴趣，但并不知道如何入手的小伙伴。

从开源定义来看，我们不需要成为“大牛”才能够参与开源。所谓开源，其实是一种促进个人成长和开源领域发展的行为，通过分享自身技术和经验来促进大家的技术交流，从这方面讲，开源是没有门槛的，只要有想要分享的东西，所有人都可以参与开源。

从参与要求来看，我们需要具备一定的知识积累才能参与开源。开源社区不是学校，社区会解答你的疑问，但首先你要有一定了解，才能准确提出你的疑问。对开源项目一无所知是无法参与开源的。当然，这与你是否成为“大牛”也并没有什么关系。因此，只要具备一定的技术积累，就可以参与相应的开源项目。

“罗马不是一天建成的”。没有人天生就是“大牛”，“大牛”们也是在参与中不断成长的，不要被虚无的 title 所困扰，只有不断的坚持和探索才能让自己不断成长！ 其实旅游中也有过一些自己的思考，在旅游中我喜欢摄影，带着相机走走拍拍。或许和女生不一样 ，我开始的时候其实是更倾向于发现风景的，就像是在香港的麦理浩径的第一段和第二段的中间破边洲部分，我更多的是以人物在破边洲的悬崖边上，然后衬托后面的悬崖的美丽壮观。我们在工作中也是一样的， 在我们摄影的时候，我们面临对焦，开始在远方我们或许更多的是把焦点放在人物后面的背景上，或者说是 title，比如说某个人是某个大学、某某大厂的光环，反而忽略了他的本身。后面当你关注在人物身上，你会发现人物的美，你会想办法如何把漂亮的小姐姐这一瞬间记录下来。这个时候其实你更专注的是某一个人，这个转变很重要，你慢慢的发现自己专注自己了，而不是专注后面虚无缥缈的光环和头衔。

在开源社区中，我慢慢学习到了非常多的技巧，比如这里我总结出一篇开源社区的提问技巧：https://nsddd.top/zh/posts/the-art-of-asking-questions-in-open-source-communities/

我对整个的开源成长也有自己的思考总结，写了这篇关于开源的成长性指南阶段，从我们第一次加入开源项目开始，到最后开源和维护自己的项目，以及商业化成长，可以参考： https://nsddd.top/zh/posts/stage-growth-of-open-source/https://nsddd.top/zh/posts/stage-growth-of-open-source/ 非常推荐阅读 ~

在加入 OpenIM 的社区一年中，我将自己的开源理解和运营技巧都集成在了 OpenIM 的开源布道上，将 OpenIM 社区带入到了一个顶级的开源社区中来。除此之外，我参与过其他的优秀开源项目的贡献和维护，我会从自己的角度上来介绍如何运营一个优秀顶级的开源社区。

开源不仅是我的热爱，也逐渐成为我的一大优势。在我与开源的互动中，我们相得益彰。

开源除了给个人以及公司带来技术影响力之外，更为重要的是通过开源实现商业化价值，而这部分才是很多开源项目成功的实际驱动力。本文会介绍我对开源的理解，以及着重介绍自己对开源以及开源商业模式做了一个系统的研究，为决策项目是否应该开源、采用何种开源策略以及开源商业化路径提供参考意见。

如果你对我有兴趣，可以关注我的开源的 github 账户： https://github.com/cubxxw

开源商业模式

越是用户付费意愿强的功能，越是要闭源。越是用户觉得好玩的功能，能吸引到大家的功能，越是要开源。

我认为的开源商业模式是什么样的？

开源商业化模式文章后面会总结目前的所有的商业化模式，但是我觉得最主要的商业模式是 open-core 和 open-standard，还有一些非主流的，比如说开源软件免费，但结合硬件组合销售。

我认为：

1. 越是用户付费意愿强的功能，越是要闭源。
2. 越是用户觉得好玩的功能，能吸引到大家的功能，越是要开源。

我认为的开源商业模式是什么样的？

开源商业化模式文章后面会总结目前的所有的商业化模式，但是我觉得最主要的商业模式是 open-core 和 open-standard，还有一些非主流的，比如说开源软件免费，但结合硬件组合销售

开源也有自己的护城河吗？

担心开源后自己的产品被抄袭，开源，作为一个推动技术创新和社区合作的新力量，其商业模式多样，从提供专业支持和服务，到构建围绕核心开源项目的企业级产品。

我认为在开源的护城河上面，关键在于如何利用产品开源的独特价值和社区力量，创建难以复制的竞争优势。

所以基本上就是你要不是有开源 core 产品，作为线索漏斗去吸引你的用户，然后用这来做你整个公司的品牌，然后再做差异化功能的落地实践，然后另一种可能就是类似 MySQL 做咨询顾问的工作。

那么开源产品本身的护城河我理解其实抛开和普通产品护城河区别外，Open standard是今天开源软件商业化更好的一个形态，它对这个公司的技术能力提出了更高的要求。 open core 其实在云时代很难发展，即使是目前 OpenIM 那种做好 传统的 open core 模式在云时代下会比较难，可能难就难在构建好护城河，比如说跟那些云厂商比。各大云厂商，从各方面看，都有巨大优势：它本身就是一个大的流量资源，客户的流量在这里，推广的流量在这里，如果你很不幸，刚好跟这个云厂商贴在同一个赛道，你怎样去获得一个这个优势？这很困难，也是 MongoDB、Elastic、Redis 等开源厂商被逼的修改开源 License 背后的深层次原因。

但是，一旦你的开源项目成为业界事实标准之后，这时候 标准就是你的护城河 。

所以，在这方面，如果盯紧一个 open standard，然后聚焦你的技术和产品能力，专注在商业产品上做到业界最优，才有可能成功。

很多开源软件公司死掉了或者是不成功，并不是死在商业模式上。其实说白了还是用户基础不够大，没有真正成为业界的事实标准，这是比较令人担心的。开源企业想以开源模式来成功，一定要把开源项目做成事实上标准，例如 Hadoop、Spark，或者是流计算里的 Flink 等，以及 AI 框架 PyTorch 等。就是在细分领域里，一定要拥有业界No.1的的用户基数。

如何判断开源软件企业成功与否：

在目前大家对开源商业化的态度是双面的，甚至最开始加入开源的我眼中，商业化的开源软件其实是不够纯粹的，这是典型的开源原教旨主义者，甚至一定程度上是反商业化的，说开源是一个非常纯粹的东西，它不应该和任何商业化相结合。另外一派是实用派，20年前的话就是说这个原教旨主义派跟实用派的边界就在使用 GPL 还是使用 BSD 上面， GPL 说你要用开源，就必须跟商业化完全切割，然后 BSD 说没关系，你用吧。今天我觉得开源之争其实变成了用 BSD、Apache，还是用新的这些，比如像 Elastic license 等这些许可证变体上。

我现在的观点可能偏后者一些，我个人的看法是 要能把商业做出来，然后在一个大家普遍接受的状态和准则上反哺社区，让社区能够活得下去，这是很重要的事。

在之前，有讨论过，《黑客与画家》书中，Graham 在书中提到了开源软件的几个关键点，他认为开源可以与商业化共存，甚至能促进创新和商业成功。

尽管开源软件通常是免费提供的，但企业和个人开发者可以通过多种方式对其进行商业化，以创造收入。Graham 提到了几种可能的商业模式，如提供专业服务（支持和咨询）、自定义开发、培训和教育服务，以及通过增加专有功能或组件来销售产品版本。

书中提到了开源的几种商业优势：

1. 信任和透明性：开源软件因其源代码的可见性而被视为更可信。这对于安全敏感的应用尤其重要，用户或公司更倾向于使用那些能够被审查和验证的解决方案。
2. 快速迭代和创新：开放源代码可以吸引全球的开发者参与，这种广泛的参与促进了快速的创新和问题解决。
3. 成本效益：使用开源软件可以减少初期的软件成本，尤其是对于创业公司和开发新产品的企业来说，这一点非常有吸引力。

成功的定义有很多，但对企业而言，成功的定义只有一个，就是商业成功。开源背后的企业也不例外，开源的公司要赢得商业成功，有几个阶段：第一个阶段，是用户社区的成功，就是你开源的软件要受到用户的欢迎；第二个阶段，就是从社区成功转化为业务的成功，就是你要有规模化的营收进来；第三个阶段，就是你的损益达到平衡点之后，能盈利（profitable），才能到达商业的成功。开源企业要想赢得商业成功，其实这三个环节，步步都不能踏错，所以要一步一步拆开来分析。

大部分所谓的开源公司都死在社区不够壮大。是的，90%的开源软件公司都死在这一点。其实第一个阶段的门槛是很高的，开源软件成千上万，真正能被大家熟悉和使用的，只有1%，其他99%都做了分母。为什么我们觉得好像开源很容易，但赚钱很困难？这其实是因为幸存者偏差，我们根本没有关注过没有人使用的那 99%的开源项目。不要看很多开源项目 star 数很多，宣传也很广，我关注的永远只有两个：一是用户数，真正在生产业务中有部署的，另一个是活跃贡献者数量。脱离这两个，一切运营手段都只是空中楼阁，项目也无法真正成为 Open Standard。

分析 OpenIM 所面对的商业化问题，OpenIM 其实是一个典型的开源商业化产品，它的背后是有一家商业化支持的，OpenIM 为什么会成功？ 我认为是两点，第一个，有一个 PMF（差异化是私有化部署 IM， 解决了中小企业以及政务企业 IM 私有化部署问题）。还有一个就是后台的商业化公司合理的开源引流，把开源做的很好，并且有合理的商业化判断，比如知道 core 是开源所需要的，边缘的特殊场景是商业化所需要的。以至于适当的高级版是企业所额外需要的。并且 OpenIM 想的很清楚，它不想去陷入为客户线下部署与现场支持（on-prem）的模式，而只去解决云上标准化产品的问题，基于标准化的硬件和标准化的设置，这大大简化了技术复杂度并降低了成本。不管是 PLG(Product-Led Growth) 还是Sales-Led, 我认为商业模式要上规模，规模化之后还能盈利是最重要的，OpenIM 提供了一个很好的参考案例。

除了用户，对开源社区，开发者或者说贡献者也很重要。刚才我们没有太细聊开发者社区，这个并不是每一个开源项目都一样：有的项目不欢迎外部开发者，只关注用户，我认为这完全没问题。我们看到在很多场景里，社区的外部开发者会把你的开源软件带到一些之前没考虑到的应用场景，从而拓展了开源项目的原先场景，这也是开源项目和社区充满创新活力的原因之一。

包括 OpenIM 在之前有贡献者为我们贡献了一套高级版已经有的一套加密模块 ~ 当然是我们当前不需要的地方。不过其实这也意味着做开源对开发和产品的要求更高的，意味着你的高级版加密一定要做到优质、顶级。 这一点类似的是，同样商业化产品，如何做到可信任，尤其是中大一点的客户，其实很关心你的商业模式。我希望用你的东西，也希望你的东西是能长治久安的。不管是我付钱还是别人付钱， 你怎么去让客户对你的商业模式有信心。每个客户都希望少付钱，你需要条理分明地说服用户。在真正的大客户合作中，这点很重要。

未来的 AI 时代商业化如何做，我是思考过的，我们当前肯定还是更依赖社区来的线索，这一点与闭源软件完全依赖销售线索很不一样。我们可以从 issues、社区邮件组、slack 群、社区技术活动里跟用户交流获取直接反馈，看看我们解决的痛点有多大价值，还有哪些共同的、待满足的需求。吸引标杆用户，通过社区用户和案例来不断拓展你的社区边界也特别重要。

思考开源的路线？

其实这一点很重要，开源我们知道有 强制性（GPL、GPL v3、LGPL、Mozilla 等） 开源和 宽松许可证（Apache、BSD、MIT 等） 开源。

我认为在 AI 领域来说，其实基本上就是大家都是尽可能地开放。我觉得，越是用户愿意付费来获得的功能，或是乏味但不可或缺的功能，你越需要把它闭源。越是大家觉得说好玩的能吸引大家的兴趣，但是企业不太会为这玩意付钱的功能，就放在开源上面。

因为这个是和你的受众有关系的，付费的那个受众是企业，所以说一旦涉及到什么稳定性、规模、安全性等，用户是愿意付钱的。但如果你把它开源出去，这帮开发者们也懒得看，例如集成（integration）这样的功能，不干也无所谓；如果说是那种好玩的，我有一个新的 SQL 功能，能用 AI 产出 SQL，大家一看说好玩的东西能够产生流量，但是企业一看说这玩意我不愿意付钱，那就放在开源这里。一边开源是驱动流量和关注，另外一边企业级产品则是驱动营收，其实就照这样的一个原则。

思考了目前一些开源社区，包括 OpenIM 和 OpenAI 等开源社区，一个东西要不要开源，除了功能特性本身的属性外，我认为也取决于背后企业所处的阶段。成功的开源企业早期我认为还是尽可能的开源。 比如说 OpenAI ，最开始也是通过 Open 来吸引用户的，现在我们回过头去看 Databricks，它在 Spark 等早期项目的开源是非常彻底和坚决的，其他的像 MongoDB、Elasticsearch，也是到了后期为了提升营收才被迫去修改许可证，之前他们也是 Apache License v2 的许可证。

在早期阶段最难的其实是构建出一个真正使用广泛的企业级开源社区。如果这时候你的许可证是不开放的，那实际上成功的几率微乎其微。每100家开源公司可能真正懂得把社区建好的可能就3至5家，所以这个比例是3% - 5%。这个3%你能跑出来，就像我刚才提到的三个阶段，在第一个阶段3%跑出来之后，后面可能就有30%-50%的几率能存活。因此，我认为就早期阶段而言，越 open 越好。

要不要开源？

和各个顶级 VC 聊了一些开源的想法，其实很多创始人也是 VC 转行创始人的，就本质而讲，对待开源是需要点耐心的。你如果希望刚投入马上就能赚钱，这跟做开源商业模式的规律就不那么符合了。尤其是国内 VC 对 PML 期望可能是从三到五年转变为一两年。但是建立一个活跃的用户社区需要时间和持续的努力，是逐渐通过建立信任和认可来提升项目的市场影响力。甚至是面向开源的商业模式，也是需要时间去思考和打磨的，这点和传统的商业模式也是不一样。

开源大模型的开源闭源思考？

其实我自己觉得模型开源和闭源对模型本身意义不大，模型及时开源对于用户来说，贡献者来说，很难产生很大的数据价值。

Llama 3 如今开源了， deepseek v2 最近也开源了，都是非常大的惊喜，这对于做垂直领域的中小型创业公司来说很重要，甚至是对于有数据安全隐私的私有化部署的企业来说。 不可否认，今天其实闭源的模型仍持续领先，市场决定了哪种模式会发展得更好。

Facebook 的 Llama2，Llama3有开源的商业模式，OpenAI 在后面也会把 gpt3 开源（它自己说的），Mistral 也有自己的商业模式。当前领先的闭源大模型公司目前还没找到除闭源之外的商业模式，也许后面有些公司意识到构建在开源模型之上，也许有助于其找到更佳的商业模式，例如构建标准来吸引强大的应用生态来挣钱，那么这些公司一样可以把类似于 GPT 4或者 GPT 5的能力给开源出来，为了让自己的生态标准化，这就和当年 Google 做 Android 的逻辑一样。所以我认为大模型这波的应用营收或价值能不能被放大产出非常关键，如果应用远超基础设施（大模型）的价值的话，各大玩家后续可能在大模型方面会更加地开放和激进。我相信未来AGI应用的价值，所以也更看好开源LLM。

从大模型出发的商业模式思考

我阅读过 Hugging Face 现在的模式，它做一个非常大的社区，通过咨询顾问服务来赚钱。这是一个还在验证中的模式。如果说 AI 继续是一个高专业门槛的状态，那么通过经营一个开源社区，来营造自己的名声和专业，同时给技术水平较弱的公司提供咨询顾问服务，这不失为一种模式。

故此，我认为开源商业化最大的意义: 标准化 ~。

什么是开源

「开源」一词对应英文 Open Source，最初起源于软件开发领域，因此也称为「开放源代码」，对应的软件则称为开源软件（Open Source Software）。除了我们熟知的开源软件以外，开源的表现形式还有开源硬件（Open Source Hardware）、开放设计（Open Design）、开放文档（Open Document）。

我们最常见的是开源软件和开放文档 ~ 先来谈论一下 开源软件

一般很容易理解就是 是不是公开源代码的软件就是开源软件呢？

实际上并不是。按照 OSI 组织 (opens new window)（Open Source Initiative Association）的 OSD 定义 (opens new window)，除了公开源代码，开源软件的发行条款还必须符合以下十个条件：

你可以通过查阅OSI官方许可证的目录 Open Source Initiative 认可的开源许可证

这里有一些是我认为需要解释的一些概览：

1. 许可证的发布具有延续性：这意味着一旦一个作品在某个开源许可证下被发布，该许可证的条款将持续适用于该作品及其派生作品，无论它被多少人使用或修改。即使原始作者决定在后续版本中更改许可证，之前版本下的许可证依然有效。这种延续性保证了开源项目的开放性和法律条款的稳定性。
2. 许可证不能针对于某一个产品：这表示开源许可证授予的权利不能限制使用者只能在特定的产品或特定的环境下使用。开源许可证通常允许任何人在任何环境下使用、修改和重新分发代码，而不受制于特定的产品或用途的限制。这保证了开源软件的广泛应用性和灵活性。
3. 程序必须包含所有源代码：程序必须包含所有源代码”的要求意味着当你分发或发布该程序时，必须提供足够的源代码，以便接收者能够编译和修改程序。这是许多开源许可证（如GPL）的核心要求，确保接收者可以自由地研究、修改、和再分发软件。

通过了解这些条件约束，我们可以得出开源软件的定义：开源软件是一种技术和立场中立的使用许可证约束的开放源代码的软件。

• 强制性（GPL、GPL v3、LGPL、Mozilla 等）（Copyleft）许可证，如GNU General Public License (GPL)：这类许可证要求，如果你分发的软件包含了原始的GPL授权代码，那么整个软件，包括你添加的所有功能，也必须以GPL或兼容GPL的许可证进行开源。在这种情况下，你不能将部分功能保留为专有的。
• 宽松许可证（Apache、BSD、MIT 等），如MIT或Apache License：这类许可证允许你在保留原有代码开源的基础上，添加专有的闭源功能。你可以选择只开源程序的一部分，而将一些高级功能保留为闭源，这不违反许可证条款。

开源的影响

开源作为一种贡献技术的方式，对整个技术界和开源社区的正向回馈是巨大的。近 10 年来，越来越多的项目加入了开源界。其中有许许多多的知名开源项目被人所认可和追捧。

随着开源协作这种方式越来越被这个世界所认可，有很多的公司和个人开发者也加入了开源大家庭，他们把自己的技术沉淀、解决方案做成开源项目回馈给开源社区。如今的技术界，正因为有了开源，而变得不再是闭门造车，而是呈现出一种百家争鸣，欣欣向荣的景象。

开源社区概念

开源社区又称开放源代码社区，一般由拥有共同兴趣爱好的人所组成，根据相应的开源软件许可证协议公布软件源代码的网络平台，同时也为网络成员提供一个自由学习交流的空间。由于开放源码软件主要被散布在全世界的开发者所开发，开源社区就成了他们沟通交流的必要途径，因此开源社区在推动开源软件发展的过程中起着巨大的作用。

开源社区的宗旨

开源社区究竟有什么魅力，让无数开源爱好者趋之若鹜？从本质上来说，这是开源社区的宗旨所决定的。所谓的宗旨，实际是指一个社区的内核，是融合了开源发起者和核心成员的理念而成的产物，你也可以将其理解为价值观。比如：Facebook 的目标是「让世界更加开放，更加紧密相连」。

《大教堂与集市》的译者卫剑钒在《开源的 7 大理念》一文中分析阐述了开源 7 大理念：

• 完全自主：开源之所以能够大行其道，是因为所有程序员都喜欢源码。
• 高度开放：对软件而言，源码都开放了，还有什么不能开放？
• 自发自治：所谓开源社区，指的是所有关心、参与、支持、帮助某个开源项目的人的集合。
• 自下而上：自下而上是大自然最普遍的法则，开源作为一个从草根社会发展起来的事物，必然会遵循这个法则。
• 自由竞争：开源，是一个靠实力说话的世界。开源软件在竞争什么？竞争的是谁的软件好使，谁的评价更高，以及，最终，是谁获得了更多的市场份额。
• 赢在声誉：除了项目发展、能力增长、回馈社会、自我实现之外，最大的好处莫过于声誉。这也是很多黑客贡献代码的初衷。
• 社区赋能：Apache 有一句格言叫”社区重于代码"，它强调的是：一个健康的社区远比良好的代码重要。如果代码消失, 一个强大的社区可以重写它；但是, 如果一个社区不健康, 代码最终也会失败。

开源社区中的几种角色

开源社区的每一个人都有自己的角色，每个角色在开源社区内，都能收获不同方面的成长与提升。一般一个大型的开源社区有以下几种角色：

• 开源领导者（Leader）：领导者承担了带领项目发展的责任，一般拥有项目事务的决策权。
• 开源维护者（Maintainer）：维护者承担了项目日常维护工作，一般拥有项目事务的管理权。
• 开源提交者（Committer）：提交者负责对项目提交成果物（一般指源代码提交），并参与项目事务的处理。
• 开源贡献者（Contributor）：贡献者通过多种方式为项目做贡献（如解答 Issues、社区宣传等）。
• 开源使用者（User）：使用者是项目的使用者，一般会围绕项目进行技术讨论和意见反馈。

开源领导者（Leader）

开源领导者扮演的是项目的指挥和决策角色。在这个过程中，领导者主要从策略规划和团队管理方面得到成长。他们学习如何制定开源项目的长远目标、协调资源、并解决复杂的挑战。此外，领导者还将提升其公关能力，与其他组织和项目进行交流合作。通过这些经验，领导者能够增强自己的领导力和影响力，为未来承担更高的管理职责打下坚实的基础。

作为项目的领导者，需要去从大局观去考虑，从项目所处的专业领域的发展，到每个特性关联的技术方向，再到怎么在社区内进行推广，怎么持续推进项目的进度。这些实际操作的过程累计的经验，能让你在任何一个项目中都能正确分析和决策，游刃有余。因此，领导者获得的提升也是全方位的，主要提升体现在以下几点：

1. 得到一次将自己的思想落地实现的机会
2. 获得更高的技术洞察力、更广的行业观察力
3. 磨炼一份坚韧不拔的精神力
4. 提升自身的领导力
5. 提高自我认同感和成就感
6. 积累自身的声望
7. 结识一群可爱的朋友
8. 提升个人综合素质

开源维护者（Maintainer）

维护者（Maintainers）：一般是指在开源项目中具有最高决策权力的群体，他们能够决策项目发展方向，同时对项目组织各层级的成员进行提名、投票等，在不同的开源组织或项目里面针对维护者的详细详细权责也会做更明确的说明。在 Apache 软件基金会的组织架构体系中，每个项目都有独立的 PMC（项目管理委员会）进行管理，PMC 成员为项目提名并选举新提交者（Committer），PMC 成员还负责提名并投票新的 PMC 成员等。

作为开源项目的维护者，这一角色主要聚焦于项目的日常管理和技术细节。维护者在解决技术问题和代码审查中磨练技术技能，同时也在项目管理和协调中提升能力。他们学习如何管理社区贡献，确保项目的质量和稳定性。通过这些任务，维护者不仅技术能力得到提升，也在人际沟通和团队合作方面获得了宝贵经验。

开源提交者（Committer）

开源提交者是参与代码开发和提交的核心成员。在这个角色中，提交者能够深入参与到代码的编写和优化过程中，这不仅提升了他们的编程技能，也增强了对项目架构的理解。此外，提交者在参与代码审查和讨论中学习到更高效的编程实践和团队协作技巧。他们的这些经验为未来的技术领导角色奠定了基础。

• 提升领域技术能力
• 磨炼一份坚韧不拔的精神力
• 提高自我认同感和成就感
• 积累自身的声望
• 结识一群可爱的朋友
• 提升个人综合素质
• 开源能力： 通过参与开源可以了解开源项目的孵化细节，能够在创建和参与开源项目时起到帮助作用。
• 技术能力： 长期关注开源社区，能让使用者长期紧跟社区最新的技术方向，这也能让你在选型企业级系统中间件的时候有很多选择。
• 学习能力： 通过了解代码细节获得相关知识，成功的开源项目一定是能帮助开发者解决一块领域的问题的，了解作者如何做到这点的细节会对你有帮助。
• 文本能力： 通过贡献 Issues、贡献文档来获得写文档的能力，提升书面叙述解决方案的能力。
• 沟通能力： 开源项目面对的用户是其他开发者，开源项目的迭代一定是要使用者参与的。正确的处理使用者的反馈，通过交流听取使用者的建议，会使开源项目处于一个正向的循环中。
• 提出与解决问题能力： 在解决问题之前，要先学会问问题。精确的提问和解答，可以让你在处理问题时更加得心应手。

开源贡献者（Contributor）

开源贡献者虽然可能不直接参与核心代码的编写，但他们通过解答问题、编写文档、参与讨论等多种方式为项目贡献力量。在这一过程中，贡献者可以在特定领域如文档编写、社区管理或软件测试中获得专业技能。同时，他们在社区中的互动也增强了网络建设和团队协作的能力，这对职业发展是一大助力。

贡献者（Contributor）的职责包括但不限于以下几点：

• 提供反馈
• 帮助新用户
• 向他人推荐该项目
• 测试和报告或者修复 Bug
• 请求新功能
• 编写和更新软件
• 创意美工
• 组织线下活动
• 撰写或更新文档
• 翻译

开源使用者（User）

开源项目的使用者主要通过实际使用软件产品来参与社区。他们通过提交问题反馈和提出改进建议，可以对产品的发展方向产生影响。使用者在这一过程中，不仅提升了解决问题的能力，也可能因为需要自定义功能或修复错误而学习到更多技术知识。此外，他们在社区中的活跃互动有助于建立职业网络，也可能激发他们转变为更主动的贡献者或提交者。

开源使用者作为社区成员，他们最有价值的部分是提出需求、报告缺陷、提出建议。通过提出需求，报告缺陷让你企业级项目里的碰到的问题得到快速解决，也能促进开源项目的迭代，等于是贡献了社区。

从个人角度上来看，开源社区为程序员提供了下面的几种能力：

1. 扎实的专业技术和技能
2. 架构设计能力和模块化思维能力
3. 团队精神和协作能力
4. 文档习惯和写作能力
5. 提问和需求理解能力

开源基金会

开源基金会在推广和支持开源项目发展中扮演着至关重要的角色。通过提供法律保护、资金支持、以及社区建设的帮助，这些基金会确保开源项目能够健康、持续地发展。以下是三个著名的开源基金会的介绍，它们分别代表了开源运动中不同的理念和重点。

Apache 基金会（Apache Software Foundation, ASF）

成立于1999年，Apache 基金会是一个非营利的支持开源软件开发的组织。基金会提供了一个中立的平台，让项目能够在一个合作而不是竞争的环境中发展。Apache 基金会最著名的是其Apache许可证，这是一个宽松的许可证，允许个人和商业用户在几乎没有限制的情况下使用、修改和分发软件。Apache 基金会托管了超过350个开源项目，包括Apache HTTP Server、Apache Hadoop和Apache Kafka等。这些项目广泛应用于商业和非商业的环境中，对互联网的发展产生了深远的影响。

自由软件基金会（Free Software Foundation, FSF）

自由软件基金会成立于1985年，由Richard Stallman创立，是推动自由软件运动的核心力量。与Apache基金会的宽松策略不同，FSF推崇的是更为严格的GNU通用公共许可证（GPL），旨在保证软件自由的四个基本自由：使用、研究、分享和修改软件。FSF支持的项目包括GNU操作系统、GNU Compiler Collection（GCC）和GNU Emacs编辑器。FSF的工作不仅限于软件的开发，还包括法律、教育和政策倡导，致力于保护和扩展用户的使用计算机的自由。

云原生计算基金会（Cloud Native Computing Foundation, CNCF）

云原生计算基金会（CNCF）成立于2015年，是一个专注于推动云原生技术的开源基金会，它是Linux基金会的子组织。CNCF致力于使云原生软件成为互联网基础设施的一部分。它提供了一个中立的协作环境，支持技术的增长和广泛采用。CNCF托管的项目包括Kubernetes、Prometheus和Envoy等，这些项目都是构建现代云环境的关键技术。通过举办活动、提供培训和认证以及其他资源，CNCF推动了云原生技术的创新和实现。

开源项目的说明文件

我们可以在当前的优秀开源项目中找到许多重要的描述文件和设计技巧，这些都是符合基本规范的开源项目所具备的元素。

• AUTHORS（可选）：虽然GitHub自动为每个项目生成贡献者统计信息（可通过链接访问如：贡献者列表），某些项目可能仍希望维护一个更详细的贡献者列表，特别是列出特殊贡献或非代码贡献者。
• DISCLAIMER：免责声明文件，对项目使用的限制和风险做出声明，是法律责任分界的重要文件。
• CHANGELOG：记录项目变更的详细日志。通常包括新功能（Added）、变更（Changed）、移除（Removed）和修复（Fixed）等，帮助用户和开发者快速了解项目的历史变化。
• CODE_OF_CONDUCT：定义社区交互规则的行为准则文件。行为准则不仅阐述社区交流的最佳实践，也是解决社区成员间潜在冲突的基础文档。
• CODEOWNERS：GitHub特有的代码所有者文件，用于指定文件或目录的代码所有者。当相关文件或目录有Pull Request（PR）提交时，系统自动通知这些代码所有者进行审查。
• CONTRIBUTING：详细说明如何参与项目贡献的指导文件。它描述了项目需要的贡献类型，以及如何按照项目的工作流程进行有效的贡献。
• LICENSE：开源许可证文件，声明项目采用的开源协议，是任何开源项目不可或缺的法律文件。
• NOTICE：通常与LICENSE文件一同使用，用于存放必要的法律声明信息，如版权、专利或其他法律信息。
• README：项目的核心介绍文件，通常包括项目的目的、用途、安装步骤、快速启动指南等。README文件是用户首次接触项目时获取信息的主要来源。

除此之外，我觉得一个开源项目，也是有一个项目文档提供给用户和贡献者阅读学习。

企业眼中的开源

开源本身是很好的，非常利于行业的进步和发展的，纵观历史，只有拥抱开源，解放思想，乐于分享，才能够有更加长足的进步和发展。

开源的优势也很好总结：

• 开箱即用（开源框架随时可用）
• 选择性多（开源社区资源丰富）
• 方便快捷（很快就能搭建出来）
• 技术解决方案交流（社区群）

但是不可避免的，对于企业商用来说，选择开源社区项目也是需要小心翼翼的。

从企业视角看，开源软件还涉及产品外销时的知识产权法务风险、企业的研发效率、产品架构、软件生态系统、开放标准构建手段、人才竞备、商业利益角逐等。 企业可以用多个视角去理解开源的意义和价值

企业用多个视角看待开源

1. 把开源看作是一个外购件或技术获取方式，看到的问题是：如何开源选型获取新技术？如何在软件生命周期过程有效迭代管理？
2. 把开源看作外部协作的一种方式，看到的问题是：获取外部人才的一种方式。与社区的技术人员、以及其他公司协作。
3. 把开源当做发展手段：看到的问题是如何在新技术领域产生影响力；在新的技术和业务领域，如何通过开源，站在行业发展前沿等问题。

就算是在传统的商业公司的角度上，使用开源的项目代码占比也将会高于百分之八十以上，那么可能会为传统的企业带来下面的一些隐患：

1. 版权许可证（License）选择不慎会潜伏知识产权法务风险，成为企业拓展海外市场的绊脚石。
2. 不同团队选择多种同类开源软件会带来巨大的管理成本。
3. 产品研发初期，如何在众多类似的开源组件中选择合适的代码？方向选择错误会导致陷入产品生态与业界不兼容的困境，面临放弃重写还是继续往下走的两难抉择。
4. 产品开发时难免会对代码进行修改，修改后的商用代码是闭源还是开源？随着时间的推移，社区版本更新迭代，继续闭源，意味着会重复投入资源，进行不增值的代码合入；而开源则意味丧失产品竞争力。
5. 主动开源并不意味着社区就能接纳，需要长期有大量的回馈代码才能建立信誉及影响力，公司内的社区管理人员才能得到锻炼和培养。但是，社区管理人员个人知名度的提升会增加被猎头公司挖走的风险。
6. 软件在开发过程中或完成之后，如果出现同类开源软件，该如何处理？

企业为什么要开源

企业都以追逐利益为目标。

传统企业以及一些大型的互联网企业为什么还会选择开源或者在开源上投入精力，原因如下：

1.吸引人才： 当贵司依赖开源软件，那么寻找人才最好的地方莫过于熟悉项目内部本身，而且还是项目社区成员。通过在社区的公开的工作，贵司可以吸引到一些既是做自己喜欢的工作，还能获得一定报酬的人。尤其重要的一点，贵司现有的项目参与的员工，每天都会和他们在一起打交道，自然是非常熟悉的，找到他们也很容易；

2.降低维护成本： 如果一个企业开始在本地的分支做缺陷修复、增加新的功能，然而却没有将这些代码提交到上游的开源项目中，那么很快维护本地的分支，将成为该公司的一个成本噩梦。将上游作为优先的提交缺陷修复和增加新功能是最为明智的做法，因为这样的维护成本最低；

3.项目影响力： 在一个开源的项目中，新的特性或功能来自社区的贡献，那么这些贡献就会影响到项目的走向，如果你认为为项目所贡献的新功能对于贵司非常的重要，那么你应该去安排积极的贡献者对这些功能进行开发和实现。通过贵司的贡献，自然而然就可以影响到项目的走向；

4.有利可图：商本逐利，无可厚非。一方面，对现有开源项目的贡献可以让企业在降低维护成本的同时促进相关业务的发展，获取利润；另一方面，开源本公司的个别项目吸引全球各地的开发者共同维护，借助开源的优势扩大该项目在本行业的影响力，扩大市场占有率，在保持项目开源继续发展的前提下，通过附加其他手段来获取丰厚的利润回报。

企业反馈：

最初并不认为使用开源软件有什么成本，但经过两三个版本的迭代以后，成本会急剧上升。一般公司经历了多次实践后才认可这种模型，这是付出了惨痛代价以后才意识到的。如果从一开始就选择与社区合作，就可以与社区一起讨论产品的特性，然后再进行修改。最初的维护成本并不高，研发的成本会很高，但由于所要求的团队能力并不一样，维护成本会逐渐降低。

基于开源软件修改，社区下一步准备做什么、怎么做，然后就都清楚，与社区有很好的互动沟通。虽然在前期投入了很大的成本，但最终取得了相应的成果。

这也是我认为比较推荐的地方，企业如果只是把开源项目的代码 fork 过来自己闷着头改，这样的成本也是非常高的。项目就像是一个黑匣子一样，不知道会遇到什么问题，不知道会发展成什么样的。

一般的企业参与开源的概念：

目前，包括阿里巴巴、腾讯、华为在内的一大批巨型企业都在为争夺这片市场而努力。那么，怎么才能在这场争夺中迅速获得优势呢？

一个最简单的思路，就是让本企业的标准成为整个行业的标准。（比如 kubernetes 作为容器编排的标准）而要达到这一点，企业就首先要让自己的标准有足够的使用者。显然，为了达到这一目的，开放自己的底层技术，吸引更多的研发者在此基础上进行建设，就是一个非常好的市场争夺策略——一方面可以争取直接的用户，另一方面还可以通过产品的丰富来吸引更多的间接用户。

最终，借助网络外部性的力量，它们就可以迅速夺取市场。

开源到商业化

任何新鲜事物的产生都是需要时间来慢慢适应，然后才能找到与现有事物的平衡点。虽然现在国内的开源形式较好，但发展开源并非是一帆风顺的。

1.开源需要付出很多精力去维护，必然不能依靠个人的力量去管理维护，由于投入精力的不足，往往会导致项目胎死腹中的情况。

2.开源项目获取关注度的方式有限，一个项目从孵化到使用，经历的时间往往会比较长，在从零到一的过程中，开源者大多需要经历孤军奋战、无人问津的局面，再加上工作生活上的压力，项目可能会因此戛然而止。

3.开源项目回报率太低，项目优秀与否，更多的是在技术上得到的认可，但物质方面却一直“歉收”，因此，项目可能因为资金问题而折戟。

4.开源项目没有明确规划，开源者对项目的前瞻性不够，或者开源组织对项目的信心不足，都会导致项目的遗憾中断。比如大名鼎鼎的Dubbo就曾经一度停摆，直到 2017 年才重启回归。

开源百花齐放

开源软件代表了一种新的技术产生方式。顶尖的高校研究成果很多都是以开源形式发布的，顶尖公司（如谷歌）的技术架构中，每套系统基本都有其对应的开源项目。

1. 开源社区的运作越来越职业化。自由参与和自组织时代已经过去，近年来，开源逐步过渡到公司化运作模式。Linux 基金会下的很多项目，比如核心基础架构联盟（Core Infrastructure Initiative，CII），都是各公司出钱，把钱放在一起经营，更像是一个合资公司；OpenStack 等基金会有明确的章程、组织结构、晋升机制、会议制度等。开源社区的运作越来越职业化。
2. 开源成为另一种标准制定方式。电信领域存在设备对接，因而有着非常严格的规范和行业标准。同样，IT 领域行业差异性大，各公司通过代码发言，在社区用代码的方式完成与其他厂商的对接和配合。从云计算 OpenStack 的接口定义等社区实践来看，开源已成为另一种标准制定方式，标准组织开源化已成趋势。
3. 开源重新定义了集成和被集成的关系。过去，IBM、惠普等大厂商都有各自的生态合作伙伴规程，策略都围绕本公司集成的。从云计算开始，这种方式发生了微妙的变化，开源扮演着集成的身份，各厂商（比如存储、网络、防火墙等厂商）都到开源平台上进行集成和对接。

开源与商业化呈现

其实，即使是一个新手，如果你已经了解了各种开源协议，相信你已经成功摆脱了「开源=免费」的错误理解。就像「开源=免费」这类常见误区一样，大家可能会想当然地认为开源与商业化毫无关系，或者认为开源与商业化是互斥的。

并不是这样的，我认为反而开源和商业化本身就是相辅相成的。

很早以前我以为的开源是不涉及任何的利益交互，纯粹的开源，最真诚纯粹。但是后面逐渐的过程中自己慢慢去接触开源的过程中，我越发认为 开源软件要想做好，就必须认真考虑商业化的事情。

开源软件项目如果想要长期成功和持续发展，考虑商业化是一个重要方面。商业化可以为开源项目提供必要的财务支持，确保项目的可持续发展、稳定的人力资源投入，以及更高水平的技术支持和用户服务。例如，通过商业伙伴关系、付费支持服务或增值产品，开源项目可以获得资金来支付开发者，维护基础设施，和推广项目。然而，这种商业化也可能带来挑战，包括可能的使命偏移，社区中的利益冲突，以及对项目原始开源精神的侵蚀。因此，开源项目在追求商业化的同时，需要仔细平衡其开源原则和商业需求，以保持项目的健康和社区的活力。

用一个不知是否恰当的比喻：当今的开源盛世，像极了 14 世纪到 16 世纪的文艺复兴。而随着知识付费时代的到来，对于开源发展而言，此时推动开源的商业化是最好时间节点。开源的商业化探索，不仅是对开源贡献者的回馈，更是促进开源社区发展的「强心剂」。

开源与商业软件对比

开源软件与商用软件的关系就像太极一样，两者并非互相对立、互相矛盾的，而是互相促进、相辅相成的。在这短短几十年中，开源与商用彼此交织，通过制定完善的规定与制度，共同推动着行业发展。

开源软件的优点：

商用软件的优缺点描述

参考 各有利弊，开源和商业软件应该怎么选？(opens new window)

开源商业化的本质

开源商业的本质就是找到边际成本足够低的部分，将价格降到底，以期望用户使用实惠的产品后，倾向于购买其他互补品，后通过互补品实现收益大化。商业化的核心问题就是如何框定这个边际成本为0的范围，如何选择合适的互补品，以及如何对互补品定价

回首看开源发展的这些年，提供给我们研究的开源项目成功的案例有很多。众多优秀开源项目：GNU/Linux、MySQL、Red Hat、Ubuntu、Apache、OpenJDK、Firefox、Spring 等。现如今，随着开源社区的不断发展，各大企业纷纷拥抱开源，利用开源进行商业布局。因此，我们有充分的理由可以认为“开源是可以进行商业化的”。

那么如何进行商业化呢？这个问题并没有一份标注答案，每个成功的开源项目都有着不同的商业化轨迹，但或许能够从它们的共性上找到答案。首先，需要考虑项目是否已经具备商业化的价值，如果项目不够成熟，无法承受住市场的检验，必定是无法商业化的。其次，需要对项目商业化模式有清晰的认识，不同的商业模式有不同的商业化属性。最后，需要做好项目的维护工作，保持团队和社区的活跃，对使用者而言，更能相信该项目是一个稳定的开源项目。

这也是我参考了好多个开源项目后总结出来的一些个人思考。

通常来说从一个项目开源到实现收益的整体流程如下：

1. 从互补品上收益获利
2. 转化为对互补品的需求
3. 快速迭代，社区流行
4. 软件代码开源，免费提供

可以看到从最初的开源到最终取得成功，必须要经过良好的社区运营。而在这个基础上我们也可以分析到一个项目实现开源商业化的前提条件：

• 普遍性以及竞争性
• 用户基数大
• 社区生态完善

商业化几种模式

在充分调研社区资料后，总结了5种主流的开源商业模式：

• Dual-License双授权：代码具有两套许可证，一套开源许可证，另一套商业许可证
• Open Core双版本：一部分软件开源，另一部分增值功能闭源收费
• 打包和技术服务：基于开源项目提供打包、技术支持、培训或项目咨询服务收费
• 托管云服务：企业用户付费使用云端的开源服务，无需搭建软件使用环境
• 生态收益：通过开源获取生态流量入口，然后利用流量进行变现

分别介绍上面的几种模式：

1. Dual-License双授权模式

“双授权"模式指的是软件具有两套许可证。一套是传统的开源许可证比如 GPL(免费) ，另一套是商业许可证(收费)。基于开源许可证可自由开发但要求开放源代码；基于商业许可证可实现代码闭源但需收费。

像比如MySQL此类软件就是采用Dual-License双授权模式：基于GPLv2商业限制性协议开发，客户在购买商业许可证后可基于开源版本二次定制并进行售卖

2. 打包和技术服务模式

开源软件的维护、部署、咨询和升级等活动统称为技术服务。企业通过提供这些服务来获得利润，尽管开源软件本身是免费的。这种商业模式的核心收入来源是为企业提供持续的服务保障。

开源软件公司的运营通常经历以下四个阶段：

1. 参与（Engagement）：

• 在此阶段，公司积极参与开源社区的活动，贡献代码，修复bug，并与其他开发者建立联系。通过这种方式，公司不仅增强了软件的功能和稳定性，还建立了在行业中的声誉和可信度。

2. 集成（Integration）：

• 在集成阶段，公司将开源软件与其他系统或应用进行集成，以满足特定行业的需求。这包括定制开发以适应特定的技术栈或业务流程，使开源软件更加适用于商业环境。

3. 稳固（Stabilization）：

• 此阶段的重点是确保开源软件的稳定性和可靠性。公司会进行广泛的测试，解决各种环境下的兼容性问题，并优化性能。这有助于提升客户信心并减少未来的支持需求。

4. 服务（Servicing）：

• 最后，服务阶段涉及提供持续的技术支持和升级服务。这包括定期更新软件以应对新的安全威胁，提供定制的功能增强，以及应对客户的技术咨询和故障排查。公司在此阶段通过订阅服务或按需服务模式获得收入。

而此类模式的代表则是红帽，红帽是第一家靠提供技术支持做到 10 亿美元营收的公司。在其“技术支持”模式存在的 20 年间，没有其他公司能够替代红帽

红帽公司提供多款基于开源软件的产品，包括：基于Linux内核的操作系统稳定发行版、基于Kubernetes的云原生管理平台OpenShift以及基于Ansible的自动化运维平台等；同时提供各类软件的培训以及咨询服务

3. Open Core双版本模式

Open Core双版本模式是目前最为普遍的开源商业模式，此种模式只开源核心（core）部分，而一些周边是非开源且需要付费的。简单理解就是提供两套版本：

• 社区版免费，不稳定因素较多
• 商业版收费，保障生产级别的功能、性能以及稳定性

而这些付费功能包含如下：

HashiCorp是一家典型的从开源到商业化转型成功的基础设施软件服务商，主要提供Cloud和DevOps基础设施自动化工具，集开发、运营和安全性功能于一体，开源了包括：Vagrant、Packer、Terraform、Vault、Nomad以及Consul等六款明星级项目

而HashiCorp从开源到商业化主要经历了三个阶段：

• Community incubating：孵化以及培育社区，迭代项目功能
• 初期商业化产品：提供针对开源项目的企业版收费产品，接触最初的一批客户，进行市场以及商业模式探索，为商业化的过度准备阶段
• 核心成熟产品：经过最初市场探索迭代总结的可规模复制的核心产品，可进行大规模商业化推广

而国内的PingCap TiDB也是此类模式的典型代表。2015年4月PingCap成立，并于同年9月份开源了TiDB分布式关系型数据库，一个月Star数超过 2700，得益于TiDB的商业化，2020年宣布完成2.7亿美元的D轮融资，同时TiDB成为最流行的国产数据库，GitHub 5.3K Forks + 32.8K Stars。并提供基于开源TiDB的企业版以及SaaS服务

4. 云服务模式

云服务收费模式指开源厂商将开源软件部署在云上，企业用户付费使用构架在云端的开源服务，无需执行搭建软件使用环境。这种模式的价值点在于云为软件提供很好的分发渠道，用户可更加便捷地购买软件。在选择这一模式后，企业避免本地部署、运维步骤，节省了人力成本，同时让用户以按需付费、即用即付的订阅方式来完成整个过程，为企业使用软件带来了极大便利。这一模式亮点在于边际成本递减，可规模化潜力高，风险在于服务构建于云厂商，而云厂商会利用开源版本与开源公司形成直接竞争关系

此类模式比较典型的代表是Databricks，Databricks开源了Spark、Delta Lake、Redash、MLflow等流行开源项目，并主要基于公有云提供这些开源项目的收费服务

除此之外，还有熟悉的社区，sealos, kubespray

而国内各大云厂商，阿里云、华为云、腾讯云等，均提供主流开源软件的云服务，涵盖操作系统、中间件、数据库等领域。阿里云数据库服务……

为了规避这种‘薅羊毛’的行为，开源厂商一般会将完全开源的协议(eg：Apache)转化为限制性商业协议(eg：GPL)，这样云厂商必须购买商业许可证方可售卖SaaS服务，很大程度保障了开源企业的利益

5. 生态收益模式

企业以开源软件作为流量入口，构建开源软件应用生态，从而获取利益。此类模式的开源主体一般为拥有高价值开源项目的巨头企业或者社区，例如谷歌安卓操作系统以及云原生计算基金会CNCF等

开源企业发展阶段

正如上述分析过的HashiCorp公司商业化阶段一样，一般来说一个开源企业的发展会经历孵化器、产品验证器以及价值变现期三个阶段：

1. 孵化器阶段（Incubator Phase）

在这个阶段，重点是构建一个初步的、功能性的开源项目，以吸引早期的用户和开发者。企业或项目团队会集中精力在以下几个关键领域：

• 技术开发：构建项目的核心功能和架构，确保软件的基本稳定和可用性。
• 社区建设：吸引和培养开源贡献者，建立一个活跃的社区环境。社区成员可以帮助改进产品、提交bug报告、提供新的功能建议。
• 品牌意识：通过各种渠道（如技术会议、博客、社交媒体等）提升项目的知名度。
• 初步反馈：收集早期用户的反馈，用于指导后续产品的开发和改进。

2. 产品验证器阶段（Product Validation Phase）

在产品验证阶段，开源企业开始寻求证明其产品在市场上的可行性和吸引力。此阶段的重点包括：

• 市场反馈：更系统地收集和分析用户反馈，了解产品满足用户需求的程度。
• 商业模式试验：实验不同的商业模式，例如通过提供付费支持、增加额外的付费功能或服务等方式，寻找收入来源。
• 增强产品功能：基于用户的反馈，不断完善产品功能和性能，增加新的特性来满足更广泛的用户需求。
• 扩展用户基础：扩大市场覆盖，吸引更多的企业用户和大规模部署场景。

3. 价值变现期（Monetization Phase）

一旦产品在市场上得到验证，开源企业将进入价值变现期，目标是实现商业成功和持续增长。在这个阶段，企业将专注于：

• 商业产品推广：推出和推广付费版本的产品，这可能包括更高级的功能、更好的性能和专业级的支持服务。
• 扩展销售和营销：建立或扩大销售和营销团队，采用更加系统和专业的市场策略来推动产品销售。
• 合作伙伴关系：与其他公司和组织建立合作伙伴关系，扩大市场影响力，提供整合解决方案。
• 可持续盈利模式：确保公司拥有一个可持续的盈利模式，能够支持公司长期的发展和扩张。

而每个阶段的关注点以及衡量指标也各不相同：

这里举例MongoDB来说明一下开源企业发展阶段。MongoDB在2007年成立，2009-2011专注孵化社区，2011-2012开始推出企业版并进行商业化尝试，2012-2016持续进行营收规模扩张

开源商业化时长

这里对国内外一些典型的开源公司以及项目进行了开源商业化时长统计：

从上面的数据可以得出如下两个结论：

• 开源~营收时长：1-5年
• 营收~盈利时长：1-3年

因此企业对待开源这件事情必须要有一定的心里预期：大概率短期内无法实现营收或者盈利，同时前期还需要投入一定资源运营社区。

如何实践商业化

我分析认为开源项目的商业化道路是有复制的捷径的。

确定项目 → 竞争分析 → 开发流程 → 开源宣传 → 商业化思考

确定要做什么

如果你有开源的想法，面临的第一个问题应该就是要做一个什么样的项目。这一步至关重要，很多想要开源的同学就因为这步选错了，导致了项目刚开始或者做到一半就放弃了。

那在聊你要做什么这个问题之前，我们先聊下你不做什么。

• 大型的框架或软件，比如做一个 IDE 工具，开发一门新的脚本语言，一来涉及面太广，短期内做不完，二来你也并不一定有能力去解决处理到大型框架软件所涉及的技术细节。
• 重新造一个轮子，比如重新写一个 RPC 框架，重新写一个 ORM 框架。这些领域都相对比较成熟，是每个项目的基础中间件的选型，已经有非常成熟的方案，用户的使用习惯很难去改变，也意味着即便你造成了轮子，用户也最多是学习，而不会很大规模的使用到生产环境中。
• 无法通用的项目，比如只能在你公司某个特定业务场景中起到作用，这个场景非常单一。对于其他的用户来说，这个项目就没多大价值。
• 非常小众的东西，即便你做出来，因为对大多数人来说，并用不到这东西。所以最后影响你项目的推广。

那如何选择你要做什么呢。选择一个相对合适的赛道非常重要，有几点建议可以供你参考：

• 尽量选择一个比较精准的痛点，而市面上的相关开源软件选择相对比较少，做一个小而美的项目，比做一个大而全的项目要来的更容易起步，开发周期也比较快。
• 即便赛道上有类似的开源项目，你也可以寻求差异化，在某一个方面做到极致。比如更加轻量化，易用性更强，支持的扩展更多，维度更高。
• 尽量选择可以持续发展的项目，小到可以解决某一个痛点，大到持续发展可以帮助一个领域解决问题。
• 做大众化的项目，能被大多数场景运用，这样有利于你的推广。

分析同赛道的产品（竞争分析）

如何分析同类型产品的竞争

1. 看同类产品项目的 Star 数
2. 看这个项目是否一直在更新
3. 看 Issue 数量和评论数量

找到这样的一个项目后，可以去看看这个项目的特性，这会帮助你在设计你的项目时了解所需要关注的点，有可能有些特性你是没有想到的。然后最好去 Clone 这个项目的代码到本地，如果有时间，最好还是仔细的去阅读下人家的代码。如果读不懂，一般成熟的项目总有例子和单元测试。最好亲自去跑下别人的例子和单元测试，再结合项目的特性，能帮助你对这个项目有更好直观上的理解。

如果你发现在这个赛道里有一大批活跃高 Star 的项目，他们也各有特点。基本上可以解决所有的这个领域的痛点。那么还是建议你换一个赛道。你的项目一定要有自己的特点，如果你的项目的特性，使用方式都和其他项目差不多或者还不如其他项目，那为什么指望用户用你的项目呢。

阶段目标

如果你已经选好了赛道，你需要为你的项目制定一个短期目标。

所谓短期目标其实就是你的项目第一个稳定版本应该达到的预期。在做短期目标的时候，应该以实际为主，切勿目标定的很宏大，过大的目标会消耗你太多的开发周期，正所谓一鼓作气，再而衰，三而竭。一口气吃不成胖子，长周期的开发本身就是一件需要毅力的事情，而很多人会在这漫长的周期内会被消耗掉原先的激情。

相对确定，短小的目标可以令你缩短开发周期，迅速达成。本来开源软件就是一个漫长的迭代过程，假设你有一些宏大的目标，都是可以通过慢慢迭代实现的。而快速放到开源社区的另外一个好处是，可以通过社区的正向反馈来调整你的迭代的过程。毕竟开源项目一开始的所有特性和功能基本上都是你一个人拍板的，但是开源之后，你可以了解到更多人的反馈。有些一开始的想法会随着反馈的增加而进行改变。这也是自我思想迭代的一个过程。

对于中长期目标我的建议是，在你第一版的时候可以先计划下大概的方向，在项目架构层面留好可以扩展的方向。但是细节点可以不用在这个阶段过多考虑。

项目架构

开源项目的初始架构至关重要，你之后的迭代都是围绕这个整体架构进行的，当然中间也可以进行重构，但是付出的成本要大很多。在设计项目架构时，有以下几点建议：

• 尽量选择较新比较流行的选型。老旧过时的选型在用户使用时可能会碰到兼容等各种问题，选择一个流行的选型会最大程度上降低这种问题的发生。
• 精简你的依赖，只选择你的项目必须的依赖。过多的依赖也会导致兼容性的问题。
• 一开始就要考虑到扩展性，模块之间的松耦合做好，边界定义清晰，这对项目之后的良性循环很重要。
• 在设计之初就要考虑到使用者环境的多样性，比如同一个选型的不同版本，不同操作系统等等。

开源运营成功经验

为了更好的制定开源运营策略，这里研究了TiDB社区运营的一些细节，希望从TiDB学习如何孵化以及运营开源社区，下面分几个方面依次介绍

1. 详细的文档

TiDB提供了详细的文档，覆盖了TiDB所有生命周期环境，包括：部署、开发、迁移、监控告警、性能调优、问题定位等。

2. 齐备的开发者社区

PingCap创建了各类开发者社区，包括：内部社区、Slack Channel、OSS Insight以及社区问答等。

3. 丰富的资料以及资讯

关于TiDB国内外的资料以及资讯很丰富，包括：Twitter、StackOverflow以及Team Blog等。丰富的资料以及资讯有助于让用户全方面了解项目相关内容

4. PingCap Education

PingCap具备完善的教育生态，包括：TIDB认证、TIDB课程、企业培训、名企直推以及校企合作等。完善的教育生态一方面可以起到宣传推广的效果；另一方面可以促进校企合作，进一步完善开发者生态：

因此，总结来说一个项目如果要运营的比较成功，需要具备如下几个条件：

• 详细的官方文档：帮助用户快速使用项目，理解架构
• 齐备的开发者社区：帮助用户定位解决问题，深度参与项目
• 丰富的资料以及资讯：帮助用户全方面了解项目相关内容
• 教育生态：校企合作，极大提高项目知名度以及普及率

开源项目推广

开源项目的宣传是非常非常重要的，尤其是一个优秀的开源项目成熟后，可以吸引很多的用户和贡献者都加入到社区。

如果开源项目分值数太少，可以和开源课程、自媒体、公众号、短视频、写书等结合在一起，既可以为项目加分又可以传播开源项目知识，增加开源项目的流量访问，同时也贡献了自己的一份开源力量。

这也是开源项目的主要的推广和宣传手段 ~

下面将介绍如何借助国内一些比较有影响力的开源项目推介平台，免费获得项目推广的机会，通常这些平台也需要优秀的项目为之充实内容，因此，只要项目质量过硬，这应该是一个双赢的合作。

注意： 其实在我的开源经历中，我认为是一个优秀、稳定的开源项目其实是更利于推广和宣传的，而那些不稳定，bug 频出的开源项目如果宣传可能会适得其反 ~

GitHub

有不少推介平台，本身也是倚靠GitHub作为底层数据来源与支撑，于是我把这一类，统一规在GitHub当中。

可以建立开源项目的官网，做好SEO，方便搜索引擎收录

科技爱好者周刊

国内互联网名宿阮一峰先生创建的周刊，已经成为众多互联网人每周五必读的一个刊物，受众垂直且数量庞大，是最值得推荐的一个去处之一。且阮先生通常对于优秀项目，向来都是不吝推荐的，因此非常推荐在其项目的issue当中进行个人项目的推介。

• 提交方式通过issue提交自己的开源项目。
• 其他的同步平台： 阮一峰博客 | flowus | 公众号

HelloGitHub

其以每个月一次的月刊受人瞩目，每次月刊一经发布，就会引来大量读者围观，是你开源项目推介的优选之处。

• 提交方式： 通过issue提交自己的开源项目。
• 其他同步平台： 博客月刊 | 公众号

GitHubDaily

GitHubDaily 类似推广平台，目前该项目GitHub有16k star，也是一个推荐个人项目的好地方。

• 提交方式： 通过项目issue可以提交自己的项目。
• 其他同步平台： 公众号 | 微博 | 知乎

Awesome-GitHub-Repo

• 简单介绍

Awesome GitHub Repo 会收集整理 GitHub 上高质量、有趣的开源项目，并将他们进行归类。值得注意的是，不是简单的按照编程语言来分类，而是按照更有趣的分类方式，比如：有趣项目、沙雕项目、实战项目、学习项目、实用工具等等。

• 提交方式: 通过项目issue可以提交自己的项目。
• 其他同步平台: 公众号 | 知乎

Go语言爱好者周刊

• 简单介绍

如果你的开源项目是Go语言项目，那么往go语言中文网站长创建的Go语言爱好者周刊推介自己的项目，就是一个合适的选择，尽管这个项目影响力还有限，但在go语言领域，还是很有话语权的。

• 提交方式: 通过issue提交自己的开源项目。
• 其他同步平台: go语言中文网 | 公众号

论坛

有一些技术论坛，其中的垂直映射影响非常直观，这里也作为一个个人项目推介的渠道。论坛的提交方式全部都是通过个人账号发帖。

1.伯乐在线 http://www.jobbole.com
2.CSDN http://www.csdn.net
3.简书 http://www.jianshu.com
4.知乎 https://www.zhihu.com/

写完之后再发链接到码农活跃的分享平台：

1.掘金 http://gold.xitu.io/

2.开发者头条 http://toutiao.io/

3.极客头条 http://geek.csdn.net/

4.干货集中营 http://gank.io/

v2ex

v2ex的技术氛围可算是最强的，如果你的项目足够优秀，且能够在一个合理合适的时机发布分享，通常都会引来不少关注度，以及讨论。

据我观察，通常在周五上午发布会是一个合适的时机，其他时间段都不算是个合适的点，尤其不要想着周末发布，往往最后的数据会很惨淡。

learnku

learnku也是一个不错的推介个人开源项目的论坛，不过貌似发布的内容通常围观度很是玄学，得看命。

其他一些地方，大概可以作为同步分享的一个场所，这里同步陈列如下：

• 掘金
• Gitee：如果你的项目足够优秀，借助gitee的自动同步能力，然后点击项目名右侧的推荐按钮，一旦成功，也能获得一些关注度。

一些社区运营的经验分析，总结自己在参与开源的几年中，获取到的经验分享：

Reddit - 论坛： Reddit 相当于国外版的贴吧，但是技术氛围相当活跃，一些最流行的技术讨论经常会在 Reddit 中发起。

Medium - 博客： 不管是从排版还是社区曝光度来说，Medium 都很适合作为博客站点，当你在官网点击【Blog】按钮，会直接跳转到自己项目的 Medium 主页，而且支持自定义域名。medium.com

Hacker News - 论坛： Hacker News 同样是国外在技术圈十分活跃的论坛，别看排版简单古老，充斥着一种上个世纪 BBS 风，但是内容硬核，经常可以看到非常有价值的讨论。

Wechat - IM、公众号： 国内使用最多的 IM 工具是微信，所以我们建立了多个微信群，用于和社区用户的日常沟通，同时微信公众号也是重要的内容运营渠道。

Slack - IM： 和国外用户的日常沟通使用 Slack，同时也会通过 Slack 参与到其它社区的讨论中

腾讯会议 - 社区会议： 社区双周会使用腾讯会议。

参考资料

• Chatgpt
• 开源指南
• 开源商业化的思考
• The Open Source Definition
• Open Source Summit Trip Report by Guido van Rossum
• Why Open Source misses the point of Free Software by Richard Stallman
• 《大教堂与集市》Eric S·Raymond，卫剑钒（译）
• 《若为自由故》by Sam Williams，邓楠 / 李凡希（译）
• 《只是为了好玩》Linus Torvalds / David Diamond
• 《黑客与画家》Paul Graham，阮一峰（译）
• 《Git 权威指南》蒋鑫
• 《GitHub 入门与实践》大塚弘记，支鹏浩 / 刘斌（译）
• Open Source Hardware Association
• Open-source hardware
• FOSS 的历史
• Richard Stallman之 GNU/Linux 问答
• Vue 出版如何宣传的
• 硅谷揭秘：开源如何选择商业模式并构建护城河？