Ant Design 圣诞节彩蛋事件之后，作为一名开发应该如何正确使用第三方库？ 第1页

现在的软件研发体系，早已经是一个成熟的工业体系，而不再是十几二十年前的小作坊年代了。

换句话说，绝大部分底层/基础组件的开源项目，我先不说难度，就以其代码规模而言，绝大部分使用者都是没能力完整的code review的，哪怕是patch review都几乎可能。包括但不限于：各种内核/引擎（如linux/webkit/各种脚本……）、各种数据库（别说mysql这种了，连通读sqlite的人在整体开发者中，占比恐怕都是凤毛菱角）、各种基础库（glibc/qt……）

事实上，这是软件业从二三十年前的手工小作坊走向大工业化的一个必然现象：

就好像建楼房，你最多也只会抽检部分砖头，而不会每个都检查一遍里面是不是埋了雷；

你造车，同样也只会抽检供应商提供的发动机，而不会review ecu的代码以确保里面没有什么彩蛋；

而同样的，发动机制造商采购soc跑ecu，也只会做基础的检测，而不会逐个放在电子显微镜下去检查是不是有缺陷。

因为在大工业化阶段，任何一个产品，都是整个产业链的各种产品的相互配合和协作才能完成的。任何单独一个企业，都不可能有能力去完成对整个产业链的所有产品的review。软件业也不例外。

所以，从本质上说，各种开源协议及其免责条款，本质上反映的是二三十年前，软件业的那种小作坊时代的面貌。因为在那个年代，软件项目都比较小，而且圈子也比较小，再加上大多数人都是比较geek的人，所以有个免责条款，要求使用者自负，是完全合理的。

然而，随着软件业的快速扩大，各种不同层级，不同专业方向的开发者进入之后，不说技术专业方向，光说精力就决定了不可能再要求review的。更何况，软件业现在已经有了太多的分支，很多分支基本上都是隔行如隔山的：例如说做数据库的为了写个好看点的webadmin，就要去review js库？做ic的为了写个驱动，就要去review整个kernel？现实吗？

所以，并不是因为信任某个库，所以没做code review，而是因为没精力/没能力去review，所以不得不信任某个库。

这时候，各种开源协议的免责条款，实际上是阻碍了这种工业化的。一定程度上也是在逼迫大家“重复造轮子”——事实上很多时候，review一些自己并不熟悉的代码，甚至还不如自己写一份。这也是为什么大家在做开源项目选型的时候，一般对大公司开源出来，或者大公司已经广泛使用的项目会高看一眼——虽然都有免责条款，但是至少觉得经过大公司过了一遍，应该雷会少点，以求得一点心理安慰。不过，这次的事件恰恰说明了，大公司也不可靠，尤其是他们想自己埋雷的话。