关于开放源代码:开源无处不在虚假的开源也无处不在

问题不再是一个我的项目是否开源，而是这个我的项目有多凋谢。

开源无处不在，虚伪的开源也是如此。最近，越来越多的开源我的项目转变为非开源我的项目的案例，同时也有一些非开源我的项目 (依照 OSI 定义) 将社区建设为开源我的项目的例子。

开源并不是黑白分明的，它蕴含了凋谢、通明、合作和信赖的多个维度。

对于一些人来说，开放源码是 Github 上的任何我的项目，对于一些人来说，它必须通过 OSI 的定义，对于一些人来说，它必须恪守不成文但广泛承受的开放源码标准。如何对待评估开源我的项目呢，咱们首先看看一些业务和技术方面，而后摸索社区治理习惯。

知识产权

对于“开放源码”我的项目的第一个问题是对于知识产权的所有权。即时不理解这些法律含意，也能够通过一个简略的问题找到答案：这个我的项目是否属于一个你信赖的驰名的开源基金会？

例如，如果一个我的项目属于 ASF、LF 或相似的基金会，他们通常领有版权，是我的项目的商标，你能够释怀，他们将作为好的管理者，不会在一夜之间扭转一个我的项目的将来方向。如果一个我的项目不属于一个有信用的软件基金会，而是由一家公司反对，那么问题就是你是否置信领有该权力的公司是软件供应链的合作伙伴。

如果这些问题的答案是必定的，那么就进入下一部分。如果答案是否定的，那么你最好考察并找出谁是这个我的项目的所有者，他们对我的项目的长期用意是什么，以及对你的潜在危险。

许可证

商标呈现在许可之前的起因是，软件的权力持有者 (通常是作者) 通过许可授予最终用户应用一个或多个软件正本的权限。自由软件许可证是授予源代码或其二进制模式的接收者批改和从新公布该软件的权力的告诉。如果没有许可，这些行为将被版权法所禁止。这里重要的一点是，权力持有者能够扭转他们的想法，扭转许可证。

权力持有者能够决定在多个许可证下散发软件，或者在任何时候将许可证更改为非开源许可证。也有可能软件是在公共畛域，在这种状况下，它不受版权法的限度。公共畛域并不等同于开放源码许可证，这是一种咱们能够疏忽的不太风行的办法。

这里有一个在行的试金石测试许可证：我的项目是依据 OSI 批准的许可证列表许可的吗？如果答案是必定的，那么您能够依附这些基金会的渎职考察来审查、分类许可证并指出任何限度。如果答案是否定的，请您的公司律师审阅并解释许可证上的每个单词以及可能的许可证兼容性含意。

治理

通过剩下的查看，咱们正从更多的业务和法律方面，转向与开源我的项目相干的技术和社区畛域。

假如对商标持有者方（您将来的合作伙伴）、许可证（您应用开源软件的条款）没有任何顾虑，下一个问题是治理。治理是一种规定或习惯，我的项目依据这些规定或习惯决定谁能够做什么、应该如何做以及何时做。

它定义了与不同我的项目角色相关联的职责、特权和权限，以及人员如何被调配和从角色中移除。这里的例子是一些小型的日常流动，比方谁有权批准一个拉申请、投票给一个公布候选人、约定我的项目架构、定义我的项目路线图以及选举我的项目治理委员会。

如果您正在评估一个对您的组织具备战略意义的我的项目，那么您心愿晓得谁是负责人。不仅如此，你甚至有雄心壮志让你的开发人员对我的项目的方向有发言权。

这里还有一个简略的测验规范: 对于开源基金会的我的项目，有明确的规定规定谁能够对重要决策进行投票，以及如何成为决策委员会的一员。在一些基金会，如 ASF，它是基于集体社区成员的价值，在一些基金会，如 CNCF，它开始是一个付费成员组织的雇员。在基于块区块链的开源我的项目中，它是基于令牌持有者的投票。

其余基金会有不同的规定，但它们都争取在多个参与者之间保持中立和权力下放。如果一个我的项目由一个公司或单个集体治理，那么您将信赖他们为我的项目和社区的利益做出最佳决策。

其中一些我的项目可能曾经写下了它们遵循的治理规定，有些我的项目可能基本不写。您能够自行确定治理动静及其对我的项目参加的重要性。除了具备治理透明度和公开作出决定外，这里的另一个方面是理事机构的信赖和名誉程度。

