开源供应链金融_成为开源供应链

开源供应链金融

我敢打赌，最擅长管理和影响开源供应链的人将最有资格创造最具创新性的产品。在本文中，我将解释为什么您应该成为供应链影响者，以及您的组织如何成为供应链中的积极参与者。

在我以前的文章《开源和软件供应链》中，我讨论了供应链管理的基础知识以及开源在该模型中的适用范围。我为读者提供了该模型的插图：

要问您的雇主和团队的问题是：我们如何最好地利用这一优势？毕竟，如果苹果公司可以通过建立更好的硬件供应链来为自己的主导地位打下基础，那么肯定可以在软件供应链上做到这一点。

评估供应链

在与许多公司的开发人员和产品团队合作之后，我了解到选择产品组件的过程是偶然的。有时官方会对一个或两个组件进行相互比较，但是开发人员经常选择使用基于“感觉”的产品。在确定最佳组件时，您必须根据这些项目的寿命，开发阶段以及足够的其他指标进行评估，以构成“构建与购买”决策的基础。用户数量，相关方，商业活动，开发团队参与支持等都是决策过程中的一些注意事项。

随着时间的推移，技术和业务需求将发生变化，在开源软件的世界中，变化更是如此。工程和产品团队不仅必须能够在那个时候选择最好的组件，而且还必须能够在时机成熟时将其切换到其他位置，例如，当管理旧组件的社区继续工作时，或者当出现具有更好功能的新组件时。

不该做什么

在评估供应链组件时，团队容易犯很多错误，包括以下常见错误：

“这里没有发明”（NIH） ：我无法告诉您工程团队决定决定自己编写多少次来“解决”现有供应链组件中的缺陷。我不会说“永远不会那样做”，但我会警告说，如果您承担编写基础结构组件的责任，请了解您正在剥夺开源供应链的所有优势，即上游测试和上游工程，并决定承担这些任务，立即让您的团队（和您的产品）背负只会随着时间而增长的技术债务。您正在选择效率较低的产品，最好有一个令人信服的理由。
推进补丁 ：任何精通开源的团队都了解为各自的上游项目贡献补丁的价值。这样做时，贡献的代码将通过该项目的自动化测试程序，与您自己的团队的现有测试基础架构结合使用时，可以使最终产品更加坚固。不幸的是，并非所有团队都精通开源。有时，这些团队面临繁重的法律要求，阻止他们寻求许可以向上游提供修复程序。在那种情况下，鼓励（na）经理就这些事情获得全面的法律批准，因为另一种选择是将所有这些更改都进行下去，招致大量技术债务，并在项目（或您）死亡之日之前应用补丁。
认为您只是用户 ：使用开源组件作为软件供应链的一部分只是第一步。要获得开放源代码供应链的收益，您必须加入并成为有影响力的人。（稍后会详细介绍。）

有效的供应链管理示例：Red Hat

由于采用了上游优先策略，红帽就是如何利用和影响软件供应链的一个例子。要了解Red Hat模型，您必须从供应链的角度查看其产品。

红帽支持的产品由经常由多个上游社区审查的开源组件组成，并且对这些组件所做的更改通常会在它们进入红帽支持的产品之前被推送到其各自的上游项目。工作流程如下所示：

这种工作流程有多种原因：

测试，测试，测试：通过减轻一些初始测试的负担，像Red Hat这样的公司将从上游社区的测试以及其他生态系统参与者（包括竞争对手）所做的测试中受益。
上游可行性：只有上游供应商可行且能够自我维持，红帽模型才有效。因此，确保这些社区保持健康符合Red Hat的利益。
工程效率：由于Red Hat将常见任务转移给上游社区，因此他们的工程师花费更多时间为客户增加产品价值。

要了解Red Hat供应链方法，让我们看看他们使用OpenStack进行产品开发的方法。

奇怪的是，红帽从OpenStack的创建不是要创建产品，甚至都不是发布产品。相反，他们开始将工程资源投入OpenStack的战略项目中（从Nova，Keystone和Cinder开始）。该列表逐渐增长，包括OpenStack社区中的其他几个项目。一位更传统的产品管理主管可能会考虑这种方法，并认为：“为什么我们会为尚未建立且没有产品的产品做出如此多的工程？为什么我们要免费为竞争对手提供我们的工作？”

