有一个词叫“啊哈时刻”，它通常用来描述一个产品。指产品使用户眼前一亮的时刻，是用户真正发现产品核心价值的时刻。在读书的时候，我们也经常会遭遇“啊哈时刻”。这个时刻通常发生在我们看到了一个有趣的观点时，这个观点解答了我们近期在反复思考的一个问题或者持续遭遇的一个困惑。

在读《大教堂与集市》这本书的时候，我频繁的遭遇了“啊哈时刻”，惊喜之余，也想拿出来跟大家分享一下。

此类标记的引用内容为书中原文

黑客与骇客

黑客，hacker，是指那些着迷于技术并充满才华和理想的人。

骇客，cracker，指涉嫌通过技术手段进行计算机犯罪的人。

两者最根本的区别是：黑客搞建设，骇客搞破坏。

每周发布，并在接下来几天内获取数百个用户的反馈

这是书中用来描述 Linux 项目运作情况的句子。DevOps 中也倡导“快速流动，持续反馈”。其实对于做好所有的事情来说，快速反馈都是一个必要因素。回过头来思考一下开源项目，为什么大部分开源项目做不到这么持续频繁的反馈？其实从一个项目一出生那一刻，他就带有了一个属性。这个属性就像人的基因，基因在很大程度上决定了项目能吸引到多少顶级的黑客来参与，也就决定了反馈的质量和密度。

最优秀的百分之五

开源之所以成功，部分原因是开源文化只接受编程人员中那最有才华的 5%

也可能是 15% 25%，项目的领域和难度决定了有多少人能参与进来。越是基础，对前置知识要求越低的项目，面向的开发人员群体就越大。但是社区的活跃度和反馈的质量、密度可能就会越低。

优秀的程序员知道些什么，卓越的程序员知道改写什么

Linus Torvalds 没有从头开始写 Linux，而是以重用 Mixin(一个迷你型 UNIX 类操作系统) 的代码和理念作为开始，虽然 Linux 中所有 Mixin 代码最终都被移除或重写，但它在 Linux 成长初期确实起到了类似脚手架的作用。

本书的作者在启动 fetchmail 项目的时候也没有从零开始，而是对比了 10 个已有的 POP3 客户端，最终选择了 popclient 作为基础进行演进。

如果你想要做对事情，至少要再做一次

popclient 并不是一开始就作为最终选型的。在第一轮对比中，作者首先选择的是 fetchpop，他给程序加上“邮件头重写”的功能，并做了一些其他改进，这些改进被项目原作者接受并在 1.9 版本中发布。

几周以后，我偶然发现了 Carl Harris 写的 popclient 代码，同时带来的是一个难题：尽管 fetchpop 有一些好的创意（比如使用后台进程模式），但只能处理 POP3 协议，代码也略显业余，Carl Harris 的代码要好一些，专业而稳健，但缺乏 fetchpop 中一些重要而精巧的特性（包括我写的那部分）。

作者最后选择了 popclient，并且把之前实现的功能又实现了一遍。

只要眼睛多，bug容易捉

这正是代码检视的意义所在，有的人关注代码逻辑，有的人关注视觉呈现，有的人关注代码风格，有的人关注架构设计。

作者在这里想表达的意思是，开源项目相比于闭源项目会有更多的参与者，就能发现更多的bug.

多少只眼睛才能驯服复杂性

内部视角与外部视角

开发人员和测试人员/用户的视角不同，开发人员从内向外看，测试人员/用户从外向内看。所以在遇到问题时，测试人员/用户会说，我页面上某个按钮点了没反应，loading 一直没有结束等等，而开发人员的第一反应是你把 F12 打开，我看一下报什么错了。

这个维度给我们的提示是，开源项目由于参与者能看到源代码，所以他们有更大的希望能够从代码层级提出问题，而不仅仅是反馈一个“按钮点了没反应”。

Brooks定律：在一个已经延期的项目上增加人手，只会让项目更加延期

bug 很容易集中在不同人写的代码的交互接口上，沟通/协调的开销会随开发者间接口数的增加而增多，也就是说，问题规模和开发人员间的沟通路径相关，即和人数的平方相关。

在闭源项目中，一个项目的所有开发者之间形成的是一张 N 对 N 连接的网。而在开源项目中，开发者之间的连接是 1 对 N 的连接，交互接口更少，进而产生的问题就更少。

问题追踪路径

不同的人在定位同一个问题时，会选择不同的路径，不同路径的难度不一样，只要有一个人先找到了答案，其他在更难的路径上追踪的人就可以停下来，避免浪费更多的时间。

聪明的数据结构配上愚笨的代码，远比反过来要好得多

Brooks 在《人月神话》的第 9 章里说：“让我看你的流程图但不让我看表，我会仍然搞不明白。给我看你的表，一般我就不再需要你的流程图了，表能让人一目了然”。

如果你把测试者当做最珍贵的资源对待，他们就会成为你最珍贵的资源

开源项目需要开发者的反馈，开发者也需要项目核心维护团队的反馈。 鼓励开发者参与，听取他们的意见，积极响应他们的提交。

比找到答案更重要的，是提出一个好问题

当你发现自己在开发中碰壁时，当你发现自己苦思冥想也很难做出下一个补丁时，通常你不该问自己是否找到了正确答案，而是该问你是否提出了正确的问题，因为也许问题本身需要被重新定义。

在开发 popclient 的时候，作者尝试将它做成一个 MTA 和 MDA 的结合体，尝试了很久发现他正在解决一个错误的问题。后来，他扔掉了 MDA 模块，默认采用 SMTP 转发。代码变得更简洁，性能更好，信件丢失的唯一途径也不见了。

MTA（Mail Transfer Agent）：“邮件传送代理”。MTA是用在邮件主机上的软件，它也是主要的邮件服务器。MTA负责发送邮件，中转邮件，当然也要接收邮件。

MDA（Mail Delivery Agent）：“邮件投递代理”。主要的功能就是将MTA接收的信件依照信件的流向（送到哪里）将该信件放置到本机账户下的邮件文件中（收件箱），或者再经由MTA将信件送到下个MTA。

传统项目软件中的 60% 到 70%，要么是从未被完成，要么被他们的用户拒绝

这一条，大家自己品一下。

批量制造的错觉-市场销量很好，但没有实际价值

在开源世界里，你寻找的是最大可能的用户群，以便获得最大限度的反馈和最有活力的可能的二级市场。在闭源环境中，你寻求的是尽可能多的购买者和尽可能少的实际使用者。所以，工厂模式逻辑会强烈鼓励供应商生产出“存架软件” —— 市场销量很好但没有实际价值的软件。

这个取决于闭源软件的收费模式，是一次性收费，还是按服务收费。

开源项目的生命周期-我觉得这个项目已经足够好了

在维护 fetchmail 项目的后期，作者发现有贡献者开始退出，并且要求自己被从邮件列表中删除，理由是这个项目已经足够好了。

开源项目的生命周期，这是我从未考虑过的维度。在项目初期，有很多事项和待办，参与者可以比较容易的贡献反馈及获得反馈，到了项目后期，产生反馈的成本越来越高，这个时候我们应该通过什么方式来保持社区的高活跃度，或者说，还需要保持吗？