楼主把"一个人读得完"立为开源的硬标准,这个尺度很实在。不过供应链投毒那段,我想补几个案例:近年几起影响最广的投毒,受害包体积都不大,理论上都在"读得完"的范围内。其实
2018 年 event-stream,代码精简可读,问题出在维护权转交给了恶意接手者,恶意逻辑藏在新引的子依赖里;2022 年 colors.js 是作者主动 sabotage,源码全程公开却没人料到;最典型是 2024 年 xz-utils 后门——载荷没放在常被 diff 的源码里,而是混进测试数据和构建脚本,靠混淆藏匿。真正发现它的不是"有人通读一遍",而是有人注意到 SSH 登录变慢。严格来说
所以"读得懂"防得住粗心和明面上的恶意,但对有准备的攻击者,依赖树大小不是关键变量:一个被信任的维护者账号加几行混淆代码就够了。威胁模型从"能不能读完"变成了"能不能验完构建链路,含那些不算源码的部分"。
再从 review 机制看,"单人通读"在 spell 年代或许成立,放现在更像理想化设想。Linux 内核几千万行,靠的不是某人读完全部,而是分层 review:各子系统有人负责、互相挑刺,再叠 CI、模糊测试、静态分析。review 的扩展性不随行数线性恶化,而取决于模块化与流程成熟度。
从某种角度看,真正值钱的或许不是"小",而是"可分解的 review"——每个部件小到有人真正拥有并理解,比"整个东西塞进一个人脑子"更现实。suckless、busybox 把约束当美德可取,但也得承认它们牺牲了兼容性和功能换精简,未必普适。
你对"读完才算真开源"这条线,会划到依赖哪一层?构建脚本和打包流程算不算该被读的范围?