《Peopleware（第二版）》精读：团队与工作环境研究 × 开源协作课题原则提炼 未开始

题记与说明

0. 检索与精读过程（如实记录）

本次在有网络环境下完成，实际执行过程：

1. WebSearch 两轮检索 Peopleware 关键词（"Coding War Games" / "jelled team"），定位到或ion2020.org 托管的 Peopleware 第二版全书 PDF（352 万字节、261 页）与 Pearson 第三版样章 PDF。
2. curl 下载两份 PDF + MIT OCW 的 Lakhani & Wolf 论文 PDF，用 python -I + pypdf 提取全文文本（脚本与下载数据分目录存放）。
3. catb.org 存在 TLS 证书备用名不匹配（ERR_TLS_CERT_ALTNAME_INVALID），WebFetch 失败；改用 curl -k 抓取《The Cathedral and the Bazaar》全部 11 个分节 HTML，python -I 去标签提取全文（77 KB）后精读。
4. 第 5 个候选来源 Bernstein & Turban (2018)《The impact of the 'open' workspace on human collaboration》尝试了 3 条途径均未读成：Royal Society 官网 WebFetch 返回 HTTP 403；猜测的 PMC 编号指向无关文章（已排除）；Crossref API 调用失败（返回非 JSON）。该来源因此未进入本笔记引证，按"未读成不引证"原则如实标注。
5. 最终精读深度：1 本专著全书 + 2 篇论文全文 + 1 篇长文全文，共 4 个来源，满足"3-5 个来源并精读"的要求。

注：原检索结果中二手摘要页（Runn、SuperSummary、Shortform 等）未作为引证依据，所有数据均回溯到一手文本核对。

1. 主源概览：Peopleware 在讲什么

*Peopleware*（2nd ed., 1999；1st ed. 1987）全书 34 章、六大部分：管理人力资源 / 办公环境 / 合适的人 / 培养高产出团队 / 在这里工作应该有乐趣 / Son of Peopleware。它不是一本"软件工程方法论"书，而是一本关于知识工作者的社会学的书。两位作者基于 1977 年起每年一次的公开生产力调查与 1984 年起的 Coding War Games 对照竞赛，主张软件项目的主要风险从来不在技术，而在人与环境。

全书三条主线：

1. 社会性论题：失败项目的首要原因不是技术（第 1 章）；
2. 环境论题：空间、噪音、打扰时间直接决定脑力劳动的产出（第 II 部）；
3. 团队形成（jelling）论题：团队是一种需要被保护、很容易被管理动作"杀死"的现象（第 IV、V 部，Teamicide）。

2. 七维提取

2.1 核心问题

为什么高薪团队仍然失败？ 具体拆成三个子问题：

• 软件组织的根本困难到底是技术的还是社会的？管理者该把时间花在哪里？
• 办公环境（安静、私密、空间、打扰）与生产力之间有没有可测量的关系？"省空间"的经济学账怎么算？
• "团队"到底指什么？什么样的管理行为让团队形成（jelling）成为可能，什么行为让它不可能？

精读后追加的课题映射问题：这些 1980-90 年代组织内部的经验，在"开源协作"这种没有老板、没有物理办公室、成员高度分散的组织形态里如何成立、如何变形？

2.2 主要主张

1. 社会性论题（全书中心论点）：

"The major problems of our work are not so much technological as sociological in nature."（第 1 章）

管理者普遍承认这一点，却普遍按技术问题来安排自己的时间——作者称之为"High-Tech Illusion"（高科技幻觉）。

1. 管理者职能观：管理的本质不是逼人干活，而是消除障碍：

"The manager's function is not to make people work, but to make it possible for people to work."（第 7 章末，Sharon 的故事）

1. 压力无效论：

"People under time pressure don't work better; they just work faster."（第 3 章）

1. 环境经济账：一名开发者的工作区成本只占其薪酬的 6%–16%，雇主每花 1 美元在空间上就要为这个人花约 15–20 美元在薪酬福利上（第 9 章）。因此压缩空间省小钱、赌上大钱的生产力是错误的成本收益分析。顶级绩效者的工作空间"更安静、更私密、更防打扰、更大"。

1. 流（flow）是脑力工作的基本工作单元：进入流需要 15 分钟以上沉浸，一次专注型打扰的代价是 5 分钟电话 + 15 分钟重入 = 20 分钟有效工时；一天十几次打扰就解释了"朝九晚五干不成事"（第 10 章）。