当你看一个我的项目的治理委员会时，是否有一个领导者或一组具备教训证的技术和社会技能的领导，让你置信他们能够把我的项目晋升到下一个档次？或者你看到一个在政治奋斗中一直争执的个人吗？这些都是掂量一个开放源码我的项目是否会胜利和长期增长的指标，或者是否会令人头疼和停滞不前的指标。

基础架构

领有开源许可证能够从技术上将一个我的项目定义为开源我的项目，但这并不意味着一个我的项目是以开源形式构建的。有许多例子表明，软件是在 OSI 许可下公布的，但却是在关闭的基础架构下开发的。说到基础架构，这里指的是供用户疾速发问的聊天频道。在论坛和邮件列表中进行更深刻的开发人员探讨。源代码管理系统，在其中审查拉申请，并构建运行测试和每晚创立二进制文件的服务器。

对于关注开源我的项目的商业人士和律师来说，这些可能并不重要，但对于将要应用开源我的项目的技术人员来说，这些是一些假设的益处。这里要做的查看是摸索软件是否是应用凋谢基础设施而不是闭门造车的开源形式开发的。以下是几个问题示例：

• 用户能够在我的项目聊天中提出问题，而后在没有中间人的状况下从其余用户那里失去答案吗?
• 开发人员能够分割我的项目提交者并失去深层次的技术问题的答案吗?
• 您能运行最新版本并确认所报告的谬误已修复吗?
• 架构师是否每周进行一次社区电话会议，从而确定我的项目的将来倒退方向吗?

在关闭的基础设施中，您必须创立一个反对案例，并付费取得相似问题的答案。有了凋谢的基础设施和凋谢的参加，那些晓得如何以开源形式工作的人就能够失去答案。

社区和采纳

开源软件的次要益处之一是它容许平凡的想法失去开发，并像病毒一样流传开来。你可能领有最好的技术，最宽松的许可证，和开放式开发，然而如果软件没有一个一直增长的社区和一直增长的采用率，那就是一个考察的信号。不同的我的项目会有不同的采用率。有些人可能很快成为支流，或者被其余这样做的人所取代。一些我的项目可能有一个小但继续的增长率和一个继续数十年的利基社区。社区规模和采用率是开源我的项目的最终寿命指标。以下是您能够问的一些示例问题：

• 我的项目中有多少沉闷开发人员（提交者），均匀提交率是多少？
• 用户论坛订阅用户数，上月问了多少个问题？
• 软件最新稳固版本下载了多少次？
• 其余我的项目和服务依赖于和应用该我的项目？
• 有多少商业组织反对这个我的项目？
• 是否有商业组织在其四周提供产品、反对和服务？
• 对于这个我的项目有多少个 StackOverflow 问题？
• 有多少本书、会议探讨和工作形容提到了这个我的项目？

运行这些问题将告诉您我的项目是否正在增长，并成为其畛域中的事实标准或停滞，并且很可能被下一个重大的事件所取代。

通常，开放源码与快节奏的开发和翻新无关。与此同时，开源也是一种创立宽泛采纳和创立非官方规范的机制。许多开源我的项目曾经变成了规范，比方用于容器编排的 Kubernetes，用于流媒体的 Apache Kafka，用于 web 服务器的 Apache httpd 等等。在软件行业，最低廉的事件之一就是找到领有适合技能的人。应用采用率高的开源我的项目将使您有更好的机会找到有技能的人员，并容许他们在更长的工夫内重复使用本人的技能。

论断

依据开放源码我的项目的要害水平，有不同的危险和评估规范。对于战略性的、难以代替的、将成为 IT 基础设施根底的我的项目，您须要曾经成熟的我的项目，这些我的项目曾经在各自畛域成为事实上的开放源码规范。在这里，确定谁领有该项目标商标以及谁将成为您的长期合作伙伴十分重要。

通常，这些合作伙伴将是我的项目所属的软件基金会的成员组织或持有我的项目知识产权的繁多公司。对于后者，您可能须要思考长期危险，例如外围开发人员分担我的项目的可能性、将我的项目作为服务提供的超级扩张者、公司收买等。

对于交付速度最为重要的非战略性、战术性、短期我的项目，您能够让开发人员驱动抉择，并基于开放性、社区合作和热门性 (对于某些前端技术来说很重要) 抉择我的项目。在这里，短期到中期的危险，例如定期的平安修复、开发人员反对和许可证兼容性查看可能就足够了。

无论哪种状况，都没有适宜所有状况的繁多评估规范。你必须在长期商业危险、技术稳定性、最新热点、翻新和开发者满意度之间找到均衡。这里的框架将为您提供须要摸索的畛域的概述以及须要思考的一些危险。