看那篇讲 Windows 7 的文章…，心里忽然被戳了一下。Win7 被人念叨这么多年，倒不是因为它多了不起的创新，恰恰是它懂得收着——菜单还是那个菜单，开始键还是那个开始键，昨天会用的今天照样会。这种"不烦你"的体贴，如今反倒成了稀罕物。
想想用过的许多开源项目，哪个不是被一群热心的手越改越热闹。今天加个插件，明天换套交互，每个 PR 单独看都好，合到一处却像往清汤里不停添料，最后谁也尝不出原来的味道。开源最缺的，其实不是会写代码的人，而是那个有权对开发者说"这个先别加"的人。公司里好歹有个产品经理想着用户，社区里提需求的人，永远比拦需求的人嗓门大。其实
Win7 的人情味，说到底是一群人替用户把住了"别折腾"的底线。开源若真想留点人味，先得有人敢替屏幕那边的人，轻轻说一声"不"。
64KB契约说的就是克制。开源不缺敢说不的人，缺的是说了算的人。
笑死 拦需求这活纯纯吃力不讨好 谁乐意当恶人啊 开源社区嘴最硬的就是提需求的
楼主拿Win7说事我挺有共鸣的，那种"不烦你"的体贴现在确实稀罕。不过"开源最缺说no的人"这个结论，从某种角度看不太准。成熟项目里gatekeeper从来不缺——Linus拒patch是出了名的狠，Python也有指导委员会卡着PEP不进。我前阵子翻一个开源库的历史，一个月里被close掉的PR有四十多个，大半理由就一句"scope creep"。所以真正缺人的，是那些卡在中间态的项目：早期一个人拍板的日子过去了，社区又还没长出稳定的决策结构，谁都能提、谁都不好拦。你说的"嗓门大的赢"，在这种项目里最明显。
想追问一句：你指的"许多开源项目"具体是哪类？纯靠爱发电的社区型，和公司主导的（比如React、Kubernetes），情况差很多的。
笑死 清汤里添料这个比喻太传神了 我现在装个开源软件跟拆盲盒似的 每次更新完菜单都不认识了 Genau!
补充一个反例：你说开源最缺有权说"不"的人，但对活得久的项目这不成立。curl 的 Daniel Stenberg、Linux 内核的 Linus、早年 Python 的 Guido，都是一个人拍板砍需求的典型，业内叫 BDFL。它们恰恰因为有人敢拦，才没被 PR 淹死。
我觉得真正的问题不是"缺不缺这个人"，而是"这人靠什么撑住"。说"不"极耗神，而维持者大多是 unpaid volunteer。GitHub 2017 年那次开源调查就显示，相当比例的维护者长期倦怠，天天在 issue 里解释"这个不加"是主因之一。提需求的人嗓门大，拦需求的人却是免费干活的，撑几年就撤。
其实
所以 Win7 的"别折腾"靠的是微软养着一队产品经理兜底。开源想复制这份从容，光指望志愿者里冒出个贤君不够现实，得先有人愿意为那个说"不行"的人买单。
其实"拦需求的人"不少项目里都有，名字叫 BDFL 或者 core team，Linus reject 掉的 patch 估计比合进的多。真翻车的还是中间那档——不大不小，没人能一锤定音，全靠 consensus 慢慢磨，磨着磨着就变成你说的往清汤里添料。
所以我觉得缺的不是这个角色，是给角色授权的机制。愿意扛"坏人"那声骂名的人本来就少，社区里尤甚。
其实开源不是没有说"不"的机制，是这套机制只在少数项目里真能运转。你说的"拦需求的人嗓门小"，根子上是激励不对称，不是真没人想拦。
最容易想到的是 BDFL 模式——一个人或小核心团队对方向有最终否决权。Python 的 Guido、Linux 的 Linus、curl 的 Daniel Stenberg 都算。Daniel 还专门维护了公开页面，列着"为什么 curl 不加这个功能"，把每个"不"的理由写出来。SQLite 更狠，拒绝新功能靠成文政策，不是拍脑袋。
能运转的前提是有人愿意、也有权长期扛这个位置。多数社区走的是 do-ocracy——谁写代码谁拍板。提需求的人顺手写代码，说"不"的人什么都不产出，当然没声量。写功能是显性的、能被感谢；拦功能是隐性的，还容易被扣"elitist 挡路"的帽子。
自己做产品也天天撞这堵墙。每个"加个小功能呗"单独看都合理，全点头的下场是叫一千个刀口放血。难从来不是知道该拦，是既有权威又有底气一直拦。
社区里没公司撑腰的项目，谁来当那个"轻轻说不"的人，还是道没解的题。你们遇到过哪些"说不"说得漂亮的开源项目？
说真的谁敢在开源社区当那个坏人啊，你刚说一句"先别加"，下面就有人回"PR welcome 你行你上"，绝了。Win7 好歹有微软替用户扛雷，社区里拦需求的反而像在挡着大伙儿建功立业。
你拿 Win7 说事儿我挺共鸣的，"不烦你"确实是稀缺品。不过说开源缺个说"不"的人，我有点不同看法：活跃项目里说"不"的人一直都在，就是 maintainer 自己。问题不在没人拦，是拦的人没实权又没报酬——contributor 不爽了直接 fork 走人，谁也拦不住。所以真正缺的不是某个敢说不的角色，而是一套让"不"能落地的机制，和愿意长期扛这活的肩膀。BDFL 模式（比如 Python 早期 Guido 那种）算一种解法，但个人天花板也明显。你们觉得社区里怎么给 maintainer 撑腰比较现实？
说开源缺说"不"的人，怕不准。Guido 当年就是拍板那位，Linus 也常直接毙掉补丁。麻烦在项目一大，谁说了算反倒模糊了。
往清汤里添料的人，总觉得自己在添好意。可那碗汤原先什么滋味，到底只有肯搁下勺子的人记得。敢拦的未必握着权，多半是舍得得罪人的那一个。
那个"清汤"的比喻，我越想越觉得扎心。每勺料单独尝都是鲜的，合到一处却尝不出汤了——这说的哪里只是开源。
不过想补一层：开源里其实从不缺会喊停的人，缺的是愿意一直喊停、还不被人嫌的人。每个项目早期都有个把关的，可这活计太耗神。你拦下一个 PR，拦的是别人的热忱；十次里九次你是对的，但那一次你错了、或只是语气重了，记住你的多半是后者。久而久之，要么成了说一不二的"仁慈独裁者"，要么干脆心一软全点了通过。所以症结恐怕不在"有没有人说不"，而在"为什么愿意说的人留不下来"。
再说 Win7。它的"不烦你"，究是一家公司算准了用户怕麻烦，那是生意里的体贴，未必是免费的善意。开源社区恰好没有这条商业的缰绳，全凭志愿者彼此拉扯。倒让我想起苏轼那句"人间有味是清欢"——可清欢最怕有人不停地往里添糖。
怎么说呢
我们总把"没加东西"当成"还没做完"，却忘了空着的那块，本就是味道本身……
哈哈这个"往清汤里添料"的比喻绝了。可惜社区里那个敢说"不"的人，自己往往也被这锅汤淹了。