1. 团队形成（jell）：凝聚团队产出大于个人之和，且成功概率大增；但 jelling 极脆弱，作者用"反转法"列出了 Teamicide（团队谋杀）清单：防御式管理、官僚化、物理隔离、碎片化员工时间、降低产品质量、虚假截止日期、压制小圈子（第 20 章）。

1. 加班的反作用（第 27 章）：加班的正面被高估，代价（出错、倦怠、流失、"补偿性少干活"）几乎从不被计入，且对凝聚团队有额外的谋杀效应。

1. 社区（第 34 章）：现代人最好的社区机会就在职场，做出社区是管理者最伟大也最少被歌颂的工作。

2.3 方法

• 作者的方法论：
  • 长期观察 + 咨询轶事（1987 年初版即由 1977–1987 年参与其调查与战争游戏的专业开发者支撑）；
  • Coding War Games：1977 年起每年公开生产力调查，300+ 组织参与；1984–1986 年改造为对照竞赛——同一组织派出一对开发者，做完全相同的"设计-编码-测试"基准任务，带自己的语言/工具/终端，在自己工位、正常工作时间完成，记录时间日志，事后统一做验收测试。竞赛结果与参与者自评的环境变量做相关分析。这是该书最重要的准实验设计。
• 本条目的精读方法：一手全文提取 → 关键论点逐条回原文核对 → 引入三篇独立实证（开源动机、分布式协作速度）做横向校验，检验 Peopleware 结论在开源协作情境下的适用边界。

2.4 数据与证据

Coding War Games（第 8–9 章，核心证据链）

• 规模：1977 年起每年调查，300+ 组织；1984–1986 年 600+ 开发者、92 家公司参赛（p.43–44）。
• 个体生产力差异三条经验法则（p.45–46）：最好 vs 最差 ≈ 10:1；最好 vs 中位 ≈ 2.5×；好的一半比差的一半高 >2:1。薪酬、经验、语言选择与绩效几乎无相关。
• 环境差异（p.50）：前 25% 选手的工作空间比后 25% "更安静（quieter）、更私密（more private）、更防打扰、更大（there is more of it）"。
• 全样本环境自评（第 9 章 p.55）：58% 认为工位不够安静；61% 认为不够私密；54% 说家里的工作环境比公司好。
• 噪音-质量关联（p.55）：赛前自评"工作环境可接受地安静"的人，交付零缺陷作品的概率高三分之一；某 50 人参赛公司（噪音不可接受率高 22%）内部：零缺陷者中 66% 报噪音 OK，有缺陷者中仅 8% 报噪音 OK。作者明确说明这是主观自评 + 赛前采集，未做客观分贝测量（诚实局限）。
• 空间现状（p.54）：仅 16% 参赛者拥有 ≥100 平方英尺专属空间；仅 11% 在封闭办公室或高于 6 英尺隔断内工作。
• 空间经济学（pp.50–51）：工作区成本占薪酬 6%–16%；"每 1 美元空间对应 15–20 美元人力投入"（20:1 之比）意味着省空间是高风险动作。
• IBM Santa Teresa 反例（pp.52–53）：Gerald McCue 主持实测后确立最低标准——人均专属 100 sq ft、工作台面 30 sq ft、封闭办公室或 6 英尺隔断（最终约一半专业人员有封闭办公室），并真的照建了。
• 开放办公室浪潮的批判（p.53）："The only method we have ever seen used to confirm claims that the open plan improves productivity is proof by repeated assertion."（我们见过的唯一"证明"是反复断言。）

流与打扰（第 10 章，pp.62–64）

• 进入流需 15 分钟以上沉浸；一次 5 分钟电话的流时间代价是 20 分钟；书中贴出一张真实的 CWG 时间表：2:13–2:17 编码（电话）、2:20–2:23（老板来聊）、2:26–2:29（同事提问）、2:31–2:39（电话）、2:41–2:44（电话）——每次 3–4 分钟，全是碎片。
• 结论："You never get anything done around here between 9 and 5" 不是玩笑，是环境失败的可预测结果。

团队形成（第 18–20 章，pp.123–135）

