开源和软件供应链

Docker是集装箱之意,它的出现和发明,一如真实世界的集装箱改变货物的运送,彻底的改变了软件的交付方式。那么物理的物体是有供应链的科学方法论支撑的,高效的供应链可以节省成本,事半功倍。那么这些理论是否能够用于软件的开发和生产了呢?尤其是在开源软件大的生态环境中。本文尝试诠释他们,以及背后的机理。

Thu May 18, 2017 | 3100 Words | 大约需要阅读 7 分钟 | |

如何有效利用开源社区的资源来进行软件生产(开发)。

掌握硬件供应链及其管理的细微差别是显而易见的,其实就是在追踪一些移动的箱子。那么在开源社区,利用人们所贡献的资源来开发相应的软件,则显得摸不着头脑。

我在写作如何利用开源来赚钱的文章的过程中,在思考这开源平台和供应链,那时,我认为供应链是一个单一的流程,使用现有的开源组件,然后基于此生产出一个结果来,这就是通常所说的软件产品。从那之后,我细心的观察并思考开源生态系统的供应链,发现远远不止一个,错综复杂。然后发现,那些懂得去管理和影响供应链的要比不理不睬的更具有竞争优势。这就值得我们进一步的挖掘。

软件供应链如何运作

在硬件的世界里,供应链和组件采购对于业务来说是必不可少的一环。能否管理一个良好的供应链,对于企业的成功是至关重要的。如何确定较为理想的定价?如何与正确的制造商构建良性的关系?如何最大化的提高供应链的效率?以达到能够以最便宜的成本,生产并销售更多的产品。Apple公司的供应链是业内顶级的典范, Apple是第一个意识到建立有效的零部件供应链是制胜的关键的公司,就在硅谷的绝大多数公司都在自己蒙头制造零部件的时候,Apple已经先行一步了。

当时整个计算机界都在嘲笑Apple,称其为“营销公司”,因为它不制造任何零部件。到如今,每家硬件公司都有着广泛的供应链,而且会致力于不同的团队来管理它的方方面面。再回到Apple,令人大跌眼镜的是,它在供应链物流上的创新要比实际的产品更胜一筹。或者换个角度来理解Apple的供应链,其在供应链物流方面的创新为Apple在推出创新产品提供了卓越的支撑平台。

让我们将视线拉回软件界,相对于硬件的供应链来说,软件就简单多了。硬件的供应链则是来源于不同地区的许多不同合作伙伴的零部件,传统的软件供应链大多定义了内部制作软件的过程,以及通过商业许可协议的供应商所提供的一些第三方软件。在此模式下,供应链的大多数来源被定义为公司内部,最多是由多个工程团队构成。来自公司外部的软件仅占其中一小部分,供应链的定义主要由内部产品管理和工程团队负责。是的,来自第三方供应商的许可软件在产品组装时需要许可证合规性检查,这意味着获得任何软件,都需要得到许可协议的合法许可。这个过程与常规做法是完全一致的,许多许可协议源于法律和产品管理团队经历的同一法律模板,但是随着开源逐渐成为主流,这一切都被颠覆了。

我们从一个简单的,定义明确的示例来看软件供应链,是这样子的:

那么开源的情况则是混乱的:未经验证的许可证、未经测试的软件仓库、以及狂野的西部牛仔(开发者),这一切所导致的软件供应链看起来似乎是不可管理的,漏斗的形状更像是这样:

正如您在上图中所直观看到的一样,至少开源导致了一个额外层次的增加。

或许你并不这么认为,而是说,将开源组件简单的插入产品中,和过去授权插入第三方的组件没有任何本质上的差别。这里要说明的是,虽然看起来没什么大的变化,但是有一个隐性的知识需要考虑。关于上游的开源组件,多数的源代码仓库时候是没有任何的商业保证的。作为供应链或产品经理,最不愿意的事情就是被别人掐住喉咙,一旦出错,是无法补救的。

此时,您有两个选择:

  1. 建立自己的内部审核代码和应用产品管理流程的方法。
  2. 依靠中间厂商来完成这个事情。

