文章目录
- 一、前文
- 二、开放源代码=开源？
- 三、社区胜于代码
- 四、左手开源，右手商业
- Open Core模式
- 服务和保险模式
- 云服务模式
- 五、商业模式的优劣
- 六、销售模式的改变
- 七、个人如何做一个开源项目
一、前文
里偷闲已经看了一半多。
在专题《开发者黄金十年》中，看了一个个大佬对开源的理解，深有感触。
其中一句“建立在开源基础上面的软件公司具有成为数十亿美元级别企业的潜能”，更加让我信心百倍，热血沸腾。
我自己本身很早就有开源的梦想，希望做出一个牛逼的项目，并开源出去。这相信这不是只有我，很多程序员都有这个想法！
但这也是自己当初最粗浅的想法，怎么开源？开源后怎么吸引志同道合的朋友来？开源后能赚钱恰饭吗？
很多问题没搞懂，很多事情没想明白。直到从昨晚开始看了这本书之后，突然有种拨开迷雾的感觉，脚底的路已经依稀可见。
其中一句“建立在开源基础上面的软件公司具有成为数十亿美元级别企业的潜能”，更加让我信心百倍，热血沸腾。
如果能够做自己最喜欢的事情，还能实现财务自由，那是啥，是天堂吗？
开源，永远是开发者最热爱的。
二、开放源代码=开源？
那我们重头开始聊，开源是什么？
是不是公开源代码的软件就是开源软件呢？当然不是。
按照 OSI 组织（Open Source Initiative Association）的 OSD 定义，除了公开源代码，开源软件的发行条款还必须符合以下十个条件：
序号 | 条款 | 简单说明 |
1 | Free Redistribution | 允许自由地再发布软件 |
2 | Source Code | 程序必须包含所有源代码 |
3 | Derived Works | 可以修改和派生新的软件 |
4 | Integrity of The Author’s Source Code | 发布时保持软件源代码的完整性 |
5 | No Discrimination Against Persons or Groups | 不得歧视任何个人或团体 |
6 | No Discrimination Against Fields of Endeavor | 不得歧视任何应用领域（例如商业） |
7 | Distribution of License | 许可证的发布具有延续性 |
8 | License Must Not Be Specific to a Product | 许可证不能针对于某一个产品 |
9 | License Must Not Restrict Other Software | 许可证不能限制其他软件 |
10 | License Must Be Technology-Neutral | 许可证必须是技术中立的 |
除了源代码之外，还需要技术文档和一个开放性的社区，接收用户和开发者的反馈信息，共同探讨开源软件的发展。
如果仅仅是一个公司抛出一个产品，并开源它，这个并不是真正的开源。如果没有文档，没有后续的社区运营（支持、回复反馈等），这也仅仅是一堆代码，开源世界并不缺乏代码。
总的来说，
- 开源是一种过程的反应，而不是结果。
- 开源也不是一种商业模式，因为它不反馈结果（可以获得多少收入利润）。
- 开源可以说是一种手段，开源企业也是需要盈利的，开源只是他们的一种商业手段。至于如何盈利，下文聊。
三、社区胜于代码
Community > Code
Apache之道（Apache Way）的核心：“社区胜于代码”。
开源软件不在于它本身，而在于有多少人使用他。代码是死的，人是活的，使用代码的是人。
- 一个社区真正的诞生，是在你和你的代码之外，开始有第三者介入并产生连接的时刻， 可能是收到第一个外部PR(Pull Request)，也可能是收到第一个外部Issue，这些才是社区的开端。
- 社区开端之后的初期推广，往往是创始人的个人影响力发挥作用，进行前期用户积累。当用户积累到第一阶段的时候，这时候的开源项目往往会迎来一个死亡鸿沟。
- 死亡鸿沟出现的原因是产品成熟度迟迟没有跟上，用户过来以后发现都是坑，随之而来的各种问题会让早期支持者和创始人疲于奔命甚至是失去兴趣。最终导致该项目的失败。
- 而度过死亡鸿沟的开源项目开始趋于稳定和成熟，并获得了用户的初步信任。这时候就会有更多的用户开始实际应用，并提出各种意见。开源就是善于听取用户的意见，但也要懂得分析、取舍和平衡，同时不要影响你内部开发的路线，把握好开源项目的大方向。
- 当你的开源项目有稳定的用户群，持续不断稳定的迭代更新时，你也进入了开源软件竞争的中后期，易用性和用户体验要开始放在最高的位置。因为这时候你的开源项目会吸引来一些愿意付费的用户，而这些愿意付费的用户，他们的首要要求就是：用着省心，用着顺手。
四、左手开源，右手商业
辛辛苦苦搭建一个优秀的开源项目和社区生态，其中无数用户和企业从中获利。而最大的功臣（创始人）两袖清风，不去考虑盈利，这样合理吗？你信吗？图啥呢？为爱发电吗？
基本大部分的开源项目最终都会实现商业化，而通过开源项目的商业化也能够反哺社区，更好地促进开源发展，形成良性循环。
开源商业主要有以下几种模式：
Open Core模式
Open Core的模式，也叫双版本模式。即发布两个版本：
- 一个是开源社区版，提供开源软件的核心功能
- 一个是付费企业版。基于社区版增加增值功能，比如数据安全、传输加密、容灾备份、可视化监测系统、专业管理工具等等。
个人爱好者，使用开源社区版玩一玩，是没有问题的。
但是大企业使用软件，必然要考虑得更多。他当然也可以自己在开源社区版的基础上面进行开发，但是其开发维护的成本一定比购买原厂的产品高。
购买付费企业版，也再次强调了开源项目中后期的要求：用着省心，用着顺手。大企业大客户愿意付费的前提是你的软件用着省心，用着顺手。
以InfluxDB为例，除了开源的社区版本之外，InfluxDB还有云服务版本，企业版本。
相对于免费的社区版本，企业版本提供了高可用、水平扩展。细粒度访问控制、增量式备份等功能。
服务和保险模式
服务
提供基于开源代码上的服务，包括但不限于培训，实施，技术支持等等
保险
提供基于开源软件上的及时响应和快速运维的服务。
采用开源软件，倘若在没有原厂的支持下出现任何技术问题，或导致整个系统宕机几分钟甚至更久，都会带来巨大的损失。因此任何一个大企业的软件负责人都会慎重考虑是否购买一份保险。
云服务模式
云服务模式，就是把开源软件在云端上部署好，提供一个安全、高效、可用并且跨云的方案，让用户省去运维、部署的麻烦。
这个模式的付费类型也很灵活，根据实际情况，可以选择如下几种方式：
- 订阅型：用户每月支付费用
- 消费型：用户每次调用API时都要支付费用
- 交易型：从用户通过API完成的每笔交易中抽取一定百分比的费用
云服务模式是我最推崇的模式，也是唯一一个可规模化变现的出路。
一个好的生意应该是可以规模化的。而上述两个模式都需要人的介入，比如销售/售前/交付/售后等等。但是基于人的生意是没法规模化的。
而云可以，云本质是一个资源租赁生意。
五、商业模式的优劣
上述的三种商业模式，
- 首推云服务模式，一次部署终生受用。
- 其次是服务和保险模式，企业级的用户购买该服务不会少，但是该模式需要投入的人力也少不了。
- 最次是Open Core模式。这种模式一不小心就很容易把你的开源项目整成半开源项目。
甚至如果你在社区建立的时候，没有申明，哪些是Open Core的功能，哪些是增值的功能。而是在开源软件的中后期宣布，那么很可能会造成社区成员的不满，导致成员出走，社区分崩离析。
所以开源和商业是一个很微妙的关系，希望能形成一个良性的互动，而不是对立的局面。
类似打印机和耗材的例子，打印机和耗材互相补充，互相依存，打印机可以薄利多销，盈利部分更多是一件件而量大的耗材。
六、销售模式的改变
开源的商业模式，与互联网思维很像，拉新、留存、促活、转化
- 拉新，就是在github/gitee上面是否有较多的star
- 促活，就是项目在社区的活跃程度，Issue有多少，PR有多少
- 留存，就是有多少人把开源软件下载到本地使用
- 转化，就是付费。产品实现了变现，创造了价值。
开源又有点不同，开源能让大家参与进来，共建信任。
主动咨询的客户已经通过线上对开源软件有了一定的了解，PoC(Proof of Concept，概念验证)的环节将缩短，直接的销售成本将大幅下降。
线上引流，线下成交。这就是开源带来的销售策略的转变。
除此之外，产品开源后，普通客户使用开源版即可，付费客户使用企业版。虽然大多客户是免费客户，但是这些免费客户形成了开源软件的庞大用户群，其带来的传播，提供了快速的市场反馈，而且无形中将竞争对手的市场空间大幅减少。
七、个人如何做一个开源项目
看到这里，大家大致对开源有了一定的了解。
现在聊到最后一个问题，也是最重要的问题。
个人如何做一个优秀的开源项目？
而我认为：
- 优秀的开源项目的根基一定是一个好产品，解决了某个问题
- 产品成熟稳定，风险可控
- 良好的易用性和用户体验
- 不断迭代和进化速度是这类软件的核心竞争力
- 更多的场景适应性（发现新的试用场景和持续提升性能）
- 提前就思考好的优秀的商业模式
最后的最后，人贵有自知之明。
我知道，我基本没可能实现Linux、MySQL这种伟大的开源软件。甚至连EMQ、TDengine这种优秀的开源软件也不太可能。
但是我希望我能实现类似RuoYi这种相当出色的开源软件，并且超越他。
道阻且长，我们脚踏实地，然后手摘星辰。