• 凝聚团队四征兆（pp.127–128）：低流失、强身份认同（团队绰号、黑话、聚会地）、产品共同所有权、明显的乐趣感。
• "The purpose of a team is not goal attainment but goal alignment."（p.126）——团队的功能是目标对齐，不是替代个人干活。
• Teamicide 七法（p.133）：defensive management / bureaucracy / physical separation / fragmentation of people's time / quality reduction of the product / phony deadlines / clique control。
• 信任的底线（p.135）："it's only the right to be wrong that makes you free."（有犯错的权利才有自由）——防御式管理发出的"你不被信任"信号是团队形成的头号杀手。

校验证据 1：Lakhani & Wolf《Why Hackers Do What They Do》(2005)

• 方法：对 SourceForge 上 287 个 F/OSS 项目的 684 名开发者网络问卷（本文 PDF 摘要与正文均为 684；二手文献常引 619 人样本，此处以一手 PDF 为准）。
• 动机排序（选 ≤3 项，Table 6）："Project code is intellectually stimulating to write" 44.9% 居首；提升编程技能 41.8%；工作需要 33.8% + 非工作需要 29.7%（合并用户需要 >58%）；"源代码应当开放"约 1/3；回馈社区 28.6%；与团队共事约 20%；社区声誉、职业地位、击败闭源软件等动机排名反而很低。
• 创造性与流：61% 说该开源项目是自己一生最有创造力（或同等有创造力）的经历；73% 写码时"总是/经常"废寝忘食（lose track of time）；志愿与受薪者无显著差异。
• 投入：人均每周 14.1 小时（中位 10）投在所有 F/OSS 项目，7.5 小时（中位 3）投在焦点项目；折算每周人均 353.69 美元（志愿者）/ 535.07 美元（受薪者）的隐性补贴。
• 回归结论（Table 8）：个人创造感是每周投入时长最大的正向预测因子，受薪与喜欢团队约为其一半，声誉约为其 1/3；受薪 × 创造感交互不显著——付钱不会挤出内在动机（与 Deci 等经典挤出效应结论相反）。
• 四聚类：29% 求技能+乐趣；27% 非工作需要；25% 工作需要（86% 受薪）；19% 义务/社区认同。
• 总括："a form of joint production-consumption that provides a positive psychological outlet for the participants as well as useful output."

校验证据 2：Raymond《The Cathedral and the Bazaar》（v3.0, 2000）

• "1. Every good work of software starts by scratching a developer's personal itch."
• "6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging."
• "7. Release early. Release often. And listen to your customers."
• "Given enough eyeballs, all bugs are shallow. … I dub this: 'Linus's Law'." 及其等价形式 "Debugging is parallelizable"（调试是可并行化的）。
• 对 Brooks 定律的修正：开源开发用"大而活跃的用户/共同开发者社区 + egoless programming（Weinberg）"推翻了"沟通成本随人数平方增长"的隐含假设——"empirically, if Brooks's Law were the whole picture Linux would be impossible."
• 声誉机制的自我净化："The open-source community's internal market in reputation exerts subtle pressure on people not to launch development efforts they're not competent to follow through on."（内部声誉市场悄悄阻止不胜任者启动开发。）

校验证据 3：Herbsleb, Mockus, Finholt & Grinter (ICSE 2001)

• 大型电信系统多站点开发实证：单站点修改请求（MR）平均 5 天完成，跨站点 12.7 天——2.5 倍以上（p<0.001）；全区间 20.5 vs 27.1 天。
• 跨站点工作"需要更多人来完成同等规模与复杂度的工作"。
• 引 Allen 曲线："when engineers' offices were about 30 meters or more apart, the frequency of communication dropped to nearly the same low level as people with offices separated by many miles."（相距 30 米以上的办公室之间，沟通频率低到与相隔千里无异。）

2.5 结论

