开源无处不在，虚假的开源也无处不在

问题不再是一个项目是否开源，而是这个项目有多开放。

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

开源并不是黑白分明的，它包含了开放、透明、协作和信任的多个维度。

对于一些人来说，开放源码是 Github 上的任何项目，对于一些人来说，它必须通过 OSI 的定义，对于一些人来说，它必须遵守不成文但普遍接受的开放源码规范。如何看待评估开源项目呢，我们首先看看一些业务和技术方面，然后探索社区管理习惯。

知识产权

关于“开放源码”项目的第一个问题是关于知识产权的所有权。即时不了解这些法律含义，也可以通过一个简单的问题找到答案：这个项目是否属于一个你信任的著名的开源基金会？

例如，如果一个项目属于 ASF、 LF 或类似的基金会，他们通常拥有版权，是项目的商标，你可以放心，他们将作为好的管理者，不会在一夜之间改变一个项目的未来方向。如果一个项目不属于一个有信誉的软件基金会，而是由一家公司支持，那么问题就是你是否相信拥有该权利的公司是软件供应链的合作伙伴。

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

许可证

商标出现在许可之前的原因是，软件的权利持有者(通常是作者)通过许可授予最终用户使用一个或多个软件副本的权限。自由软件许可证是授予源代码或其二进制形式的接收者修改和重新发布该软件的权利的通知。如果没有许可，这些行为将被版权法所禁止。这里重要的一点是，权利持有者可以改变他们的想法，改变许可证。

权利持有者可以决定在多个许可证下分发软件，或者在任何时候将许可证更改为非开源许可证。也有可能软件是在公共领域，在这种情况下，它不受版权法的限制。公共领域并不等同于开放源码许可证，这是一种我们可以忽略的不太流行的方法。

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

治理

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

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

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

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

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

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

其中一些项目可能已经写下了它们遵循的治理规则，有些项目可能根本不写。您可以自行确定治理动态及其对项目参与的重要性。除了具有治理透明度和公开作出决定外，这里的另一个方面是理事机构的信任和声誉水平。

当你看一个项目的治理委员会时，是否有一个领导者或一组具有经验证的技术和社会技能的领导，让你相信他们可以把项目提升到下一个层次？或者你看到一个在政治斗争中不断争论的团体吗？这些都是衡量一个开放源码项目是否会成功和长期增长的指标，或者是否会令人头疼和停滞不前的指标。

基础架构

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

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

• 用户可以在项目聊天中提出问题，然后在没有中间人的情况下从其他用户那里得到答案吗?
• 开发人员可以联系项目提交者并得到深层次的技术问题的答案吗?
• 您能运行最新版本并确认所报告的错误已修复吗?
• 架构师能否每周进行一次社区电话会议，从而确定项目的未来发展方向吗?

在封闭的基础设施中，您必须创建一个支持案例，并付费获得类似问题的答案。有了开放的基础设施和开放的参与，那些知道如何以开源方式工作的人就可以得到答案。

社区和采用

开源软件的主要好处之一是它允许伟大的想法得到开发，并像病毒一样传播开来。你可能拥有最好的技术，最宽松的许可证，和开放式开发，但是如果软件没有一个不断增长的社区和不断增长的采用率，那就是一个调查的信号。不同的项目会有不同的采用率。有些人可能很快成为主流，或者被其他这样做的人所取代。一些项目可能有一个小但持续的增长率和一个持续数十年的利基社区。社区规模和采用率是开源项目的最终寿命指标。以下是您可以问的一些示例问题：

• 项目中有多少活跃开发人员（提交者），平均提交率是多少？
• 用户论坛订阅用户数，上月问了多少个问题？
• 软件最新稳定版本下载了多少次？
• 其他项目和服务依赖于和使用该项目？
• 有多少商业组织支持这个项目？
• 是否有商业组织在其周围提供产品、支持和服务？
• 关于这个项目有多少个 StackOverflow 问题？
• 有多少本书、会议讨论和工作描述提到了这个项目？

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

通常，开放源码与快节奏的开发和创新有关。与此同时，开源也是一种创建广泛采用和创建非官方标准的机制。许多开源项目已经变成了标准，比如用于容器编排的 Kubernetes，用于流媒体的 Apache Kafka，用于 web 服务器的 Apache httpd 等等。在软件行业，最昂贵的事情之一就是找到拥有合适技能的人。使用采用率高的开源项目将使您有更好的机会找到有技能的人员，并允许他们在更长的时间内重复使用自己的技能。

结论

根据开放源码项目的关键程度，有不同的风险和评估标准。对于战略性的、难以替代的、将成为 IT 基础设施基础的项目，您需要已经成熟的项目，这些项目已经在各自领域成为事实上的开放源码标准。在这里，确定谁拥有该项目的商标以及谁将成为您的长期合作伙伴非常重要。

通常，这些合作伙伴将是项目所属的软件基金会的成员组织或持有项目知识产权的单一公司。对于后者，您可能需要考虑长期风险，例如核心开发人员分担项目的可能性、将项目作为服务提供的超级扩张者、公司收购等。

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

无论哪种情况，都没有适合所有情况的单一评价标准。你必须在长期商业风险、技术稳定性、最新热点、创新和开发者满意度之间找到平衡。这里的框架将为您提供需要探索的领域的概述以及需要考虑的一些风险。