第 5 小节：有关开源的常见误区

第 5 小节：有关开源的常见误区

前言

本篇内容将会为开发者们解释有关开源的常见误区，欢迎开发者们补充更多内容！

常见误区

开源 = 免费

开源并不等于完全免费和随意使用。

在使用开源软件时，您需要严格遵守项目的开源许可证（又称开源许可协议）。开源许可证是对开源软件著作人版权的保护，在开放源代码的同时，也确保了开源软件的权利是受到保护的。例如：GPL、MIT、BSD 等比较流行的开源许可证允许使用者修改源代码，但是不允许修改版权信息。

而部分开源许可证则对于商业应用需要购买并支付费用。还有部分开源许可证表明不能将软件用作任何政治相关的用途，特别是政治宣传。

所以开源并不意味着完全免费和随意使用源代码！

OSI 组织与 OSI 网络体系结构

OSI 组织一般指的是开放源代码促进会（Open Source Initiative），于1998年2月创建，是一个旨在推动开源软件发展的非盈利组织。

OSI 网络体系结构（Open Systems Interconnection）是由国际标准化组织（ISO）提出和定义的计算机网络的分层、各层协议和层间接口的集合。这个模型把网络通信的工作分为7层，分别是物理层、数据链路层、网络层、传输层、会话层，表示层和应用层。也就是我们平时常说的 OSI 7 层网络模型。

在各个行业领域，缩写重复是很常见的事情，如果不加以区分，很容易造成理解上的误会。因此，请注意：OSI 组织与 OSI 网络体系结构，两者的关系就像是 Java 和 JavaScript 、蔺相如与司马相如一样，并没有太大关系。

只有“大牛”才能参与开源

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

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

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

“罗马不是一天建成的”。没有人天生就是“大牛”，“大牛”们也是在参与中不断成长的，不要被虚无的 title 所困扰，只有不断的坚持和探索才能让自己不断成长！

开源是好的，闭源是不好的

开源与闭源各有优劣，一般是根据个人需求来选择采用哪种方式。

开源项目因为开放源代码，参与人数较多，在快速促进项目成长，对行业的良性发展起到了重要的作用。与此同时，也正是因为参与人较多，这就导致开源社区的维护需要投入更多的精力，如果维护者精力不足，很容易导致项目停止维护，这也是开源项目不稳定的原因。

而闭源项目参与人数较少，在项目迭代和项目质量的管理较为明确，如果是商用软件，还会为客户提供长期的运维服务，更加标准和稳定。也正是因为参与人数较少，闭源软件的迭代周期会比较慢，在项目成长曲线上略显不足，这也是闭源软件有时会被开源软件弯道超车的原因。

开源项目不能商用

开源项目能不能商用，这取决于开源项目使用的哪种开源许可证。比如：Apache License 2.0、BSD 等开源许可证就允许使用者可以进行商业使用。

开源项目的作者没有版权

项目的开源并不意味作者没有版权/著作权。

开源项目不能转为闭源

认识开源首先的一点是要认识各种开源许可证，不同开源许可证对待开源转闭源有不同的规定：

LGPL、GPL、MPL 这类许可证禁止开源软件转为闭源软件。
BSD、MIT、Apache 这类许可证允许开源软件转为闭源软件。

参考：如何选择开源许可证？

“半开源”和“伪开源”不是开源

这个问题其实是有争议的，一部分人认为不属于开源，而另一部分人认为属于开源。在这里，我们认为开源可以分为两种开源：广义的开源、狭义的开源。下面，我们从项目规范性和完整性两个方面来探讨这两者区别。

从项目规范性来看，只要开放源代码就可以认为是广义的开源，而狭义的开源在广义的开源基础上，增加了一定限制——需要符合国际社区公认的规范和定义。

广义的开源，使用非国际社区公认的开源许可证，或者没有采用任何开源许可证，只要开放源代码就属于开源项目。
狭义的开源，除了开放源代码以外，还需要符合一些国际社区公认的定义（比如：采用 OSI 批准的开源许可证），满足开源的一些条件才是真正意义的开源。我们平时说开源社区，一般指的是狭义的开源。

从项目完整性来看，狭义的开源一般对项目完整性有严格的要求。而广义的开源，对项目的完整性要求较为宽松。

狭义的开源，对项目完整性有严格的要求，比如：公开代码完整、可以编译和再发行、符合国际开源规范、拥有开源许可证、维护和治理开源社区，以及接受贡献（允许外部贡献）等。
广义的开源，不严格要求狭义的开源中提及的一系列约束，完整性要求较为宽松，可以忽略上述提到的各类要求，按照自己的想法来维护项目。