相反，这是开源供应链的思考过程：

第1步

查看业务增长领域或需要填补的最大产品缺口。是否有一个适合战略缺口的开源社区？还是我们可以从头开始构建一个新项目来做同样的事情？在这种情况下，Red Hat查看了OpenStack社区，并最终确定它将填补产品组合中的空白。

第2步

逐渐打开工程资源表盘。这做了两件事。首先，它可以帮助工程团队了解各个项目的成功前景。如果前景不佳，公司可以停止投资，而花最少的钱。一旦确定项目值得投资，公司可以确保其工程师将影响当前和未来的发展。这有助于质量代码开发项目，并确保代码满足将来的产品要求和验收标准。在宣布OpenStack产品之前，Red Hat花了很多时间在OpenStack存储库中存储代码，而发布它的时间要少得多。但这只是该公司从头开发IaaS产品的投资的一小部分。

第三步

一旦工程投资开始，就启动产品管理路线图和市场发布计划。一旦代码达到最低质量级别，请派生上游存储库并开始处理特定于产品的代码。错误修复程序被推送到openstack.org上游并进入产品分支。（请记住：Red Hat的模型取决于上游的生存能力，因此不向上游推送修订毫无意义。）

泡沫，冲洗，重复。这就是您管理开源软件供应链的方式。

不要积累技术债务

如果需要，Red Hat可以决定仅依赖上游代码，提供必要的专有产品胶水，然后将其作为产品发布。实际上，这就是大多数公司对上游开源代码的处理方式。但是，这错过了我之前提出的关键点。要开发出真正出色的产品，需要大量参与开发过程。如果组织不参与日常体系结构讨论，那么如何确保代码库满足其核心产品标准？

更糟糕的是，为了保护向后兼容性和互操作性，许多公司叉起了上游代码，进行了更改，而不是在上游进行贡献，而是选择在内部进行继承。这是一个很大的禁忌，使您的工程团队永远背负着只会随着时间而增长的累积技术债务。在这种情况下，从上游测试，开发和发布中获得的所有收益都会变得愚蠢。

红帽和OpenShift

一旦您开始了解Red Hat的供应链方法（可以在OpenStack的方法中看到它的体现），就可以了解其Red Hat的方法。红帽首先发布OpenShift作为专有产品，该产品也是开源的。一切都是自家生产的，由一支加入Red Hat的团队建造，这是2010年对Makara的收购。

尽管最近（当时）发布了新项目（如Kubernetes，Mesos和Docker），但该技术最初还是受到NIH的困扰-使用其自身的群集和容器管理技术。红帽下一步要做的事情证明了该公司对其开源供应链模型的承诺：在OpenShift版本2和版本3之间，开发人员重写了它以利用和利用Kubernetes和Docker社区的新开发成果，放弃了NIH方法。通过以这种方式重组项目，该公司利用了两个项目的Swift发展的开发者社区所带来的规模经济。一世

他们可以依靠Docker和Kubernetes社区提供的测试基础架构，而不是Red Hat为整个OpenShift堆栈构建完整的QC / QA测试环境。因此，在到达公司自己的产品分支之前，Red Hat对Docker和Kubernetes代码库的贡献都要经过几轮测试：

第一轮测试是由Docker和Kubernetes社区进行的。
生态系统参与者在一个或两个项目上构建产品，可以进行进一步的测试。
对下游代码发行版或“嵌入”两个项目的产品进行更多测试。
最终测试在红帽自己的产品分支中进行。

在代码上进行的大量上游（来自Red Hat）测试确保了质量水平，对于公司而言，从头开始进行全面的测试要昂贵得多。这是开源供应链管理的窍门：不要仅仅消耗上游代码，而是将其最小化地填充到产品中。这种方法不会给您任何开源开发实践和直接参与解决客户问题的优势。

为了从开源软件供应链中获得最大收益，您必须是开源软件供应链。

翻译自: https://opensource.com/article/17/1/be-open-source-supply-chain