成为开源软件供应链本身——学习为什么应该成为供应链的强有力的影响者

在真正的开源当中，你拥有掌握自己命运的权力。 –Linus Torvalds

我敢断言：能够管理和影响开源供应链，那么就为创建最具创造性的产品获得了有利地位。本文中，将解释为什么我们应该成为供应链的影响者，以及如何在供应链上下游中进行积极的参与。

在上一篇文章：开源和软件供应链中，探讨了供应链管理的基础，以及将开源套进这样的模式中来，并对开源的软件供应链使用了如下图所示的诠释：

那么问题来了，该如何做才能够从这样一个链条中获得最大好处？因为我们可以看到 Apple 通过创建优秀的硬件供应链，获得了很大的竞争优势，那么我们一定可以从软件供应链中获得同等的效果的。

评估供应链

曾经在多家公司和开发团队、产品团队共事，我了解到，选择进入产品的组件的过程是偶然的。有时会遇到一、两个其中的组件相互排斥的情形，但是我们的开发者通常是靠“感觉”来选择其中的进入产品。在决定最佳组件时，你必须基于这些项目的生命周期、开发的阶段、以及其它重要的指标来进行评估，进而决定是自行构建还是购买。还有一些重要的会影响决策的因素，如：

• 用户的数量
• 有意思的发明
• 商业活动
• 开发团队的参与和支持
• ……

随着时间的推移，技术和业务均需跟上时代的节奏，在开源软件的世界，道理也是一样的。工程和产品团队不仅可以选择当时最好的组件，而是要紧跟步伐，当出现变化时，能够及时、敏锐的切换到更优秀的组件上，举个例子，当社区所管理的旧的组件被移走时，或者是有更加卓越的新的组件被创造时，就会出现这样的情况。

禁忌

在评估供应链组件时，有些团队容易犯一些错误，比如下面常见的：

• 自行蒙头搞发明（NIH）：我没法告诉你，该何时去修复现有的供应链组件的问题，又或者是何时重新制造一轮子。我也绝不会说从来不要那么去做。我这里要说明的情况是，假如读者您独自承担了编写基础架构组件的责任，那么你要明白一件事，那就是正在将开源供应链的所有优势推掉，诸如上游的测试、上游的工程能力，都一点也用不着了，而且让您的团队在背负技术债务（产品亦是），这些债务会随着时间的推移了翻倍增加。这样做的话，效率会相对底下，除非你有更能说服他人的理由和实践，否则的话，听我的，千万不要这么干。
• 将补丁攥在自己手里：任何懂的开源的人都能够理解为各自的上游社区贡献补丁的价值所在。当真正这么去做的时候，贡献代码本身就会贯穿该项目的自动化测试的流程，当这与现有的测试基础设施架构相结合时，可以对最终的产品质量进行进一步的改进。然而，现实的情况是，不是所有的团队都真正的懂开源。比如，有的时候，团队面临公司内部苛刻的法律要求，使他们没法为上游贡献，无法获得许可。在这种情形下，我的建议是大力说服你的经理去申请允许这一切的法律许可：理由就是如果不把这些变动提交到上游，攥在自家手里，就成了沉重的技术债务，会付出惨重的代价，甚至是可能引起项目的失败的重大原因。
• 想着只有自己一个用户：使用开源组件仅仅是软件供应链的一小部分，要获得更大的开源供应链的回报，您必须融入开源并成为其有力的影响者。

有效的供应链典范：红帽

红帽是当仁不让的既利用了开源又在开源有着独一无二的影响力的公司，以它为例，概莫能外，而这其中的诀窍就是：上游优先策略。若要深入理解红帽的模式，我们必须通过供应链的视角来审视红帽的产品。

由红帽所支持的产品，均是多个开源组件的组合，且来自不同的上游社区，红帽会对所有这些组件的更改都推送到上游的各自的项目中，而这有违人们直接的是，这些都是在红帽正式发布产品之前进行的。大体的工作流程示意图如下：

红帽之所以这么做，是有充分的理由的：

• 测试、测试、测试：通过将最初的一些测试分担出去，像诸如红帽这样的公司可以获得两方面的好处：一是上游社区的测试，而是能够获得其它生态的支持，包括竞争对手。
• 上游可行性：只有上游社区是正常运转并自给自足的，红帽的模式才是可行的。因此，红帽必须确保上游的社区是健康运转的。
• 工程效率： 因为红帽将很大一部分工作分担到了上游社区，他们的工程师可以将更多的时间花在为用户生产更多的增值产品。

关于红帽供应链采用的方法的理解，我们得从具体的项目和产品来入手，比如其OpenStack的开发和上游参与。

红帽的做法是一番常人的思维的，红帽开始启动OpenStack的时候，并不是从产品开启的，甚至都没有做过任何的声明，而是在OpenStack的项目（如具体的Nova、Keystone、Cinder）上投入了大量的资源，并随着时间的延伸，并扩展到OpenStack社区其它的项目中。这样的做法对于很多传统的产品经理是不可思议的：“这个地球上还有人在没有创建任何产品的情况下就贡献大部分的工程资源？为什么要为竞争对手免费做大量的工作？”

那么，以下就是开源供应链思考的流程：

步骤一