此外，需要明确的一点是：OSI 批准的许可证并不是划分是不是开源项目的唯一标准。 OSI 只是国际开源许可证的一个组织机构，由于被其认可的开源许可证较为清晰严谨，所以一般国际认可的许可证都需要经过 OSI 批准。但并不是说只有 OSI 才能制定和批准开源许可证，一个本地的开源项目也可以使用或者定义自己的开源许可证。比如：我国第一个被 OSI 批准的木兰许可证，在被批准前也只是木兰本地的开源协议。虽然木兰许可证在此之前并没有被 OSI 批准，但是基于其规范性和完整性而言，都具备狭义上开源的标准。因此，采用木兰许可证的项目不管是在被批准前还是批准后，都属于狭义上的开源。

最后总结一下，“半开源”和“伪开源”都违反了狭义上开源的其中某些条款，因此，不算标准的开源形式。但因为贡献出源码，所以也可以认为属于广义的开源。广义的开源和狭义的开源只是概念上的区分，而广义的开源项目如果符合狭义的开源标准，也可以转变为狭义的开源。在秉承“吃水不忘挖井人”的优良传统下，哪怕“井”挖的不够好不够深，也要吃水怀恩，因此，“半开源”和“伪开源”可以被认为广义的开源。

开源项目只需要开放源代码就可以了

一个开源项目不仅仅要开放源代码，还要有一套完整的项目管理流程以支撑开源项目的健康推进。

一个优秀的开源项目，开放源代码只是第一步，更重要的是维护一个开源社区。开源社区包含了一套完整的项目管理流程，它包括开放源代码、社区协作流程、项目质量管理为一体的系统管理，绝对不逊色于公司企业的项目管理流程。同时开源发起人还需要考虑社区传承等重大问题，大量的开源项目就是因为无法传承而被取代或者失败。或者由于项目管理本身的问题，导致问题频出被社区放弃。因此，开源项目并非开放和维护源代码这么简单。

开源是安全的 or 开源是不安全的

身处全球信息化的今日，在经历了熊猫烧香、信息泄露等一系列网络安全问题之后，希望大家对“安全”保持一份谨慎的认知：“这天底下没有不透风的墙”，也就是说，安全是相对的，没有绝对意义上的安全。

我们来看一下走出误区正确认识开源一文中的描述：

首先，我们来看一下封闭式平台或专有平台是怎么运作安全补丁的：安全漏洞必须由有权访问源代码的人员识别（通常只是供应商），这首先就要耗费大量时间。随后，他们必须对修复补丁进行编码、测试并交付使用，这就再次延迟了修复时间。

相反，再看看基于标准且开放的开发模式：它有助于快速识别潜在的安全漏洞。举个栗子，在 2014 年，常用的 OpenSSL 加密软件库发现了 Heartbleed。已经订阅红帽软件的客户都在第一时间收到了红帽安全响应团队的即时回应。随即，该部门进行了后续漏洞测试、打补丁和安全修复等工作，以确保客户始终处在安全的网络环境中。

红帽公司总裁兼 CEO Jim Whitehurst 在一次采访中表示：“在 Heartbleed 发生时，每个人都收到通知，同时红帽在第一时间做出了响应。在红帽，我们有专门的安全响应团队，来迅速、专注处理这类问题。”

我们有理由认为：一个软件是否安全，并不在于软件的一个瞬时状态，而是看其是否能够提供及时的维护和修复漏洞。闭源软件和商业软件也存在安全问题，相对安全的闭源模式和专业的维护质量可以帮助它们降低安全隐患。开源软件会被认为不安全，主要是因为开放源代码会更容易暴露漏洞，并且开源软件的健康完全取决于开源社区的网络安全水平。因此，在对待开源的安全性问题上，正确的态度是：正视其开源所带来的问题，共同维护开源社区的安全性。

开源没有技术支持

一般较小的开源项目（如个人项目）只能依赖于维护者的技术支持，支持力度较小。因此，经常会被大家误认为开源项目是没有技术支持的，但其实不然。开源项目的技术支持和开源社区的发展息息相关，一个发展良好的开源社区，能够为开源项目带来比较多的贡献者，通过共同建设，也会带来比较完善的技术支持。

此外，企业也会支持开源项目，为开源项目保驾护航。比如 RedHat 的开源版本 Centos。目前国内的大型企业也密切关注开源发展，维护自己的开源项目，指定专门的开源项目负责人。

开源项目需要技术支持且至关重要！技术支持的程度，在项目的技术选型方面也是一个重要的指标。

开源项目的质量不够好