1. 软件生产力的主要杠杆是社会性变量：环境（安静/私密/防打扰）、团队凝聚、信任与社区，而非工具、语言或方法论。
2. 个体差异 10:1 是常态，组织的竞争优势来自让最好的人待在最好的环境里并凝聚成团队；环境默认值（default）政策必然失败。
3. 大多数团队"死因"是管理行为（Teamicide 七法），而非运气或人员素质。
4. 跨到开源情境后结论依然成立但形式变换：
   • 开源协作没有"家具警察"，因为它把 Peopleware 的物理问题翻译成了协议问题：物理隔离 → 异步沟通与模块化；噪音与打扰 → 邮件列表/issue 优先于即时打断；jelling → 核心圈、贡献者阶梯、共同署名；catalyst → 社区维护者与"people and communications skills"（Raymond 明言 bazaar 协调者最需要的素质）。
   • Lakhani & Wolf 的数据证明 Peopleware 第 3–4 部分的预言：创造感与流是投入的第一驱动力，志愿者与受薪者 alike；声誉不是主要动机（这与"开源=声望经济"的通俗说法相矛盾）。
   • Herbsleb 的 2.5× 数据从反面证明：一旦"物理隔离"的代价无人抵消，代价就是真实的——开源世界用文档、模块化、公开讨论来系统性地偿还这笔沟通债。

2.6 局限

作者明示的局限（诚实度高）：

• 环境数据是主观自评（"We made no objective measurements of noise levels"），无法区分"环境真的安静"与"耐噪音者恰好高效"；作者只主张"抱怨噪音的人更可能出错，忽视这个信号风险自负"。
• 相关 ≠ 因果：第 8 章 "What Did We Prove?" 明确承认可能存在自选择——"perform better 的人流向更好的环境"，但作者反问：长期看两者对雇主等价（要么提升现有员工、要么吸引更好的人）。
• CWG 是单任务基准练习，非长期真实项目；参与者是自愿参赛的公司，样本有选择偏差。

本精读补充的局限（推断）：

• 数据窗口 1984–1986（2nd ed. 1999 出版），成文于办公室政治与"美式大格子间"时代；对远程/混合办公、开源原生（OSS-native）协作、AI 结对时代的外推需要重新校准——例如"在家环境更好"的 54% 在全远程时代含义完全不同。
• 10:1 个体差异出自竞赛式任务，对设计探索类工作的差异可能更大，但对流程化工作可能更小。
• 书中对"过程改进计划/防御式方法论"的批判有其咨询立场，CMM 等章节观点存在争议。
• Lakhani & Wolf 的受访者来自 SourceForge，时代（2001–2003）与今日平台生态（GitHub、云端协作）不同；声誉动机排名低也可能受当时问卷措辞影响。
• 未能读成 Bernstein & Turban (2018) 开放办公室实证（403/证书/接口三连失败），第 5 来源缺席，"开放办公室有害"的当代因果证据链在本笔记中是断的，只有 Peopleware 的 1980s 自评数据与 Herbsleb 的间接佐证。

2.7 对我的启发（可执行原则）

1. 把"环境预算"当生产力投资：环境成本是人力成本的 1/15–1/20，任何"省空间/省工具/省注意力"的决策都要按这个比率换算。
2. 保护流时间：为自己和别人设定"无打扰块"；异步优先（写清楚再发，读的人不必打断你）；一次打断的真实成本 = 打扰时长 + 15–20 分钟重入。
3. 警惕 Teamicide 清单：防御式管理、官僚化、物理/组织隔离、时间碎片化、降质量保期、虚假 deadline、压制非正式圈子——这七条是自查清单，不只是管理者的事：给自己立 phony deadline、把自己的时间碎成多线程，都是自我 teamicide。
4. 目标对齐而非目标转包：团队的功能是 goal alignment；招募时优先找"催化剂"（能帮项目 jell 的人价值等于两个干活的人）。
5. 信任要提前给出：让人有"做错的权利"，否则团队永远凝不起来；审查文化要区分"看代码"与"看人"。
6. 开源协作的镜像原则（从三篇校验文献提炼）：
   • 动机设计以创造感为中心：让贡献者的第一个 PR 能碰到" intellectually stimulating "的核心（good first issue 只能当门，不能当主食）；
   • 把用户当共同开发者：release early, release often；文档即环境；
   • 声誉市场用来防草率，不用来带货：别把"刷 commit"当激励设计；
   • 模块化是对 2.5× 距离罚款的还款：接口越清晰，Herbsleb 罚款越小；
   • 受薪与志愿可以共存：付钱不挤出创造感（Lakhani & Wolf 交互项不显著），公司出雇员给开源项目不需要愧疚。
7. 社区是终局资产：Peopleware 第 34 章与开源共同体互为注脚——"the making of community"是长期项目真正的护城河。