紧盯着业务的增长领域，然后想想做什么样的产品能填补缺口。问自己的问题：开源社区能否将这个坑给填上？或者说我们从头开始构建一个产品做来满足用户？ 正是基于这样的考虑，红帽将宝押在了OpenStack社区，并最终确定采用它来填补产品组合的空白。

步骤二

逐步的投入工程资源。这需要分作几步走，首先，它能够帮助到工程团队去准确的理解项目前景，假如说前景比较暗淡，公司可以决定停止贡献，而这只会有少量的投入。第二，如果工程团队的结论是前景光明，那么公司的投入，可以确保自己雇佣的工程师对于项目是有影响力，并会影响项目的未来。这有助于项目的高质量的代码开发，并确保代码满足未来的产品要求和验收标准。在宣布OpenStack产品之前，Red Hat花费了大量时间在OpenStack存储库中审核代码，而发布则更为滞后。换个角度讲，相比这是从头开启一个项目的话，那么其开销和如此的开源上游投入相比，简直是大巫见小巫。

步骤三

一旦开始了工程资源的投入，红帽就可以就会启动产品管理的路线图和市场发布计划。当代码达到最低质量标准时，就会从上游仓库fork出分支来，然后开启产品化的开发和强化。Bug的修复均会直接在上游openstack.org上提交，同时也会合并到产品化的分支。（要记住：红帽的模式严重依赖于上游的可行性，所以他们不会不把代码提交到上游。）

优化、试错、然后重复上述步骤。这就是所谓的如何管理开源软件供应链。

不要拖欠更多的技术债务

如果需要的话，红帽会尽可能的减少对上游的依赖，提供一些必要的专有的产品的黏合剂，从而发布其产品。其实，说实在的，就是这么个道理，有太多的公司视而不见，虽然他们也是同样直接采用了开源的代码。想要开发优秀的产品，能够积极的参与到整个开发过程是绝对必要的。我们可以逆向思考一下：如果一个组织不去参与项目的日常架构讨论，这个组织如何确保代码库符合其核心产品标准？

大多数情况是更为糟糕的情形：从上游fork代码，然后基于此进行更改和开发，但是不会将之合并到上游，那么为了向后的兼容性以及业界的互操作性，那么这些变更就得自己来维护。这是一个非常严重的错误，这会将工程团队陷入深渊，随着时间的推移，所负的技术债会越积累越多。在此情形下，上游所有的测试、开发和发布的内容都成了可望而不可得的收益，只能眼巴巴的看着。

红帽和 OpenShift

如果读者您现在开始对于红帽的开源软件供应链有了一定的认识和理解的话，那么从上述其对待OpenStack的策略来推演，理解起来OpenShift就更加的轻车熟路了。红帽发布OpenShift商业版时，其对应的开源版本是先行发布了的，而这个开源版则来自于红帽在2010年收购的一家叫做Makara的公司所开发，当然，红帽还做了团队的融合过程。

从技术上来说，最开始的时候，OpenShift完全是自己搞了一套集群和容器管理技术，即上文提到NIH，但是后来（最近特火爆）一些新的开源项目发展起来了：Kubernetes、Mesos、Docker等，那么接下来发生的事情，则充分说明了红帽公司对于开源供应链独特的理解（和一线工程师对于技术的敏锐：译者黑心添加）：在OpenShift版本2到版本3之间，他们做了一个重大的决定，彻底重写，以利用新起项目Kubernetes和Docker的优势，融入、参与这些社区，将NIH方法彻底废弃。通过这样的方式重构项目，红帽公司有效的利用了这两个项目开发人员社区不断增长的规模经济。

红帽聪明的做法在于，此时并没有选择将整个的 OpenShift 栈的 QC／QA 环境都自己搞起来，而是将底层的基础设施组件Docker和Kubernetes利用起来，囊括进来，因此，Red Hat开始对Docker和Kubernetes的代码库进行积极的贡献，在这些组件达到公司自己的产品分支之前进行几轮测试：

1. 第一轮的测试由 Docker 和 Kubernetes 社区来进行的。
2. 进一步的测试，则是由基于同样基于这两个项目做产品的生态的参与者来完成的。
3. 下游代码分发或“嵌入”两个项目的产品都会发生更多测试。
4. 最后才是红帽自己产品分支的测试。

（对于红帽的情况）将代码交给上游来进行测试，不仅确保了最终产品的质量，还大大节省了公司的成本，可以想一下公司若是从头自行来过的话，这是一笔多大的投入。而这恰恰是开源软件供应链的精髓：不要仅仅去消费上游代码，然后将之微调成为自己的产品。如果你不去这么做的话，你无法获得开源开发实践所带来的益处，也无法去直接参与去解决你客户的实际问题。

若要从开源软件供应链中获得收益，必须成为开源软件供应链本身。

关于作者

John Mark Walker 是 Dell EMC 的产品管理总监，负责管理ViPR 控制器产品，以及CoprHD开源项目，他也是资深的开源社区活跃者，如ManageIQ、Gluster、Hyperic，乃至过去的SourceForge。

关于激进的言论，请关注他的Twitter：@johnmark，他也有领英账号：johnmarkwalker，也不定期的会更新自己的博客：johnmark.org。

John Mark 经常在各个开源技术会议上做演讲，并有优秀的论述开源的文章，如根本就不存在开源社区、永远不要搞创新、逝者如斯：写在VA Linux IPO 十年之际。

英文原文：Be the open source supply chain ，开源之道精心翻译出品。