当选择1时,您需要自行从上游拉下代码、确定合法合规、构建流程、应用补丁、为自己的产品准备好,似乎一切都很美好,但是对于人力资源来说,这太过于昂贵。

作为高管的你,是否采用1的流程,应从公司战略的重要性和ROI(投资回报率)进行认真的分析:如果为某些软件组件建立一个团队,来管理整个流程,那么这样做有足够的投资回报吗?

举例

在许多情况下,公司决定与中介机构一起审查代码,执行一些质量保证工程,当然,必要的时候也会采用非常规策略,来满足最终的产品需求。这就是软件发行版存在的理由,它们背后的商业公司有:红帽、SUSE和Canonical,很多人都会产生疑问:这些公司有存在的必要吗?是的,这个问题回答起来不太容易,但是从软件供应链的角度来讲,如果没有这些公司提供的发行版,整个Linux的世界将是灰暗的。

可以想象一下没有如红帽企业级Linux(RHEL)或相类似的发行版,一家公司开发产品,将不得不把所有的上游的项目整合进自己的流程,审核代码,并招聘业内顶级的专家来增强它们,然后再将它们集成起来,经过这一系列的过程之后,方能够发行然后将产品推向市场。也就想象一下就可以了,聪明的公司都会决定,让这些发行版公司做他们该做的事,这样会省去非常大的一笔投入,而且可以聚焦精力做其它更重要的事,也更有效率。

另外,以上所说的还是开源“用户”的情况,还不是供应商。以下才是真正有趣的地方。先问自己一个问题:在自己的产品中使用了或者插入了开源代码,要想成为供应链的影响者或供应商,最好的方法是什么?一个潜在的结论是,要在开源产品方面取得成功,必须掌握影响和管理最终在产品创建过程中汇集的各种供应链的能力。一旦完成这点,最终的产品则会大大受益,即上面图“漏斗”中左边的 上游参与

不要去维护一组标准的补丁,而是将这些补丁持续的贡献给上游。因为贡献给上游,会省去公司内部很多的资源,而是让整个社区即外部资源来维护。如果你已经作出了决定,认为使用下游的软件发行版要比自己采用和审核源码更加的容易的话,那么问题来了,”这时我如果在上游贡献代码,但是我又和发行版厂商进行了合作,那么还能享受到上游的好处吗?”答案是显而易见的,这样做可以帮助其他组织管理和支持维护此代码的附加优势,让您的工程师们能够开发直接为您的产品带来价值的有趣的东西。无论你是售卖软件、售卖软件服务、还是创建开源社区,用心专研你的供应链,并学习其最佳管理方法,这绝对是值得投入时间去做的事情。

硬件供应链,是基于实际物理物体的,相比于软件的供应链,更加的静态。那么对于开源软件供应链来说,则是更加的灵活多变,会随着时间的推移,越来越式微,无论你在项目中身处何种角色:商务人员也好,开发人员也罢,甚至是社区经理,必须决定那些值得投入时间和精力,发现错误能做到及时减损,并及时的切换到其它的供应链。在项目启动的时候,所使用、修改、和创建的组件都将依赖于供应链的状态,其中的过程,有主动,也有被动。必须积极主动地决定对哪些供应链进行投资,哪些应该忽略,同时对依赖生态系统的快速变化作出反应。那些掌握这种艺术的人,在理论上拥有最佳实践,方可能像Apple公司一样,最终将赢得胜利。但期望归期望,具体的实现效率还要看水平,也就是说工程团队要更具创造力。

结语

如果你想有效的管理软件组件的供应链,同时所建造的高效的供应链“漏斗”,——能够在正在开发的产品上进行快速迭代,产品创建和管理流程将会得到大大的改善。这种管理需要资源投入,不仅仅是您的产品的质量保证体系和供应链“漏斗”,而且在供应链中所使用的组件,用来直接创建产品。

关于作者

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

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

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

英文原文:Open source and the software supply chain ,开源之道精心翻译出品。