开源项目吐槽大会：一万字深度复盘，我亲历的那些“破防“瞬间
引言：为什么我们需要"吐槽大会"？
2023 年秋天的一个深夜，我在 GitHub 上第 N 次刷到一个熟悉的 Issues 讨论串——某个知名开源项目的用户正在愤怒地抱怨文档"完全没法用"，而维护者则在底下冷冷地回复了一句：“Read the fucking source code.”
这条回复获得了 47 个点赞。
我不是在讲段子。这是真实发生的事情，而且每天都在上演。维护者觉得受了委屈——你们白嫖代码还这么多事；用户觉得受到侮辱——文档是你项目的一部分，写得烂还不让人说。
然后双方都觉得自己赢了，但所有人都输了。
我在开源社区待了六年，前三年是狂热的贡献者，后三年是一个小项目的维护者。这两个身份让我见识到了开源生态最荒诞又最真实的一面：一群全世界最聪明的人，用着最先进的技术工具，却困在最原始的沟通方式里。
我们每天都在用 PR、Issue、Code Review 这些工具，但这些工具的设计初衷是管理代码，不是管理人的预期和情绪。当代码问题变成人的问题，当技术分歧升级为情绪对抗，这些工具就彻底失效了。
"吐槽大会"这个概念，是我在组织一次社区会议时偶然想到的。那天我们本打算正经地讨论下个版本的 Roadmap，结果聊着聊着，大家开始疯狂抱怨某个模块的设计。起初我很紧张，试图拉回正题，但突然意识到——这才是他们真正想说的东西。
于是我说：“好啊，那今天不聊 Roadmap 了，你们把所有的槽点都倒出来，我不还嘴，只记录。”
那天晚上我们聊了四个小时，产出了一份 30 多条待办事项的清单。三个月后，那个一直被诟病的模块完成了一次漂亮的重构，没有人预想的"分家"（Fork）没有发生。
从那天起，我开始系统性地思考：在开源社区里，槽点到底在说什么？我们能不能有更好的方式面对它？
这篇文章是我六年开源生涯的完整复盘。我会告诉你槽点从哪里来、怎么分类、怎么收集、怎么处理，以及怎么把一场"吐槽大会"变成项目真正的转折点。所有的案例都来自我自己的亲身经历、我朋友的项目，或者我亲眼目睹的开源圈真实事件（涉及的人名和项目名会做匿名处理）。
第一部分：槽点的四种面孔
在具体讨论"怎么办"之前，我们需要先搞清楚一个问题：开源项目的槽点，到底在槽什么？
大多数维护者把用户的反馈当成"Bug 报告"来处理——你告诉我问题在哪，我来修。但真正的槽点往往不是一个 Bug，而是一个信号。这个信号不一定指向某个具体的技术问题，而更多是在表达一种期待与现实的落差。
根据我个人的经验，以及我跟十几位开源维护者聊下来的感受，槽点大致可以分为四类。每一类背后，都对应着开源项目的一种典型"病根"。
1.1 文档与入门体验：第一道拦路虎
把一个人从一个门外汉变成贡献者的那道门槛，主要是文档。但我必须说一句容易被骂的话：大多数开源项目的文档，其实是给作者自己看的。
我有过一次非常具体的经历。2021 年我在研究某个 Golang 的微服务框架，它的 GitHub Star 有一万多，社区很活跃。我点开 README，开头是：“本项目严格遵循 Clean Architecture 设计哲学，采用 CQRS 模式实现命令与查询分离……”
我读了三遍，依然不知道第一步该怎么跑起来。
最后还是在一个 2019 年的 Issue 里，有人贴了一段完整的 docker-compose 配置，我才成功把 demo 跑通。而那段配置，在官方文档里的描述就一句话：“推荐使用容器化部署。”
这不是个例。你去翻任何超过两年的开源项目的 Issues 区，一定会看到一种重复率极高的帖子：
“按照 Getting Started 的步骤执行到第三步报错，是不是漏了什么依赖？”
然后下面可能有两三种回答，分别是不同版本的用户自己摸索出来的"补丁式方案"。
文档的问题往往不是写的人不用心——恰恰相反，很多维护者在文档上倾注了巨大的精力。问题在于，维护者已经丧失了对"不知道"的记忆。当你对某个项目的代码和架构了如指掌时，你很难想象一个完全不熟悉的人会卡在哪里。这就是知识的诅咒。
除此之外，还有一种更隐蔽的问题：文档只写了"怎么做"，没写"为什么这么做"。开发者看了文档知道怎么调用 API，但完全不懂背后的设计意图。一旦遇到边界情况，文档就成了一堆废纸。
1.2 代码质量与架构：历史的"包袱"不是谁都能继承
我在 2022 年接手过一个项目——一个 Python 的后端框架，原来的维护者因为结婚生娃退出了开源。翻开代码的那一刻，我大脑空白了大概十秒钟。
主模块的入口文件大约 3000 行，名字叫core.py。
里面混杂了路由定义、数据库连接、缓存逻辑、以及一个自定义的日志工具类。更让我抓狂的是，在一个处理 HTTP 请求的函数里，我发现了一句注释：
# TODO: 这里不知道为什么能跑，但就是能跑，先别动ifresponse.status_code!=200:time.sleep(2)returnself._retry(request)这就是开源圈里著名的"祖传代码"。它的存在不是因为有用，而是因为没人敢删。原来的作者可能已经不在了，逻辑为什么这样写也没人说得清。你删掉它，一切正常的那个下午，比一切崩溃的下午更让你害怕。
代码质量的问题通常不是一个简单的"写得不好"的问题，而是一系列历史决策叠加出的结构性问题：
"魔法数字"和硬编码：当年为了快速上线，把配置直接写死在代码里。后来配置越来越多，但没人有勇气做一次彻底的提取。每个
if status == 3背后，"3"到底代表什么，只能靠猜。模块耦合成一团乱麻：A 调 B，B 调 C，C 又反过来用 A 的一个工具函数。你改一个模块，三个模块的测试一起挂。不是你的代码写错了，而是整个架构已经像意大利面一样纠缠在一起，牵一发而动全身。
测试覆盖率是假象：很多项目把"测试覆盖率 85%“写在 README 上，看起来很唬人。但你点进去看就会发现，这 85% 覆盖的全是"快乐路径”——正常流程跑通了就算通过。边界条件、异常处理、并发场景，完全没有测到。这种数据是给自己看的安慰剂，对代码质量没有任何实际意义。
有一次我在重构一段代码时，发现它的test_success用例覆盖了 80% 的代码行，但只测了一个正常输入就 assert 了response.status == 200。而真正的危险——用户传入了空字符串、传入了超长参数、传入了一个 JSON 格式错误的请求体——这些场景一个都没测。
这就是"测试覆盖率"的另一个谎言：行覆盖率不代表场景覆盖率，更不代表质量。
图 1：技术债的滚雪球效应——每绕一次路，下一次的阻力就更大。
1.3 社区与协作流程：贡献者的心是被冷暴力杀死的
压倒开源项目贡献者的，往往不是什么技术难题，而是沉默。
我认识一个朋友，某天兴致勃勃地给一个明星项目提了个 PR。他花了两天时间研究代码、写测试、写文档。提交之后，五天后项目 bot 自动发了一条：“Please make sure you have signed the Contributor License Agreement.”
他立刻签了，然后又等。
两周后，一个 Reviewer 出现了，留下了一条评论："Some nits."然后指了三处空格问题。
他改完重新 push。然后又没了。
一个月后，他发现自己的 PR 被人悄悄关闭了，没有任何解释。
"我后来明白，那个 Reviewer 根本就没打算合我的改动，"他后来跟我说，“他只是在走流程——让你觉得有人在看，但其实发完之后就忘了。”
静默的拒绝是开源的冷暴力。它比直接说"我们不需要这个"更伤人心，因为它连基本的分歧都懒得发生。
除了响应迟缓，还有一个更常见的问题：非技术环节的劝退机制。
有些项目的 Issue 模板长达两千字，要求你填写"系统版本"、“依赖版本”、“复现步骤”、“预期行为”、“实际行为”、“日志文件”、“截图”、“是否尝试最新版本”……我理解模板的意义——筛选低质量反馈。但当新人只是想说一句"这个页面的链接好像打不开"时，面对这套模板会直接关掉页面。
更糟糕的是，很多项目的CONTRIBUTING.md写得像一份法律合规文件，而不是对新贡献者的欢迎信。开头不是"欢迎！如何上手"，而是直接列出"违反本规范的 PR 将被直接关闭。"
新人读了之后，本能反应不是"我想参与"，而是"这个项目是不是不想让我参与？"
此外，Code Review 的随意性也是一个隐性问题。有的项目维护者 Review 代码时全凭心情——心情好了，连注释拼写错误都懒得提；心情不好，一个变量的命名风格都会成为拒绝的理由。而且标准从不公开。今天纠结于缩进，明天轻描淡写地放过了一个可能导致性能瓶颈的循环写法。
不是维护者有恶意，但标准的不可预期感让贡献者极度内耗。
1.4 发布节奏与维护路线：没有人想当你的免费 QA
你经历过大版本升级把生产环境搞崩的事吗？我经历过。
那是一个用了两年多的后端框架，一直是 2.x。某天 GitHub 弹了个通知："v3.0.0 Released."我点进去，几十条 commit，两行 Changelog：“Major refactoring, improved performance.”
我第一反应是：干得漂亮！更新到下一行。但是五分钟之后——“所有依赖这个框架的旧 API 是不是都废了？”
然后就是一整个上午的地狱时间。迁移指南（Migration Guide）只有两段，解释了两层核心抽象变化的"设计理念"，但对于我关心的哪些具体函数名变了、参数顺序改了、返回值类型从 dict 变成 class 了完全没有交代。
我一个文件一个文件地 grep 报错，手写了 200 多行迁移代码。
这种事每个做后端的工程师都经历过至少一次。破坏性更新不是原罪——重构是开源的命脉。罪在于通知不充分，迁移路径不清晰。用户不是你的测试团队，更不是你的免费 QA。
| 槽点类型 | 用户的第一感受 | 对维护者的反噬 | 典型信号 |
|---|---|---|---|
| 文档与入门 | “这东西到底怎么用？” | 用户流失，论坛被同类问题刷屏 | Issue 区重复提问率高 |
| 代码质量 | “为什么改一个小功能要动这么多地方？” | 贡献者不敢深入，PR 质量下降 | 重构 PR 长期无人敢 Review |
| 社区协作 | “他们是不是对我的反馈有意见？” | 核心贡献者冷走，社区活跃度下降 | PR 合并时间中位数持续上升 |
| 发布与维护 | “我的系统第二天就跑不起来了” | 用户信任崩塌，Fork 事件风险增加 | 旧版本回退请求激增 |
表格 1：四类槽点的用户感知与维护者反噬
这四类槽点，每一类单独看似乎都不足以毁灭一个项目。但它们会相互关联、层层叠加。文档烂 → 用户入门失败 → 好用户流向竞品 → 留下的人大多带着情绪 → 社区氛围变差 → 贡献者出走 → 维护压力集中到一两个人身上 → 他们开始倦怠 → 文档更没有人维护。
这就是开源项目常见的死亡螺旋。
第二部分：吐槽大会的完整操作手册
现在你了解了槽点从哪里来，接下来就需要一套方法论来系统性应对——这就是"吐槽大会"。
我之前参加过各种"社区会议"、“开发者大会”、“线上 AMA”，但直到自己主导组织了五六次之后，才真正体会到什么有效、什么没用。以下是踩完所有坑之后的实操总结。
2.1 会前准备：安全感的建构比什么都重要
让用户开口吐槽比你想象中难得多。因为在很多人的潜意识里，提意见 = 批评维护者 = 恩将仇报。中国人尤其有这种心理负担——人家免费做的东西，我怎么好意思说不好。
所以第一步不是发公告，而是消除道德负担。活动公告必须明确表达三层意思：
- 吐槽不是抱怨——具体描述问题 + 提供改进方向才是我们需要的
- 吐槽是贡献——发现问题比写代码更需要敏锐度，我们珍惜这种贡献
- 对事不对人——任何设计决策都有历史语境，批评的是"当前状态"，不是某个人
我把这段话写在了活动公告的第一屏。后来反馈给了我惊喜——很多人看了这句话才敢来。有个用户私下跟我说：“本来不好意思开口的，但是看到你们说’吐槽是贡献’，我整理了一整天，写了一份十几页的文档发过去。”
平台选择也很关键。前两次我用了 Zoom 线上会议，效果极差。因为实时语音环境下，人的发言压力很大，而且讨论容易被少数"社牛"主导。话题一岔开，录音也找不回来。
后来改用双轨制：会前用匿名 Google Form 收"冷反馈"，会上同步开一个 Discord 频道做文字讨论。文字讨论的好处是消歧成本低、有据可查、可以回溯。
一位经验丰富的社区经理教过我一个技巧：“永远不要让用户当着所有人的面说一件他想了很久的事。给他一个提前写下来的机会。”
2.2 反馈收集：结构化模板不是为了刁难你
模板的争议我自己经历过——有用户反馈说"你们那个槽点模板太长了，像在考试。"
所以我后来改成了一个极简版本：
【槽点模板】（任何一个格子不想填可以留空） 问题发生时我在做什么： 我期望的结果是什么： 实际发生了什么： 如果让我提一个改进方向，我想说：这个模板的核心原则是“尽量还原场景，而不是给结论”。因为用户直接说"XXX 模块太烂了"是一个无效信息；但他说"我当时想配置 YAML 的多环境参数，文档里只写了 JSON 的写法，我试了一个下午没搞出来"——这是一个具体的、可以被解决问题的。
有一个现象我在第三次组织吐槽大会时才恍然大悟：匿名反馈的质量普遍高于实名。实名反馈比较礼貌，但指向模糊；匿名反馈更直接，但也更容易带着情绪。我的建议是：匿名收集、实名讨论——用匿名渠道鼓励真实表达，但在公开讨论中引导建设性的方向。
而收集到的反馈需要在开会前做一次预归类：把相似的问题合并，给每条标记优先级（紧急/重要/可延后），然后在会议议程里把讨论时间优先分配给"高频"问题——不是维护者觉得重要的，而是大家提得最多的。
2.3 大会现场：闭嘴是维护者最强大的技能之一
这是最难执行的一条——维护者在会上闭嘴听。
第一次组织吐槽大会时我也没忍住。当有人用比较尖锐的方式批评一个功能时，我本能地想解释为什么这么设计。我刚开口说了两句，气氛就变了——参与者开始"收回"他们的批评，语气从坦诚变成了"其实也不是很大的问题"。
后来复盘时我发现了一个规律：每次我一解释，就有一到两个人停止发言。他们不是被说服了，而是觉得"维护者不想听"。
第二场的时候，我硬是按住了自己所有的解释冲动。全场三个半小时，我只说话不超过十次，每次都是复述确认，而不是反驳。复述确认的意思是：“我确认一下，你的意思是当 X 发生时，你期望的是 A，但实际看到的是 B，对吗？”——听起来像客服话术，但在一个吐槽的场景里，这句话传递的含义是：你在被听到。
除此之外，主持人的一个关键职责是把对话从过去式引导到将来时段。当某个话题开始反复讨论"之前改得太慢了"、“怎么那么慢”，我会直接打断：“这个时间点我们已经不能回去了。我关心的是下个版本我们能不能让这个流程变快，现在有什么建议？”
这不是回避责任，而是避免会议变成争吵。吐槽大会的黄金法则是：讨论问题的时间不要超过两次抱怨所需的时间。一过这个阈值，场景就从"诊断"滑向"宣泄"。
随附一个完整的操作流程图，供参考：
图 2：吐槽大会的全流程操作。会前决定了你听到的东西有多真实，会后决定了它会不会变成空谈。
2.4 会后怎么落地：看板是社区信任感的充要条件
吐槽大会开完之后，如果只是产出一份会议纪要然后不了了之，那比不开更糟糕——它会让所有参与者确认一件事：“说了也没用。”
我们当时采取的是一套极度透明的方式：
把所有待办项丢到一个公开看板上——GitHub Project 或 Trello 都可以，每一列代表一个状态（待处理、进行中、已完成、暂缓）。每张卡片上有负责人和截止时间。
优先拆解高频问题为具体的 Issue。一个"文档太烂了"的槽点，拆出来的可能是：“重写 Getting Started”（P0）、“补充配置文件示例仓库”（P1）、“为 API 文档添加可运行片段”（P1）。每个任务独立追踪。
对"不好改"的槽点，公开说清楚为什么。有时候一个槽点指向的是架构层面的问题，短期真的改不了。那就明确公开当前工作量、为什么延后、以及何时重议。坦白是最便宜的信任积累方式。
反馈闭环。下一次社区月度会上，我们专门设了一个"上期吐槽大会追踪"十分钟环节，把看板上状态变动的卡片快速过一遍。
这套流程走了两次之后，社区里有一种微妙的变化：大家开始把看板当成一种"契约"。有人会主动在卡片下面留言：“这个我来搞。”“这个有没有我能帮上忙的？”
他们之前不这么做，是因为他们不确定自己做的事会不会被接受。看板的公开可视性，给出了确信。
第三部分：我看到的真实故事（好的、坏的，以及一个正在发生的）
理论说完了，我想讲三个真实的故事。它们来自我自己和我朋友的项目，为了隐私，人名和项目名均做了替换。但事情本身完全是真的——每一个细节我都记得。
3.1 成功案例：当五个核心开发者终于开始聊"为什么我们发展这么慢"
2022 年，有一个由八个 Go 开发者维护的中间件项目，在社区增长上停滞了将近半年。Star 数量持续，但活跃贡献者的数量在减少——老开发者逐渐沉默，新 PR 进来没有人 Review。
项目创始人袁工是个技术能力极强但极不爱说话的工程师。社区成员曾在 Discord 上委婉表达过"项目方向不明"，袁工的回应是：“方向在代码里。”
这句话让社区讨论整整沉默了三天。
契机来自于一个外部事件——他们的一位早期用户，开始频繁在 GitHub Issues 上提出各种反馈，越来越多，语气也越来越直接。其他一些用户开始"站队"——有人支持这位用户，觉得他说得都对；有人认为他"态度太差"。
后来一位中立的社区成员私信袁工，建议办一次吐槽大会。袁工犹豫很久之后同意了，但提出了一个要求——他自己不参与，因为他觉得"自己忍住了还好，没忍住会坏掉全场。"
大会当天，另一位维护者代替主持，袁工静音旁听。那天晚上用户确实很猛：“你们的配置方式我每次都要重翻文档。”“我翻了半天源码才知道怎么自定义返回格式。”
旁听的袁工一个字没说。
会后的改变是我见过的最快、也最彻底的：他们新建了一个"用户体验讨论频道"，把之前零散的反馈集中管理；把文档站点从老式的 Wiki 迁移到了 Docusaurus，并引入社区成员负责校对；还将"自定义返回格式"拆解成了六个小 Issue，带上了标签good-first-issue，不到十天全部被社区认领。
三个月后，项目的新 PR 周均数量翻了一倍。更关键的是，社区里出现了一种之前没有的东西——分歧后的信任。人们发现维护者是真的能接住批评的。
3.2 失败案例：防御是软件工程的本能，但这本能会毁掉一切
另一个故事更加现实。有一个 Rust 的工具库，维护者李工特别能写代码——一个人维护了 80% 以上的 commit。但与此同时，他也是一个对批评极度敏感的人。
问题在一次讨论中爆发。用户在 Issue 里详细描述了某个 API 的不便之处，写了一大段用例场景。李工用两句话回了：“这个设计是故意的，你的场景不是主流。”
用户感到被冒犯——不是因为被否决，而是因为他花了时间和精力写下来的东西，被一句"不是主流"否定了全部价值。他删除了原 Issue，另发了一个"Are you interested in listening to the users at all?"，然后退出仓库。
更糟糕的连锁反应在后面。对话截图被传到了 Reddit 和几个 Rust 社区群。一些原本观望的潜在贡献者发帖表示"这个项目不考虑社区反馈，不值得投入。"另外两位正在提交 PR 的外部开发者也在这之后的几周内逐步退出。
项目在接下来的半年几乎没有新增外部贡献。Fork 这件事没有发生——因为这个项目太强绑定个人了，根本没法 fork。但项目活跃度统计里的那条下降曲线，和事件发生的时间点完美对应。
我反复问自己一件事：如果当时回复那句"你的场景不是主流"的，是一个更有沟通经验的维护者，他会怎么回？
我朋友的回答让我记到现在：“他会说，兄弟我懂你这个场景，我现在手边有点忙，但能不能先留在这里，我过两周详细看一下——然后真的去看。”
能不能接住批评，只在一个细微的动作：在展示自己的正确和承认别人的感受之间，你选哪边。
3.3 正在进行时：一个用吐槽大会自救的 AI 开源项目
2024 年，我以观察者兼用户代表的身份，旁观了第三个案例——一个快速增长的 AI 训练工具库。
这个项目的最大问题是"速度太快，烂得也太快"：发布速度极快（两周一个版本），但每个版本都带一堆新的 Bug，而且 Breaking Changes 从不提前通知。到第三个月时，Discord 上形成了一个"版本劝退党"——专门劝新用户"等稳定了再来"。
那次吐槽大会是他们一位运营同学硬推着办的。我看了他们的议程设定，印象很深——议程上每件要讨论的事，都对应一个精确的版本号和一个特定函数。比如：“v0.20.0 中 DataLoader 的线程控制参数，在 64 核机器上行为异常。”
会议前半段，维护团队几乎全程沉默记录。到后半段，有一个资深工程师接过了话头，说了一句让我印象很深的话：“我们这半年的发布节奏确实有问题，我是那个做决策的人，我来说一下为什么会这样——不是为了辩护，是为了让各位知道约束在哪里，我们一起讨论怎么调。”
这句话的魔力在于一个词——“约束”。他没有说"这是对的"，而是说"这是当时我们能做的选择范围"。这句话把讨论从"谁对谁错"拉回到了"现在可以怎么办"。
当天晚上他们产出了一整套新的发布流程方案：v.x.0-pre先行版、破坏性更新在 Changelog 加粗警告行、引入社区 bug triage 轮值机制。
到目前为止，我还在观察这个项目的后续进展，但我至少确认了一件事——吐槽大会这件事，它不是一个固定的会议形式，它是一种"我要听到真实问题"的态度。
第四部分：给维护者的五个生存法则
在经历以上种种之后，我想从维护者视角说一些掏心窝的话。可能有些不好听，但都是我自己撞过墙之后才相信的。
法则一：不要把用户的吐槽当成对你的质疑
这个认知转变对我来说是颠覆性的。
当一个用户在你项目上花了时间，结果踩到了坑，他的第一情绪一定是 frustration。这个 frustration 看起来是对你的，但他的真实诉求是——想把这个东西用起来。
把框架拉出来看，用户吐槽你的项目，说明你的项目有人在乎，用户愿意花时间去尝试。——你的项目对这个陌生人来说，曾经意味着一种可能性，只是后来落了空。
这个视角能帮你剥离情绪。
法则二：把你"想解释"的内容放到"了解具体情况"之后
工程师的职业病就是：别人刚说了半句，你已经想好怎么解释全貌了。
但吐槽不是技术讨论。吐槽的底层诉求是"被理解"，不是"被纠正"。确认对方遇到的问题比解释你的设计意图重要得多。
所以我后来给自己定了一条很具体的规则：接到一个尖锐的反馈时，回复的第一句话永远是确认，而不是解释。
“你的意思是，当你在 X 场景下调用 Y 时，文档让你按 A 走，但实际上 B 才是对的，所以你被困住了——是这样吗？”
这句话平均减少 70% 的后续情绪强度。剩下的 30% 是真正值得讨论的技术问题。
法则三：公开 = 信任，不是暴露缺陷
我看到的一种常见维护者心态是，怕"把问题暴露出来会影响项目形象"。
但事实是，你以为的"遮"，用户早就看见了。发一个"我们打算用一周修，但人手不够，邀请帮忙"的帖子，得到的回应远好过"我们不需要修"。
法则四：区分"做不了"和"暂时不做"
很多时候维护者的本能是拒绝——但这个拒绝从用户耳朵里听到的是"不在乎"。"这个做不了，因为我们架构上无法支持"和"我们大概率可以，但我需要到 Q2 才能排进去，你愿意等我到时候更新吗？"是完全不同的两句话。
法则五：建立常态化反馈闭环，而不是把吐槽累积到一次
把压力积攒到半年一次的吐槽大会，不如在日常把一些小的、可微调的反馈渠道打通。允许用户在文档站点看到最新改进计划并签名参与；每季度发一次"我们还欠的债"的简短公开贴。
这五个法则，本质上都指向同一件事：把用户的吐槽作为项目改进的驱动，而不是阻挡。
结语：感谢那个敢于指出你项目问题的人
写到这里，我想回扣开头的那句话：吐槽是另一种形式的爱。
这不是鸡汤，这是体验。每个愿意花时间去想、去写、甚至去骂你项目的人，都说明你的产品曾在某个瞬间对他产生了真实的吸引力。他期望它更好，所以发声。
在开源的世界里，最大的冷漠不是被骂，而是被遗忘。有人指出你项目的 bug，说明你的项目有价值；有人愿意定期"吐槽"，说明你的社区还活着。
结尾我想讲一个小世界里的真实时刻。有一次一个早期社区用户给我们写了满满三大段的改进建议，我晚上加班一一看完，当场标注了一条 GitHub Issue。
第二天早上我发现他给我发了条私信：
“谢谢你昨晚看完了，我看到你把我的反馈加进了 Issue。这个项目我从第一版本就在用，它的底层设计我很欣赏，就是一些小地方一直让我膈应得难受。我说了以后，你不觉得冒犯，是真的在听。我以后有什么想法都会先说给你的。”
我看到这条消息的时候，比看到 Star 数突破 10000 还高兴。
所以，如果你在维护一个开源项目，请勇敢地去问：你最不满意的三个地方是什么？
然后闭嘴听完。
你会得到比 PR 更有价值的东西。那是一个社群对一件作品，最真实的爱。