| 作者：庄表伟| 编辑：钱英宇| 设计：谭嘉露| 责编：王玥敏
1
供应链与断供
隐喻会帮助人，也会误导人。
当我们谈到“供应链”时，会产生哪些联想？环环相扣？缺一不可？掉链子？当我们这样去思考软件供应链，或者开源软件供应链时，同样的“意象”也会出现在我们的脑海里。
一条从不知名的远处延伸到我们面前的链条，这个链条的最后一环，是一款我们看得见、用得上的软件。
这个链条当中，有很多环节都是别人（美国）提供的。也许有一天，美国（人）一旦决定，拿回他的那一环。我们就断供了，延伸到我们面前的链条就断掉了，我们手中正在使用的软件，就消失了。
这就被称为————“断供”。
2
物质断供
当一个链条是由物质构成的时候，这个“意象”并不是幻想，而是实实在在的现实。比如：芯片断供，手机缺货。GPU断供，显卡涨价。
当我们想要把这个情况，引申到软件、甚至开源软件领域的时候，我们必须重新定义“断供”。
这就带来了各种“乱象”。
3
开源软件断供：分类
从中国，无法下载到美国（Github）上的开源代码。或者无法及时下载到最新的源代码一个开源社区，用规则或潜规则，拒绝中国开发者，导致中国开发者被排除在外。我们的开发者被禁止向上游提交代码，无法参与、回馈社区基于某种License（不允许商业使用、不允许邪恶用途、不允许特定国家使用）具体某一款开源软件的某一个版本，存在安全漏洞，需要修复（或替换）- 项目缺少投入，无法继续发展（感谢 @Donald@CNCF@LFAPAC 的补充）
一款无人维护的开源软件（维护不及时，不到位），比如曾经的OpenSSL，就是一种值得关注的风险
首先推荐一本非常了不起的著作《技术的本质》（布莱恩·阿瑟），在这本书中，布莱恩提出了一些极其深刻的洞见。例如：技术的本质是对现象的驾驭。以及：技术是组合与递归的。
我想继续引申这个观点。类似于我们在做软件开发时，通常会定义的一个依赖文件。一款软件，会依赖一组其他软件（包），而这些软件（包）又会进一步的依赖某些其他的软件（包）。但是，随着包依赖描述的不断改进，我们会区分：开发期（Dev)依赖与执行期(Running)依赖。
在更加广泛的技术领域，我们也会发现类似的现象。我们发明一种新技术时（开发期），会依赖一组其他已有的技术。但是，当我们基于这个新技术，生产某一个产品时，会依赖另外一组技术（编译期），当我们的产品被实际使用时，还会依赖其他一些技术（执行期）。
当我们泛泛的分析技术时，可以发现其中的组合与递归结构。而当我们更加深入的分析技术的依赖关系时，会发现不同的依赖与递归结构。
《技术的本质》告诉我们，依赖一定存在，而且无穷无尽。但是：依赖不能简单的等同于风险，至少不能等于同样大小的风险。
当我们对于开源软件，做供应链风险分析的时候。泛泛的树立一个假想敌，然后一概以风险视之，不但将风险不断放大，也将防范风险手段无限提升。
我认为：这并非一种理性的应对风险的策略。
如果我们将“链条”的隐喻，换成“生态圈”的隐喻，来看待软件、以及开源软件所面临问题。也许会更加有利于我们朝向正确的方向前进。
空气、水、土壤与风，是环境的一部分。温度、湿度、海拔也是环境一部分。对于一个生态圈来说，我们虽然也提“食物链”，但是很难想象：一个单一物种的缺失，会导致整个食物链的断裂，以及食物链上端的物种全部灭绝。所以：事实上现在描述生态系统时，常用的概念是“食物网”而非“食物链”。
作为软件行业的从业者，我们应该关注整个生态的健康程度，以及预防可能存在的“污染”和“破坏”。甚至，考虑到生态多样性，我们也的确应该支持更多类似的软件，甚至竞争性的平台。
但是：这并非一场“为了防止我的链条断掉”，而发起的一场“伟大战斗”。这是一场“建设更加丰富、繁荣的软件生态的运动”。
所以，我的提议是：不再提“开源供应链安全”，而是提“开源生态建设”。
与诸君探讨。
开源社简介
开源社成立于2014年，是由志愿贡献于开源事业的个人成员，依“贡献、共识、共治”原则，所组成的厂商中立、公益非营利的开源社区，是最早以“开源治理、国际接轨、社区发展、开源项目”为使命的开源社区。开源社积极与支持开源的社区、企业以及政府相关单位紧密合作，旨在共创健康可持续发展的开源生态，并推动中国开源社区成为全球开源体系的积极参与及贡献者。
相关阅读 | Related Reading
我们在夏风和煦的BBQ 期待与您来一场开源盛会的畅聊
《大咖说开源第二季》三、四期
In Community We Trust