3. 重要原文引述汇编（已逐条核对）

以下引文均出自本条目实际精读的一手文本；页码为 Peopleware 2nd ed. 印刷页码（PDF 第 N 页处可见的页眉/页脚），个别章节页码为近似。

1. "The major problems of our work are not so much technological as sociological in nature." —— Ch.1, p.4
2. "The manager's function is not to make people work, but to make it possible for people to work." —— Ch.7 末（Sharon："Tom, this *is* management."）
3. "People under time pressure don't work better; they just work faster." —— Ch.3
4. "Someone who can help a project to jell is worth two people who just do work." —— Ch.3（催化剂故事）
5. "A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts." —— Ch.18, p.123
6. "Once a team begins to jell, the probability of success goes up dramatically." —— Ch.18, p.123
7. "The purpose of a team is not goal attainment but goal alignment." —— Ch.18, p.126
8. Teamicide 七法：defensive management / bureaucracy / physical separation / fragmentation of people's time / quality reduction of the product / phony deadlines / clique control —— Ch.20, p.133
9. "It's only the right to be wrong that makes you free." —— Ch.20, p.135
10. "There is no message you can send that will better inhibit team formation."（指防御式管理传递的"不信任"）—— Ch.20, p.134
11. "Flow is a condition of deep, nearly meditative involvement. … It takes a slow descent into the subject, requiring fifteen minutes or more of concentration before the state is locked in." —— Ch.10, pp.62–63
12. "If the average incoming phone call takes five minutes and your reimmersion period is fifteen minutes, the total cost of that call in flow time (work time) lost is twenty minutes. A dozen phone calls use up half a day." —— Ch.10, p.63
13. "Beginning in 1977, we have conducted some sort of a public productivity survey each year. So far, more than three hundred organizations worldwide have participated in these studies." —— Ch.8, p.43
14. "From 1984 to 1986, more than 600 developers from 92 companies have participated in the games." —— Ch.8, p.44
15. "Count on the best people outperforming the worst by about 10:1. … Count on the best performer being about 2.5 times better than the median performer." —— Ch.8, pp.45–46
16. "The top performers' space is quieter, more private, better protected from interruption, and there is more of it." —— Ch.8, p.50
17. "If we proved anything at all, it's that a policy of default on workplace characteristics is a mistake. If you participate in or manage a team of people who need to use their brains during the work day, then the workplace environment is your business." —— Ch.8, p.50
18. "The 20:1 ratio implies that workplace cost reduction is risky."（工作区成本占薪酬 6%–16%，每 1 美元空间对应 15–20 美元人力）—— Ch.9, pp.50–51
19. "The only method we have ever seen used to confirm claims that the open plan improves productivity is proof by repeated assertion." —— Ch.9, p.53
20. "Across the whole Coding War Games sample, 58 percent complained that their workplace was not acceptably quiet; 61 percent complained that it wasn't sufficiently private; 54 percent reported that they had a workplace at home that was better than the workplace provided by the company." —— Ch.9, p.55
21. "Workers who reported before the exercise that their workplace was acceptably quiet were one-third more likely to deliver zero-defect work." —— Ch.9, p.55
22. "Zero-defect workers: 66 percent reported noise level okay; One-or-more-defect workers: 8 percent reported noise level okay."（某 50 人参赛公司内部）—— Ch.9, p.55
23. "It has been our experience that the positive potential of working extra hours is far exaggerated, and that its negative impact is almost never considered. That negative impact can be substantial: error, burnout, accelerated turnover, and compensatory 'undertime.'" —— Ch.27, p.178
24. "Fragmenting any knowledge-worker's time over many different tasks assures that he or she will be thrust into two or more different work groups, none of which is likely to jell into a real team." —— Ch.33, p.220
25. "It is instead in the workplace that we have our best chance of finding community." —— Ch.34, p.223
26. "The business we're in is more sociological than technological, more dependent on workers' abilities to communicate with each other than their abilities to communicate with machines." —— Ch.15（招聘/试演）
27. Raymond: "1. Every good work of software starts by scratching a developer's personal itch."
28. Raymond: "6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging."
29. Raymond: "7. Release early. Release often. And listen to your customers."
30. Raymond: "'Given enough eyeballs, all bugs are shallow.' I dub this: 'Linus's Law'." / "Linus's Law can be rephrased as 'Debugging is parallelizable'."
31. Raymond: "The open-source community's internal market in reputation exerts subtle pressure on people not to launch development efforts they're not competent to follow through on."
32. Raymond: "…empirically, if Brooks's Law were the whole picture Linux would be impossible."（并引 Weinberg egoless programming 作为关键修正）
33. Lakhani & Wolf（摘要）："enjoyment-based intrinsic motivation, namely how creative a person feels when working on the project, is the strongest and most pervasive driver. … approximately 40 percent being paid to participate in the F/OSS project."
34. Lakhani & Wolf："73% of the respondents lose track of time 'always' or 'frequently' when they are programming"；"Project code is intellectually stimulating to write"（44.9%，第一动机）
35. Lakhani & Wolf（回归）："A personal sense of creativity on a F/OSS project has the largest positive impact on hours per week. Being paid to write code and liking the team have significant positive effects that are approximately half the size of a sense of creativity. Caring about reputation in the F/OSS community has about one-third the impact as feeling creative on a project."
36. Lakhani & Wolf（总括）："…we should regard their activity as a form of joint production-consumption that provides a positive psychological outlet for the participants as well as useful output."
37. Herbsleb et al.："The average single-site MR took about 5 days to complete… In contrast, MRs which involved more than one site took 12.7 days, more than 2.5 times as long, to complete."
38. Herbsleb et al.（引 Allen）："when engineers' offices were about 30 meters or more apart, the frequency of communication dropped to nearly the same low level as people with offices separated by many miles."