回顾开源历史，能够流传至今的开源项目中，无一不是业内最顶级的技术专家参与研发的，目前国内比较知名的开源软件也是顶级的技术专家负责。之所以大家会对开源项目质量有疑问，主要是因为开源的蓬勃发展，开源者越来越多，但由于水平的参差不齐，以及不完善的项目维护机制，很多开源项目都因“一时兴起而生，一时兴起而亡”。因此，开源项目质量不够好，更像是一个“以管窥豹”的看法。我们需要做的，是对优秀开源项目的贡献，以及对糟糕开源项目的辨识。

开源项目必须用英文命名标识符吗？

虽然很多开发者早已知道多数常用编程语言支持中文命名标识符并付诸实践，但仍然常见“如果项目开源的话还是要用英文命名”的说法。2007 年 Python3 决定支持非 ASCII 码标识符的增强建议书中指出：

A developer wishing to make a library widely available needs to make a number of explicit choices (such as publication, licensing, language of documentation, and language of identifiers). It should always be the choice of the author to make these decisions - not the choice of the language designers.

希望使库广泛可用的开发人员需要做出许多抉择（例如发布、许可、用何种语言编写文档和命名标识符）。决定权都应在项目作者而不是语言设计者手中。

这段话同样适用于开源项目。无论是文档还是源码中标识符使用的语言，项目作者都可以根据实际需求来灵活决定，而非简单的一刀切用英文。实际上，开源项目往往是在开发者业余的碎片时间进行，文档和测试往往从简。这种情况下，代码的清晰度和可维护性对于项目可持续性尤显重要，这恰恰是母语命名标识符的优势。正如同一文档指出：

By using identifiers in their native language, code clarity and maintainability of the code among speakers of that language improves.

通过使用母语命名的标识符，代码的清晰度和可维护性对于该母语使用群体得到了提高。

下面是一些常见的疑虑：

用中文命名出了问题怎么办？

像任何技术一样，在使用推广中必然有各种问题出现。如果是编程语言或是开源框架对中文命名的支持问题，可以向它们的开发组反映，往往能得到解决，先例有 Vue.js、Hibernate、pip 等等。另外，也可在开源中国社区求助，协力解决。毕竟，鲁迅先生说过：“走的人多了，也便成了路”。
框架限制必须用英文怎么办？

比如 JavaBeans 规范通常要求使用 set/get 前缀。即便如此，仍然可以使用中英混合的命名，只要开发者感觉更易读即可，比如 getCostOutcomeRatioByClientGroup 相比 get投入产出比By客户组。类似地，一些常用的英文术语或简写，如果没想到合适中文对应术语，大可以暂时保留这部分英文命名。
中英文混输的效率会低吗？

大多数情况下，读代码的时间远超过写代码的时间。即便仅仅讨论写代码的效率，也要考虑推敲英文命名甚至查字典的时间，何况很多领域业务相关命名连恰当英文表达都很难找到。另外，随着中文命名实践的普及，相应的 IDE 辅助功能也在不断涌现，比如 JetBrains 和 VS Code 的中文代码补全插件。
用拼音效果一样吗？

从代码可读性看，使用拼音不如中文。比如 shipin，就有食品/视频/饰品等等理解。即便可以根据代码上下文进行猜测，无疑也是额外的负担。拼音缩写的可读性更差，像 xmjl，到底是姓名记录、项目奖励、项目监理还是项目经理呢？如果需要额外中文注释才能避免误解，还不如将直接将中文注释的内容用于命名。输入效率来说，输入全部拼音的速度也往往不如输入中文，因为大多数中文词语不需输入全部拼音即可选词。更不用说用拼音命名更容易出现细节错误如翘平舌、前后鼻音等等。
项目已经是英文命名的，没法转了？

如果某一部分的英文命名经常在开发组中引起误解或者新手甚至自己也难以看懂，可以尝试从这部分先开始中文化，看看效果后再逐步在其他部分采用。与任何未曾尝试过的技术一样，渐进增量式的应用可以减小风险、在使用中逐渐适应。
用了中文命名之后，怎样为国外用户服务？

如果需要面向国外用户，首先要对用户界面和使用文档进行国际化。如果是库，用户界面就是 API。技术上，可以开发中英两套 API。如果想更进一步，鼓励国外开发者参与开发项目，当然可以逐步将命名英文化，但也应综合考虑是否值得。

总之，澄清这个误区的目的，绝不是排斥英文命名，而是让更多开源作者意识到可以视项目性质和自身情况因地制宜、具体情况具体分析，灵活选择何时、何处进行中文命名实践，也希望中文开源社区能以开放宽容的心态看待中文命名标识符这一并不新的“新技术”。

参考资料

本部分内容贡献者

YFun、吴烜、菜菜STWhite、雪山凌狐、和耳朵、jack960330、哦是吗、taotieren、Sooxin、西狩