本文作者：王春生
作者自我介绍：我是春哥，禅道软件公司的创始人，二十年的IT老兵，14年的创业者。喜欢编码，喜欢做产品，所以我用了代码之歌做我的公众号的名字。我会持续地更新关于企业管理、产品管理、项目管理、团队建设、创业、学习型组织、企业文化、开源软件等方面话题的实践和思考，欢迎大家和我讨论交流。
开源软件已经像水和电一样融入到了我们日常的生活中，但我们对开源软件还有很多错误的认知。我尝试站在开源软件作者的角度来进行总结，总共有七大错误认知。
首先来看第一个错误认知：只要软件开源了，就会有人用。
很多刚开始从事开源软件开发的作者，会有这样的想法。认为我只要把软件开源出来，就会有人来使用。但事实上一个软件有没有人用，首先看它有没有价值，而不是先看它是不是开源软件。开源软件首先是一个软件，开源是其定语。所以从这个角度来讲，开源软件不会超越软件本身的属性限制，要先有用。在这个基础上，再进行开源，可以为用户带来增强的附加属性。
这给我们的提示就是在做开源软件之前，要认真思考软件的定位：
-
这款软件要解决的问题是什么；
-
它的目标用户是谁；
-
和市面上其他软件相比有什么优势；
-
如何进行宣传推广。
第二个错误认知：我又没收你钱，软件有漏洞、问题跟我没关系。
开源软件许可协议通常会包含类似这样的条款，表明作者不对用户使用该软件所造成的任何问题负责。比如GPL V3的第15条款，就是这样的声明：
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
中文版本：
本程序在适用法律范围内不提供品质担保。除非另作书面声明，版权持有人及其他程序提供者“概”不提供任何显式或隐式的品质担保，品质担保所指包括而不仅限于有经济价值和适合特定用途的保证。全部风险，如程序的质量和性能问题，皆由你承担。若程序出现缺陷，你将承担所有必要的修复和更正服务的费用。
这份协议还特意用了全大写的方式来声明。但是自2017年《中华人民共和国网络安全法》正式实施以来，这样的声明就不再有效了。
《中华人民共和国网络安全法》第二十二条规定：
网络产品、服务应当符合相关国家标准的强制性要求。网络产品、服务的提供者不得设置恶意程序；发现其网络产品、服务存在安全缺陷、漏洞等风险时，应当立即采取补救措施，按照规定及时告知用户并向有关主管部门报告。
网络产品、服务的提供者应当为其产品、服务持续提供安全维护；在规定或者当事人约定的期限内，不得终止提供安全维护。
网络产品、服务具有收集用户信息功能的，其提供者应当向用户明示并取得同意；涉及用户个人信息的，还应当遵守本法和有关法律、行政法规关于个人信息保护的规定。
第六十条规定：
违反本法第二十二条第一款、第二款和第四十八条第一款规定，有下列行为之一的，由有关主管部门责令改正，给予警告；拒不改正或者导致危害网络安全等后果的，处五万元以上五十万元以下罚款，对直接负责的主管人员处一万元以上十万元以下罚款：
（一）设置恶意程序的；
（二）对其产品、服务存在的安全缺陷、漏洞等风险未立即采取补救措施，或者未按照规定及时告知用户并向有关主管部门报告的；
（三）擅自终止为其产品、服务提供安全维护的。
所以各位开源软件的开发者们，一定要认真理解这个法律的条款。我们已经收到过五次公安部下发到青岛市网警的漏洞整改通知。具体细节就不跟大家讲述了。这给到开源软件作者们两点警示：第一个就是一定要及时处理自己产品的相关漏洞，另外一点就是认真思考开源商业化方面。
第三个错误认知：我应当选择最宽松的开源软件协议。
许可协议是开源软件的法律基础，它规定了用户可以如何使用、修改和分发软件。有些人错误地认为，选择最宽松的许可协议可以吸引更多的用户和贡献者。然而，许可协议的选择应该根据具体情况进行权衡，并考虑到软件作者的目标和需求。
比较宽松的许可协议限制比较少，如MIT和BSD许可证。这些许可协议几乎没有限制，允许用户自由地使用、修改和分发软件。然而，这也意味着其他人可以将开源软件用于商业目的，甚至将其更改后的版本作为专有软件发布，而无需向原作者贡献任何代码或修改。对于一些开源软件作者来说，这可能不符合他们的意愿和目标。
相比之下，像GNU通用公共许可证（GPL）这样的许可协议对代码的再分发和修改设置了更严格的限制。它要求任何使用或修改GPL许可的软件的派生作品必须以相同的许可证开放源代码。这样可以保护开源软件的自由性和共享精神，防止将其私有化。
因此，在选择许可协议时，开源软件作者应该考虑到他们的目标、期望用户和社区的需求，并选择合适的许可协议来平衡开放性和保护性的要求。
第四个错误的认知：我应当努力地将软件捐献给基金会。
最近这几年，有不少国产的开源项目陆续从Apache软件基金会毕业，成为Apache软件基金会旗下的项目。姜宁老师也两度当选Apache软件基金会董事。还有一些项目是加入了CNCF云原生计算基金会。包括中国也成立了开放原子基金会，大厂也都有一些项目捐赠给了开放原子基金会。这对中国的开源软件作者也是一个鼓舞，很多开源软件作者也都在思考自己的软件是否也可以加入这些基金会呢？我尝试来阐述下自己的观点：
首先这是好事情。说明了中国的开源软件生态越来越成熟，也涌现了一批高质量的开源项目，在国际上也能够产生我们的影响力，一定程度上也改变了中国只是开源软件消费大国、对开源社区回馈较少的尴尬局面。
但是不是我们要努力地将项目捐赠给基金会，以谋求项目的健康发展呢？对此我会有完全不同的观点。
第一，基金会并不是你想加入就能加入。无论是Apache软件基金会，还是CNCF云原生计算基金会，对项目的方向、成熟度、投入都有比较高的要求。所以目前能够加入这些基金会的项目大部分都是大厂背景的开发团队开发的。开放原子基金会目前的项目基本上都是会员单位捐赠的，网站上貌似也没有公开加入开放原子基金会的具体章程。所以，对于我们这些个人或者小团队的开源软件开发者来讲，这条路就不要想了，门槛太高。
第二，如果你的项目真的很不错，都达到了加入基金会的标准，我也建议你认真思考一下加入基金会的诉求是什么。对于大厂来讲，将项目捐赠给这些基金会，可以提升自己的品牌，吸引优秀的开发者加入，建立行业标准，这些都是可以通过基金会来达成的。但如果你有明确的开源商业化方面的诉求，我建议还是要慎重，因为将项目捐赠给基金会，需要将代码的所有权和商标都要捐赠给基金会。换句话讲，这个项目就属于基金会了，你只是这个项目的主要贡献者。无论从哪些方面来讲，你都阻止不了其他团队可以利用已经不属于你的项目去做商业化的操作。
这一块我要展开来说一下。整个自由软件和开源软件运动的基础，还是Copyright。正是有了Copyright，才有了Copyleft。开源软件这种游戏规则之所以能够运转起来，底层还是法律。只要是你创作的东西，你天然拥有对它的著作权（著作权不需要额外申请，都受法律保护。通过著作权登记、时间戳存证等手段可以更好地保护自己，后续再讲）。之前的软件售卖都是有源码的，后来比尔盖茨说我们只能给你二进制文件，从而开启了微软帝国时代，所以才有了黑客们对商业软件的反击。开源软件区别于商业软件，就是向软件的用户让渡了更多的权力：你可以对代码进行修改、进行二次分发。那开源软件作者为什么可以这么授权呢？因为代码的版权是我的，所以我想怎么样就怎么样。这是底层的游戏逻辑。当然开源软件还有一个基本游戏规则，就是我不对你使用软件造成的任何问题负责，因为开源软件和用户之间并没有形成商业合同上的契约关系。（但是随着《中华人民共和国网络安全法》的实施，后面的这个游戏规则不成立了，所以我们必须要对开源软件的玩法做修改，参考我的前一篇文章《关于开源软件的七大错误认知（上）》。）
所以从这个角度来讲，你将开源软件捐赠给国外的基金会，这个代码的Copyright和商标从法律上就归人家基金会了。如果我们上升到国家的角度来看这个问题，我们把我们优秀的开源软件都捐献给国外的基金会，这会不会对国家的知识产权和国家安全造成威胁呢？2021年闹得沸沸扬扬的Log4j2组件的安全漏洞，可窥一斑。阿里云的工程师在发现了这个漏洞之后，第一反应不是向中国工信部通报相关信息，而是先向美国的Apache软件基金会披露了该漏洞。工信部得知这个漏洞之后，时间已经过去了15天。15天会发生什么呢？尤其是在现在的这种国际政治背景下面。这个问题往小的方面讲，是国家安全意识不够，往大里面讲，是屁股坐得正不正的问题。
有童鞋估计会问，我们不是还有国内的基金会吗？前面也讲了，现在门槛太高，不是我们想加入就加入。另外开放原子基金会有非常强的政府背景，在运作上会有比较强的监管，在各种政策措施出台上会比较慎重（慢）。所以在国内的开源相关的基金会成熟之前，我们需要通过社区的方式来推进开源生态的发展，所以这是渠成开源社区成立的初衷（突如其来的广告）。
第五个错误认知：开源之后会有很多人来帮我完善项目。
很多开源软件作者开源，是希望有更多的人参与到项目中，这样项目的问题能够得到及时地发现和处理，项目也可以持续地发展。但实际的情况是什么样的呢？InfoQ 联合 X-lab 开放实验室发布的“GitHub 2019 数字年报”，通过对 2019年 GitHub 上 5.46 亿条日志进行分析，得出了世界范围内开源软件项目的一些汇总数据。这其中有这样的信息值得我们思考：
-
2019年总活跃项目数为512万，但活跃度超过1000的项目只有1399个，不到万分之三。
-
在这512万个项目中，只有333个项目有1000位开发者参与，而2019年 Github 上活跃的开发者数量是360万。
-
2019年活跃度排行前10的项目中，有60%来自大厂，其中有2个来自微软，分别是vscode 和azure-doc。3个来自Google，分别是 Flutter、Tensorflow、Kubernetes。还有一个是来自红帽的 Ansible。
-
2019年活跃度前列的项目中，大厂维护的项目现在仍然非常活跃，而排名第10的 tweakCompatible，已经停止维护了。
-
2019年中国Top20的项目中，主要都是大厂维护的项目。
-
Vue 项目2019年大部分的贡献是由一个账号 Evan You，也就是尤雨溪尤大贡献的。
2022年1月份，cURL 的作者发表了一篇文章，吐槽世界500强企业白嫖技术支持的乌龙事件。具体新闻可以看开源中国的网址：
https://www.oschina.net/news/180252/fortune-500-log4j-curl。类似的事情太多了，就不一一列举了。
所以，结论是，开源项目的维护主要还是要靠自己。
第六个错误认知：我开源不是为了钱。
这个话题估计会有很多开源软件的作者会不赞同。就像 Linus 做 Linux 项目，just for fun。很多开源软件作者比较纯粹，把软件开源出来就是希望能够对用户有用，并没有商业化的目的。但我把这个话题换一种表达方式，估计大家都会赞同。也许大家刚开始开源的时候，确实没有想着赚钱。但随着事情的变化，大家就会考虑，我能不能通过开源项目赚钱呢？
刚开始开源的时候，开源软件的作者更多的是兴奋，以及软件得到用户认可所带来的成就感。但随着用户的增多，来自用户的问题就会越来越多。有的是希望你帮我解决一些使用安装的问题，有的是希望你帮他做一些功能。随着这些问题的增多，你做开源这件事情的性质就会逐渐发生变化。从最开始的分享为主，逐渐变成维护为主。开源项目给到你的乐趣会逐渐减少，责任和义务就会逐渐增多。自己的投入会越来越多，心里的不平衡感就会越来越强。这时候大家就会考虑，我是不是可以通过开源项目来赚点钱呢？
所以这是水到渠成的想法，也是非常合情合理的想法。能够通过开源项目获得一定的收益，然后支持自己在开源项目做更多的投入，这是一件非常好的事情。
再来看最后一个错误认知：开源软件靠服务和捐助可以赚钱。
网上有很多的资料，在讲到开源软件的商业模式时候，都会谈到软件免费，服务收费。这个模式按道理是能够讲得通的。毕竟软件我都给你了，你要是有问题，我通过服务来收点费用，不是很合理吗？但这里面有一个悖论，我来给大家分析一下。
先来界定下这个服务的范围。我所理解的软件免费，服务收费的服务，是指保证软件正常运行使用过程中所产生的支持类的服务。二次开发类的服务和咨询培训类的服务，超脱了这个服务的范围。
如果我们尝试通过支持服务来收费，那么什么情况下用户需要支持服务呢？肯定是软件有问题用户才会需要服务，对吧。如果我们希望通过服务来赚比较多的钱，肯定是希望用户提出越多的问题越好。那如果一个软件问题比较多，那就说明软件复杂度或者质量有问题。那这样用户就比较少。用户少，那怎么通过服务来收费呢？所以这里面就存在了这样一个悖论。
什么样的软件可以通过支持服务收费呢？这个软件对企业非常关键，他们需要一个商业主体来为这个软件的正常运行负责，这样的软件通过服务收费才能行得通。什么样的软件符合这样的标准呢，基础软件。所以红帽卖自己的订阅制服务是行得通的。
我们禅道团队在开发项目管理软件之初，就放弃了通过支持服务收费的想法。我们给禅道开源免费版的用户都会提供近乎于实时的技术支持。我们的目的很简单，吸引更多的用户使用禅道。一个社区的陌生小伙伴，只有成为你软件的用户，才有可能成为你的客户。为了吸引更多的社区小伙伴成为禅道的用户，我们不遗余力的完善产品、提供各种技术支持。然后通过我们的收费的版本来实现商业化。
很多开源软件作者也都放出了自己的捐助账号，但实际的情况如何呢？我们在网上也看到过很多的新闻，很多知名的开源项目，一年收到的捐助少得可怜，可能连主要维护人员的正常生活都保证不了，这还是在欧美。比如 Core-js 项目每周下载量达数千万次，累积下载量已经超过90亿次，但作者 Denis 并没有从这个项目中获得更多的回报，甚至因为全职维护 Core-js 而穷困潦倒。他想了各种办法来筹集资金以便维护开源项目，结果每个月也只能获得几十美元的赞助。估计会有小伙伴会提 Vue 尤大的例子，但这个只能是个例，而且很多对 Vue 的捐赠是有品牌推广的性质在里面，和我们通常说的打赏类的捐赠还是不太一样。
我们最开始几年也有开放捐赠的通道，也陆续收到一些捐助，不过相比较于我们的研发投入来讲，只能说是杯水车薪。因为我们跑通了商业化这条路，我们把我们所收到的捐助又全部捐了出去。后来我们就关闭了捐赠的通道，是因为有的人因为捐赠之后，希望我们能够给他做一些额外的事情，这已经超出了捐赠这件事情本身的含义。
所以大家就不要幻想通过技术支持和捐助来实现健康的收入了。需要认真考虑开源软件的商业化之路。这是关于开源软件的七大错误认知系列的最后一篇文章。欢迎大家来讨论。