4. 开源协作课题映射表（Peopleware → 开源）

5. 来源清单

1. 主源：Tom DeMarco & Timothy Lister, *Peopleware: Productive Projects and Teams*, 2nd ed., Dorset House Publishing, 1999（ISBN 0-932633-43-9）。本次精读所用全书文本：https://orion2020.org/archivo/articulos/00_peopleware.pdf （261 页 PDF，含版权页与全书 34 章）
2. Karim R. Lakhani & Robert G. Wolf, "Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects", in *Perspectives on Free and Open Source Software*, MIT Press, 2005。全文（MIT OCW）：https://ocw.mit.edu/courses/15-352-managing-innovation-emerging-trends-spring-2005/8733c45a525ebcede867a9fb282398ca_lakhaniwolf.pdf ；SSRN 页：https://papers.ssrn.com/sol3/papers.cfm?abstract_id=443040
3. Eric S. Raymond, *The Cathedral and the Bazaar*（v3.0, 2000），原文分节页：https://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html （注：该站 TLS 证书备用名异常，WebFetch 失败，本条目以 curl -k 抓取全文精读）
4. James D. Herbsleb, Audris Mockus, Thomas A. Finholt, Rebecca E. Grinter, "An Empirical Study of Global Software Development: Distance and Speed", ICSE 2001。全文 PDF（Georgia Tech 镜像）：https://faculty.cc.gatech.edu/~beki/c13.pdf
5. （检索未读成，仅记录）Esther S. Bernstein & Stephen Turban, "The impact of the 'open' workspace on human collaboration", *Royal Society Open Science* 5(3):180295, 2018, DOI: 10.1098/rsos.180295 —— 官网 403、PMC 定位失败、Crossref 调用失败，本条目未引用其任何内容。
6. Pearson 第三版样章 PDF（检索所得，用于版本比对确认）：https://ptgmedia.pearsoncmg.com/images/9780321934116/samplepages/0321934113.pdf

这次学到什么

1. 先看账本再谈文化：Peopleware 最有穿透力的不是金句而是那个 20:1 的账——环境是人力成本的 1/15~1/20，任何对环境的小气都是用小钱赌大钱。争论"格子间好不好"之前，先算这个比率。
2. 好研究的自我克制值得学习：作者对噪音-缺陷相关数据主动交代"无客观测量、可能自选择"，还专门写"What Did We Prove?"一章给出保守结论——强主张配弱证据时，把边界说清楚反而更有说服力。
3. 跨语境校验法：检验一本 1980s 组织学经典是否还成立，最快的方式不是找书评，而是拉两篇独立领域（开源动机、分布式协作）的实证数据来对表——本条目的"开源映射表"就是这么来的：结论大多成立，但"声誉是开源主驱动力"这一流行说法被数据推翻（创造感才是）。