Bitnami事件警示开源商业风险。开源项目多有资助方，需评估其商业模式、资金来源。组织应做风险评估、供应链可见性、理解许可并制定弹性策略。开源采纳是战略性商业决策，非单纯技术决策。
译自：The Reality of Open Source: More Puppies, Less Beer
作者：Michael Donovan
Bitnami 停止维护其流行开源容器库并下架相关 Helm Chart 后，许多团队开始担心开源软件的下一次“靴子落地”何时到来。Bitnami 的决定造成了重大混乱，迫使云原生计算基金会 (CNCF) 发布了一篇博客文章，指出 Bitnami 的行动并未影响 Helm 项目的开源状态。
Bitnami 的举动只是开源软件的可用性、打包和许可变更中最新的一例重大事件，这些变更影响了用户的业务连续性。Elastic、HashiCorp、Redis、Linkerd 和 Red Hat 都曾进行过变更，迫使团队重新考虑其开源组件的使用。
Bitnami 事件再次提醒我们，开源软件更像是一只免费的小狗，而非免费的啤酒。它的拥有成本高昂，不容忽视。
每个组织、平台和安全团队不仅需要确保其扫描器正常运行且应用程序安全流程坚如磐石。他们还需要审视自己正在运行的每一个开源容器，包括谁在维护它，以及他们对该组织持续维护的信任程度。这对于所有开源软件包来说也同样适用。这完全是商业问题。
所有这些并非是说做出这些变更的公司没有商业理由。但在每个案例中，用户都不得不做出反应和调整。无论我们喜不喜欢，每个开源组件都必须从业务连续性的角度来看待。
开源生态系统中的“善意”神话
在开源世界中，长期存在着一个神话，即数千个项目纯粹通过热情的开发人员在业余时间的“善意”贡献来维护。在极少数情况下，这个神话是真的。
确实有一些开源开发人员在维护关键项目。他们主要维护的是较小的软件包或库，而不是完整的产品。对于生成重要开源制品（如官方容器镜像或软件包）的组织来说，也存在类似的幻象。Bitnami 的遭遇就是明证。
现实核查。几乎每一个重要的开源项目或制品的背后，都有一个公司或基金会。有人正在为开发提供资金。有人正在进行投资。而这个人期望获得回报。
在极少数不期望回报的情况下，个人开发人员或小团队正在构建一些有趣的东西，但却走在一条脆弱的道路上。他们可能会精疲力尽或选择移交项目。或者，作为一名独立开发者，他们可能没有足够的精力来实施一个更强大的组织可能具备的安全措施。
归根结底，尽管我们不愿承认，开源关乎经济，无论是对企业还是个人。如果维护和持续运营不再有意义，那么所有人都会感到痛苦。
超越常规指标的必要性
当工程师评估开源技术时，他们通常侧重于技术本身。他们会关注 GitHub 星标、分支、拉取请求、社区力量、代码质量和功能集等社交信号。
希望他们还会关注项目有多少维护者、这些维护者是谁、他们在哪里工作、软件是否属于某个基金会以及许可条款是什么。这些因素很重要，但不足以做出关于依赖何种技术的明智商业决策。
缺少了什么？对项目背后的公司、组织或个人进行评估。具体来说，关键要问：谁在资助开发？是单一公司、财团、拥有多元支持的基金会，还是仅仅是志愿者？如果是一家公司，这家公司资金充足且稳定吗？它的商业模式是什么？
如果你所依赖的开源项目不直接有助于赞助公司的收入模式，那就是一个危险信号。当经济状况收紧或战略发生转变时，不产生收入的项目最先被削减或积极地货币化。治理模式是什么？是一家公司控制所有关键环节吗？是否存在多个有意义输入贡献的组织？如果主要赞助商退出，项目能否轻易被分叉并继续维护？
例如，Bitnami 的变更不应让任何关注商业基本面的人感到惊讶。当 Broadcom 收购 VMware 随后改变 Bitnami 的分发方式时，预兆就已经显现。看看 Broadcom 是如何赚钱的。看看它在收购方面的历史。限制“免费”内容的举动完全是可预测的。
Bitnami 的警钟：层层依赖
Bitnami 容器和 Helm Chart 只是风险的最上层。每个开源项目都依赖于数十或数百个其他开源项目。每个项目都有自己的商业模式、资金来源和风险状况。风险在每一层都会累积。
考虑大多数团队甚至没有想到的依赖关系。你的应用程序使用一个流行的 Web 框架。该框架依赖于特定的 SSL 库。该库几乎完全由一家大型科技公司的工程师维护。如果该公司改变优先级会发生什么？如果出现一个关键漏洞而没有人维护它会发生什么？
这种级联依赖风险意味着你不能只评估你直接使用的顶级开源组件。你需要了解它们之下是什么，以及那之下又是什么。它就像“乌龟叠罗汉”一样层层相依，而大多数组织对这些“乌龟”中的大部分都没有可见性。
如何做出更好的决策
不深入考虑业务连续性而采纳开源的时代已经结束。以下是组织在处理开源方式上需要改变的地方。
- 风险评估必须包含商业模式分析。 在采用任何重要的开源组件之前，团队需要回答这些问题。这背后是否有可持续的商业模式？这个商业模式如何盈利？如果这个商业模式失败或改变方向会发生什么？
- 供应链可见性至关重要。 组织需要工具和流程来理解其完整的依赖树，而不仅仅是直接依赖。他们需要知道每个组件由谁维护，并评估每个层级的风险。
- 必须彻底理解许可协议。 法律和工程团队需要合作，以理解许可协议允许和限制的内容。这不仅仅是关于合规性。它关乎确保在主要维护者消失或改变条款时，你仍有运营的自由。
- 制定弹性策略。 对于真正关键的组件，组织需要考虑在必要时自行分叉和维护代码的能力。这可能意味着贡献你所依赖的项目、与其他使用相同技术的用户保持关系，或者在内部保留专业知识。
- 分散依赖。 在可能的情况下，避免技术堆栈中的单点故障。如果你完全依赖一家公司在多个组件上的开源产品，那么如果该公司的策略发生变化，你将面临风险。寻找替代方案并准备好使用它们。
- 适时依赖强化镜像。 强化镜像提供商会尽可能多地移除依赖项，生成一个安全、最小化的容器镜像，它更具弹性，且更少依赖从存储库拉取经批准的容器镜像。此外，在开源项目或产品公司动荡期间，最小化镜像不太容易受到常见漏洞和暴露 (CVE) 的影响。
开源弹性在实践中的意义
需要明确的是，这并不意味着要放弃开源或被风险所束缚。开源仍然是技术领域最强大的力量之一，它以前所未有的规模赋能创新和协作。但我们需要清醒地认识到开源带来的全部商业风险，以及缓解这些风险所需的成本或必要步骤。如果没有规划和远见，这些成本可能会突然降临，任何急于重建或寻找 Bitnami 容器替代来源的人都可以证明这一点。
Bitnami 的举动仅仅强调了开源采纳也必须是一个战略性的商业决策，而不仅仅是技术决策。我们不仅要评估代码，还要评估公司。不仅要评估现状，还要评估可能的未来发展轨迹。这需要更多的工作。它需要不同的技能和不同的流程。但这才是充满信心地在开源基础上进行构建的唯一途径，确保你所依赖的基础明天依然存在。
