我敢打赌，最擅长管理和影响开源供应链的人，将最能创造出最具创新性的产品。在本文中，我将解释为何你应该成为供应链的影响者，以及你的组织如何才能积极参与到你的供应链中。
在我之前的文章《开源与软件供应链》中，我讨论了供应链管理的基础知识，以及开源如何融入这个模型。我给读者留下了这个模型的图示
需要向你的雇主和团队提出的问题是：我们如何才能最好地利用这一点？ 毕竟，如果苹果公司可以通过创建更好的硬件供应链来为其统治地位奠定基础，那么肯定有人可以对软件供应链做同样的事情。
评估供应链
在与许多公司的开发人员和产品团队合作后，我了解到，选择产品组件的过程是随意而为的。有时会对一两个组件进行正式的“比拼”，但开发人员通常会根据“感觉”来选择使用某个产品。在确定最佳组件时，你必须根据这些项目的持久性、开发阶段以及足够的其他指标进行评估，以形成“自建还是购买”决策的基础。用户数量、相关方、商业活动、开发团队对支持的参与程度等等，都是决策过程中的一些考虑因素。
随着时间的推移，技术和业务需求会发生变化，在开源软件领域更是如此。工程和产品团队不仅必须能够选择当时最好的组件，而且还必须能够在时机成熟时将其替换为其他组件——例如，当管理旧组件的社区转移时，或者当出现具有更好功能的新组件时。
不该做什么
在评估供应链组件时，团队容易犯一些错误，包括以下常见的错误
- “非我发明”（NIH）综合征：我无法告诉你，有多少次工程团队决定通过自己编写代码来“修复”现有供应链组件中的缺点。我不会说“永远不要这样做”，但我会警告你，如果你承担起编写基础设施组件的责任，请明白你正在抛弃开源供应链的所有优势——即上游测试和上游工程——并决定承担这些任务，立即让你的团队（和你的产品）背负技术债务，而这些债务只会随着时间的推移而增长。你正在做出效率较低的选择，你最好有令人信服的理由这样做。
- 向前携带补丁：任何精通开源的团队都了解向其各自的上游项目贡献补丁的价值。这样做时，贡献的代码会经过该项目的自动化测试程序，这与你团队现有的测试基础设施相结合，可以使最终产品更加可靠。不幸的是，并非所有团队都精通开源。有时，这些团队面临繁重的法律要求，阻止他们寻求许可向上游贡献修复程序。在这种情况下，鼓励（即，唠叨）你的经理获得此类事情的全面法律批准，因为替代方案是将所有这些更改向前携带，产生巨大的技术债务，并应用补丁，直到你的项目（或你）消亡的那一天。
- 认为自己只是用户：使用开源组件作为软件供应链的一部分只是第一步。要获得开源供应链的回报，你必须深入其中并成为影响者。（稍后详细介绍。）
有效的供应链管理示例：红帽
由于其“上游优先”政策，红帽 是如何利用和影响软件供应链的一个例子。要理解红帽模式，你必须从供应链的角度来看待他们的产品。
红帽支持的产品由开源组件组成，这些组件通常由多个上游社区审查，并且对这些组件所做的更改会被推送到各自的上游项目，通常在它们进入红帽支持的产品之前。工作流程大致如下
这种工作流程有多种原因
- 测试，测试，再测试：通过卸载一些初始测试，像红帽这样的公司可以从上游社区的测试以及包括竞争对手在内的其他生态系统参与者进行的测试中获益。
- 上游可行性：红帽模式只有在上游供应商可行且能够自给自足的情况下才能奏效。因此，确保这些社区保持健康符合红帽的利益。
- 工程效率：由于红帽将常见任务卸载到上游社区，因此他们的工程师可以花费更多时间为客户的产品增加价值。
为了理解红帽的供应链方法，让我们看看他们使用 OpenStack 进行产品开发的方法。
奇怪的是，红帽最初使用 OpenStack 并不是为了创建产品甚至宣布产品；相反，他们开始将工程资源投入到 OpenStack 的战略项目中（从 Nova、Keystone 和 Cinder 开始）。这个列表不断增长，包括 OpenStack 社区中的其他几个项目。更传统的产品管理主管可能会审视这种方法并思考：“我们为什么要把这么多工程投入到尚未建立且没有产品的东西上？我们为什么要免费给竞争对手提供我们的工作？”
相反，这是开源供应链的思考过程
步骤 1
关注业务中的增长领域或需要填补的最大产品缺口。是否有符合战略缺口的开源社区？或者我们可以从头开始构建一个新项目来做同样的事情吗？在本例中，红帽考察了 OpenStack 社区，最终确定它将填补产品组合中的一个缺口。
步骤 2
逐步加大工程资源的投入。这有几个作用。首先，它有助于工程团队了解各个项目成功的可能性。如果前景不好，公司可以停止贡献，只需花费最少的投资。一旦确定该项目值得投资，公司就可以确保其工程师将影响当前和未来的开发。这有助于项目进行高质量的代码开发，并确保代码满足未来的产品要求和验收标准。红帽在宣布 OpenStack 产品之前，甚至在发布之前，就花了很多时间在 OpenStack 存储库中编写代码。但这只是公司从头开始开发 IaaS 产品所需投资的一小部分。
步骤 3
一旦工程投资开始，就开始制定产品管理路线图和营销发布计划。一旦代码达到最低质量水平，就 fork 上游存储库并开始处理特定于产品的代码。错误修复被推送到 openstack.org 和产品分支。（请记住：红帽的模式依赖于上游可行性，因此不向上游推送修复程序是没有意义的。）
反复进行。这就是你管理开源软件供应链的方式。
不要积累技术债务
如果需要，红帽可以决定它将只依赖上游代码，提供必要的专有产品粘合剂，然后将其作为产品发布。事实上，大多数公司对上游开源代码都是这样做的；然而，这忽略了我之前提出的一个关键点。要开发一款真正出色的产品，深入参与开发过程会有所帮助。如果组织不参与日常架构讨论，如何确保代码库满足其核心产品标准？
更糟糕的是，为了保护向后兼容性和互操作性，许多公司 fork 上游代码，进行更改但不将其贡献给上游，而是选择在内部向前携带它们。这是一个大忌，会让你的工程团队永远背负不断积累的技术债务。在这种情况下，从上游测试、开发和发布中获得的所有收益都会在愚蠢的气息中消失殆尽。
红帽和 OpenShift
一旦你开始理解红帽的供应链方法（你可以从其 OpenStack 方法中看到体现），你就可以理解其 OpenShift 方法。红帽最初将 OpenShift 发布为专有产品，该产品也是开源的。一切都是本土开发的，由一个团队构建，该团队在 2010 年加入红帽，成为 Makara 收购 的一部分。
该技术最初受到 NIH 综合征的困扰——尽管当时发布了新项目：Kubernetes、Mesos 和 Docker，但仍使用其自己开发的集群和容器管理技术。红帽接下来所做的事情证明了该公司对其开源供应链模型的承诺：在 OpenShift 版本 2 和 3 之间，开发人员重写了它，以利用和利用 Kubernetes 和 Docker 社区的新发展，放弃了他们的 NIH 方法。通过以这种方式重组项目，该公司利用了这两个项目蓬勃发展的开发者社区所带来的规模经济。
红帽没有为整个 OpenShift 堆栈构建完整的 QC/QA 测试环境，而是可以依赖 Docker 和 Kubernetes 社区提供的测试基础设施。因此，红帽对 Docker 和 Kubernetes 代码库的贡献在到达公司自己的产品分支之前，将经历几轮测试
- 第一轮测试由 Docker 和 Kubernetes 社区进行。
- 进一步的测试由生态系统参与者完成，他们在其中一个或两个项目上构建产品。
- 更多的测试发生在下游代码发行版或“嵌入”这两个项目的产品上。
- 最终测试发生在红帽自己的产品分支中。
对代码进行的上游（来自红帽）测试量确保了质量水平，如果公司要全面地从头开始做，成本会高得多。这就是开源供应链管理的诀窍：不要只是消费上游代码，将其最小程度地填充到产品中。这种方法不会给你带来开源开发实践和直接参与解决客户问题所提供的任何优势。
为了从开源软件供应链中获得最大收益，你必须成为开源软件供应链本身。
1 条评论