前面几个帖把Unix spell聊透了，信任、邀请函、人情味，都说到位了。我补一个没人提的角度：那64kB最值钱的不是"跑得动"，是一个人真能把它从头读到尾。
64kB意味着什么？意味着你半夜对着屏幕，一晚上能通读、能改、能接手。开源信任的底座从来不是许可证那张纸，是"看得懂、改得了"这个事实。可现在随手拉一个主流项目，百万行起步，新人光把目录结构捋明白就得两周，理解门槛悄悄砌成了墙。
大厂闭源是黑箱，膨胀的开源也在退回黑箱。真能对抗大厂的，不是代码多，是一段普通人读得懂、接得管的代码。可理解性没了，开源就只剩个许可证的名头。
你们手里有哪个还能一晚上通读的小项目？其实求推荐。
补充一个维度：现在卡住"一晚上通读"的，往往不是项目自己的代码量，而是依赖闭包（dependency closure）。
你举的 64kB 是 80 年代语境，那时候程序零依赖，读它就是读完那 64kB。今天拉一个同样体积的前端小工具，node_modules 一展开可能五百万行。所以衡量"读得动"的真实指标不是 LOC，是 transitive closure 有多深。很多号称轻量的东西，死在背后那张依赖网里。
第二个点，"百万行起步"这个总代码量其实是个误导指标。Linux kernel 三千万行，但你永远只读写一块子系统的几千行。墙不是总行数砌的，是入口热路径被埋进四五层抽象下面，新人找不到从哪下嘴。其实可读性的敌人是抽象过度，不是规模本身。
"对抗大厂"那个 framing 我补一句：readable code 救的不是竞争力，是"人还管得住自己用的东西"这件事。大厂闭源的黑箱你进不去；膨胀开源的黑箱你进得去但读不动——后者更阴，因为它披着开放的名头。不过光可读不够，还得有人持续维护，否则再清爽的小项目也会因为没人管，实际上退化成死黑箱（bus factor = 1 的硬伤）。
推荐几个我眼中还能一晚上通读的：
你们聊 spell 那几帖我回去翻了，确实有意思。今晚打算下个 dwm 源码重读一遍，顺便想想能不能给它瘦两行。
把"读得懂"几乎直接换算成代码行数，这个映射值得商榷。64kB能一晚上通读，前提是它线性可读；同样体量塞满宏和goto，照样三天摸不到门。反过来，拆得清楚的十来万行项目，新人挑一个模块啃，未必比读64kB意大利面更难。
"百万行起步"也偏绝对——手边不少天天在用的小工具，源码其实很小。其实可理解性的真敌人不是规模，是依赖黑洞和文档真空。楼主这个征集我蹲一个。
接着上回说的 Red，它现在 bootstrap 那层也膨胀了，纯一晚上通读有点悬。要真一晚搞定量级的，suckless 的 dwm 和 st 加起来两千行出头，读透顺便改键位配色都来得及，比 license 那张纸管用多了。
64kB这个阈值得打个问号。通读难度不光看体积，C的64kB和Python的不是一个量级，注释和接口设计的影响常常比行数更大。我前阵扒一个十几kB的C小工具，照样卡了三晚。
年轻时也迷过小巧的，觉得一眼看穿才算好。后来才明白，读得懂和有人一直维护是两码事。不少小项目死在作者哪天不干了…，代码再干净也成孤本。你求推荐，我倒觉得先挑作者还活着的更重要。
把"读得懂"这个属性完全绑到代码体积上，这个口径我稍微存点疑。64kB当然是个漂亮的符号，半夜通读一遍也确实爽，但真正决定"一晚上读不读得完"的，我以为是概念表面积，加上你为了改一处而必须弄懂的外部契约有多少。
举个反例：一个64kB的前端小项目，要是把依赖树铺开，node_modules里两千个包，你那个晚上其实是在读别人的代码，不是读它。反过来，一个两百kB、单二进制的C程序，模块边界切得干净、心智模型自洽，反而比一个三十kB却缠满context provider的React应用更容易一眼看穿。所以"小"不等于"可读"，Rich Hickey讲过的simple和easy是两回事，Brooks说的conceptual integrity也不是靠行数堆出来的。
再说"信任底座"那句。许可证和可理解性其实不是替代关系——许可证回答"我合法不合法"，可理解性回答"我办得到办不到"，两者叠在一起才是底座。而且光读得懂还不够，fork得动、有人持续维护，那又是另一层的组织问题。一个精巧但没人管的小项目，照样会静悄悄地死掉。
严格来说你们说的能一晚上通读的项目，我好奇大家手里的底线是多少行？我印象里lua、suckless那几个工具、还有tcc这类，体量都还客气，但"一晚上"对熟手和新人完全是两个尺度。
顺着你最后那个求推荐，我前阵子翻过 OpenBSD 的 doas，就是想替掉 sudo 那套的小工具，核心逻辑几千行，一个周末真能读顺。这种"小而可审"的东西现在确实金贵。
不过有一点想跟你掰扯，en fait，你说开源信任的底座"从来不是许可证那张纸"，这个我倒觉得值得商榷。许可证和"看得懂改得了"不是两码事。代码再清楚，要是没有 copyleft 或者宽松许可证把"你能改、能再分发"写死，读完改完也白搭——大厂随时能拿专利或条款压你。许可证保的是权利，可读性保的是能力，底座是这两层叠起来的；少掉法律那张纸，光靠读得懂其实扛不住。
再说"一晚上通读"这个标尺，我私心觉得有点浪漫。真接手一个项目，光读代码不够，还得摸清它的约定、历史包袱，还有那些"当时为什么这么写"。可读性降的是门槛，但接管成本从来不全压在行数上。
你那个 64kB 拿来量"能不能读"挺准，量"值不值得信任"就单薄些。你后来去翻 doas 了没？
其实你那个"信任底座不是许可证那张纸，是看得懂改得了"的判断我挺认同。不过在"多大算读得懂"这件事上，后面那句"百万行起步"我有点想较真。
前阵子我翻过一个做静态站点生成的小工具，核心四千来行、目录就三层，但我卡在它那个依赖关系图上耗了大半天——不是因为大，是因为它把配置、插件和渲染管线全塞进一个命名空间里搅成一锅。反过来看，我见过一个二十多万行的数据库引擎，模块边界切得干净，只读它查询优化那一块，一晚上确实能摸到门道。严格来说
所以"看得懂"和字节数真不是简单的单调关系。64kB 当然舒服，但 64kB 的意大利面条照样能让人半夜砸键盘；两百万行但分层清楚、注释到位、还留了能独立跑的最小子集，新人未必真要两周。你那个"两周捋目录"的结论，落到不同项目上方差大得离谱，关键看它有没有把可理解性当一等公民来设计，光看总量会出偏差。
"膨胀的开源退回黑箱"这个比喻我接一半。黑箱的本义是进不去、改不了，可很多大项目你现在依然能 clone、能 debug、能提 PR，只是门槛高了——门槛高和锁死是两回事。真该警惕的是那些把构建流程和依赖分发捏在少数人手里、社区根本碰不到刀把子的项目，那才接近黑箱，跟行数关系不大。
想问一句：你心里"读得懂"的判据到底是什么？能改个 bug，还是能从头重写一遍？这俩难度差着一个数量级。
我年轻时用的那些机器，一张软盘塞得下整个系统，随盘带的手册能从头翻到尾。怎么说呢那种一页纸说清一件事的做派，如今少见咯。
不过这事我想换个说法：代码能不能一晚上读通，不全在行数。前阵子随手翻过一个老项目，作者写得啰嗦，比现在某些"优雅"的精简代码反倒好懂——他把弯路都摊给你看了。可读性一半在写的人肯不肯把话说透，一半在读的人还坐不坐得住。
现在手机刷惯了，对着屏幕超半小时手就痒，想切出去。这堵墙，未必全是别人砌的。
前两天我也犯了傻，想给一个挺出名的开源工具提个小补丁，下下来一看依赖图，光搞明白它怎么跑起来就耗了三个晚上，最后默默关了标签页。所以你说那道墙是真的砌起来了，不是吓唬人，新人光是站到门口就已经很累了。
顺着你那个"一晚上通读"的标准，我手里还真有一个能推荐的：suckless 的 st，那个终端模拟器，核心就两千来行，注释也干净，周末下午泡杯茶就能从头捋到尾。它不是最厉害的终端，但改起来真不 intimidation，想加个功能随手就动了，这种"普通人接得管"的感觉和你说的特别对得上。
不过我有点不一样的小感受——有时候读得懂不光是代码小，是作者愿不愿意把门开着。有些项目体量不大，但满屏宏和位运算，照样把人挡在外面。所以我倒觉得，比起行数多少，更该看重的是作者有没有替读它的人着想的那份心。
你们要是还知道这类"门开着"的小东西，也求安利，我存着慢慢翻 (´▽`)