供应链与断供

隐喻会帮助人，也会误导人。

当我们谈到“供应链”时，会产生哪些联想？环环相扣？缺一不可？掉链子？当我们这样去思考软件供应链，或者开源软件供应链时，同样的“意象”也会出现在我们的脑海里。

一条从不知名的远处延伸到我们面前的链条，这个链条的最后一环，是一款我们看得见、用得上的软件。

这个链条当中，有很多环节都是别人(美国)提供的。也许有一天，美国(人)一旦决定，拿回他的那一环。我们就断供了，延伸到我们面前的链条就断掉了，我们手中正在使用的软件，就消失了。

这就被称为————“断供”。

物质断供

当一个链条是由物质构成的时候，这个“意象”并不是幻想，而是实实在在的现实。比如：芯片断供，手机缺货。GPU断供，显卡涨价。

当我们想要把这个情况，引申到软件、甚至开源软件领域的时候，我们必须重新定义“断供”。

这就带来了各种“乱象”。

开源软件断供：分类

• 无法下载

从中国，无法下载到美国(Github)上的开源代码。或者无法及时下载到最新的源代码

• 无法参与上游

一个开源社区，用规则或潜规则，拒绝中国开发者，导致中国开发者被排除在外。我们的开发者被禁止向上游提交代码，无法参与、回馈社区

• 修改License之一：闭源

在某个版本之后，该软件不再提供开源代码

• 修改License之二：排除特定类型用户

基于某种License(不允许商业使用、不允许邪恶用途、不允许特定国家使用)

• 生态限制

开源本身不断供，但是开源所依赖的服务，无法使用

• 代码托管平台断供

整个Github不允许你使用

• 开源软件安全风险

具体某一款开源软件的某一个版本，存在安全漏洞，需要修复(或替换)

• 项目缺少投入，无法继续发展(感谢 @Donald@CNCF@LFAPAC 的补充)

一款无人维护的开源软件(维护不及时，不到位)，比如曾经的OpenSSL，就是一种值得关注的风险

《技术的本质》与其不足之处

首先推荐一本非常了不起的著作《技术的本质》(布莱恩·阿瑟)，在这本书中，布莱恩提出了一些极其深刻的洞见。例如：技术的本质是对现象的驾驭。以及：技术是组合与递归的。

我想继续引申这个观点。类似于我们在做软件开发时，通常会定义的一个依赖文件。一款软件，会依赖一组其他软件(包)，而这些软件(包)又会进一步的依赖某些其他的软件(包)。但是，随着包依赖描述的不断改进，我们会区分：开发期(Dev)依赖与执行期(Running)依赖。

在更加广泛的技术领域，我们也会发现类似的现象。我们发明一种新技术时(开发期)，会依赖一组其他已有的技术。但是，当我们基于这个新技术，生产某一个产品时，会依赖另外一组技术(编译期)，当我们的产品被实际使用时，还会依赖其他一些技术(执行期)。

当我们泛泛的分析技术时，可以发现其中的组合与递归结构。而当我们更加深入的分析技术的依赖关系时，会发现不同的依赖与递归结构。

依赖与风险

《技术的本质》告诉我们，依赖一定存在，而且无穷无尽。但是：依赖不能简单的等同于风险，至少不能等于同样大小的风险。

当我们对于开源软件，做供应链风险分析的时候。泛泛的树立一个假想敌，然后一概以风险视之，不但将风险不断放大，也将防范风险手段无限提升。

我认为：这并非一种理性的应对风险的策略。

换一种隐喻

如果我们将“链条”的隐喻，换成“生态圈”的隐喻，来看待软件、以及开源软件所面临问题。也许会更加有利于我们朝向正确的方向前进。

空气、水、土壤与风，是环境的一部分。温度、湿度、海拔也是环境一部分。对于一个生态圈来说，我们虽然也提“食物链”，但是很难想象：一个单一物种的缺失，会导致整个食物链的断裂，以及食物链上端的物种全部灭绝。所以：事实上现在描述生态系统时，常用的概念是“食物网”而非“食物链”。

作为软件行业的从业者，我们应该关注整个生态的健康程度，以及预防可能存在的“污染”和“破坏”。甚至，考虑到生态多样性，我们也的确应该支持更多类似的软件，甚至竞争性的平台。

但是：这并非一场“为了防止我的链条断掉”，而发起的一场“伟大战斗”。这是一场“建设更加丰富、繁荣的软件生态的运动”。

所以，我的提议是：不再提“开源供应链安全”，而是提“开源生态建设”。

与诸君探讨。