大教堂与集市
黑客”并不是媒体报道中的计算机违法分子，而是那种着迷于计算机技术并通过编程提供极具价值软件的人
他教导我：要尊重能力，要珍视和捍卫自由，特别是：昆虫才讲究技能专一
Cray系列超级计算机的设计者Seymour Cray就是其中的佼佼者，据说他通过机器的前面板开关将他自己设计的整个操作系统以八进制形式导入他设计的计算机之中，并且没有任何错误，这可真是大师级的神作。
“黑客”一词大约就起源于MIT的计算机文化。技术模型铁路俱乐部的黑客们，大都成为MIT人工智能（AI）实验室的核心成员，直到上世纪80年代早期，该实验室在AI领域的研究都一直处于领先地位，
同样也是使用PDP-10，MIT却有些与众不同，他们完全摒弃了DEC为PDP-10写的软件，而是自己写了一个操作系统，即传说中大名鼎鼎的ITS。
ITS是用汇编语言写的，其应用大都是用AI语言LISP写的。LISP比当时的任何编程语言都要强大而灵活，事实上，25年过去了，它的设计仍然比如今大多数语言都要好
Berkeley UNIX提供了对APRAnet协议的内置支持，解决了由于UUCP点到点连接较慢而带来的网络问题，促进了互联网的进一步发展。
Linux最重要的特点不是技术上的，而是社会学上的。在Linux被开发出来之前，所有人都认为，如果软件复杂到操作系统这样的程度，就必须要有一个精心协作的团队，团队要比较小，而且紧密互动，不管是以前还是现在，这都是很典型的开发模式。
他们创造了一种类似达尔文“物竞天择”的选择机制，被选择对象则是开发者们所做的种种软件修改。让所有人吃惊的是，这种方式工作得非常好。
1996年，黑客动员起广泛的同盟，导致所谓的“通信合宜法”（CDA）被废止 [6]，阻止了政府对互联网的审查。
“只要眼睛多，bug容易捉。”这和那些由利己个体组成的自纠错系统有着异曲同工之妙。
Linus Torvalds的开发风格是：早发布、常发布、委托所有能委托的事、开放到几乎是混乱的程度，这些都令人感到惊讶不已。在Linux社区里，没有建筑大教堂那样的安静和虔诚，倒更像是一个乱糟糟的大集市，充满了各种不同的计划和方法（Linux的文件服务器就是个很好的例子，这里可以接受任何人的代码和文档提交），而既稳定又一致的一个操作系统就这么诞生了，这真是奇迹中的奇迹。
的软件作品，往往源自于开发者的个人需要。
但太多的软件开发人员并不需要也不热爱他们正在开发的软件，他们把编程当差事，为的只是拿薪酬
优秀的程序员知道写什么，卓越的程序员知道改写（和重用）什么
卓越程序员们有个很重要的特征是“建设性懒惰”，他们知道人们要的是结果而不是勤奋，而从一个部分可行的方案开始，明显要比从零开始容易得多。
我想，Linus最聪明和最有价值的成就其实不是构建出一个Linux内核，而是他发明的这种Linux开发模式。有一次我当面向他表达了这个看法，他笑了，平静地重复了他常说的话：“我基本上是个很懒的人，别人做事，我得名誉。”像狐狸那样懒，或者像Robert Heinlein曾经描绘的一个很有名的角色，太懒以至于无所不能。
不只是Emacs，还有其他一些软件产品也使用了两层架构和两级用户群，内核使用大教堂模式开发，工具箱(toolbox)使用集市模式开发，比如数据分析和可视化展现的商业化工具MATLAB就是这样
Linus无疑是一个顶级黑客，想想有多少人能从零开始建造一个完整的具有产品级质量的操作系统内核？但Linux并没有展现出多少令人赞叹的概念性突破。和Richard Stallman或者James Gosling（NeWS和Java的作者）相比，Linus不是（至少现在还不是）一个富有创造性的设计天才，他更像是一个工程实施上的天才，他具备一种避免bug和防范开发走入死胡同的第六感，而且有一种能发现从A点到B点最省力路径的真本事，事实上，Linux的整个设计，都透露着这种特质，并反映了Linus那种本质上保守而简洁的设计取向。
事实上，一个仅描述外部可见症状的bug报告，和一个直接关联到源码的分析型bug报告，对开发者而言简直是天壤之别。
传统软件开发在组织结构上的根本问题由Brooks定律一语道破：“在一个已经延期的项目上增加人手，只会让项目更加延期。”更为一般地讲，Brooks定律指出，随着开发人员数目的增长，项目复杂度和沟通成本按照人数的平方增加，而工作成果只会呈线性增长。
Brooks定律是建立在经验基础上的，人们发现，bug很容易集中在不同人写的代码的交互接口上，沟通/协调的开销会随开发者间接口数的增加而增多，也就是说，问题规模和开发人员间的沟通路径数相关，即和人数的平方相关（更精确地讲，应该是N(N-1)/2，N代表开发者数目）。
实际上，每个开发者和测试者在寻找病状症结的时候，都是在“半随机”（semi-random
实际上，每个开发者和测试者在寻找病状症结的时候，都是在“半随机”（semi-random）的变量集合上对程序状态空间进行采样
对于简单和容易重现的bug，重点要放在“半”而非“随机”上，此时，调试技能以及对代码和架构的熟悉程度会大显身手。对于复杂的bug，重点就要放在“随机”上了，这种情况下多人共同追踪bug远比少数几个人循序追踪要有效得多——即便这几个人的平均技能要高很多。
聪明的数据结构配上愚笨的代码，远比反过来要好得多。
Brooks在《人月神话》的第9章里说：“让我看你的流程图但不让我看表，我会仍然搞不明白。给我看你的表，一般我就不再需要你的流程图了，表能让人一目了然。”历经30年的术语/文化变迁，这个道理依旧没变
仅次于拥有好主意的是，识别来自用户的好主意，有时后者会更好
很有趣的是，如果你发自内心地谦逊，并承认你欠别人很多，你将很快发现世界会这样对待你：他们认为是你发明了整个软件，而且你对自己的天赋有着得体的谦虚。
通常，那些最有突破性和最有创新力的解决方案来自于你认识到你对问题的基本观念是错的。
设计上的完美不是没有东西可以再加，而是没有东西可以再减
任何工具都应具备预期内的功能，但一个伟大的工具能给你带来预期外的功能。
传统程序员倾向于喜欢那种非常简洁、紧凑和没有一点冗余的控制语法。这是计算资源昂贵年代的文化遗留，在当时看来，解析过程应尽可能简单和节省资源。英语大约有50%的冗余度，很不适宜作为控制语法的模型。
系统的安全性只取决于它所拥有的秘密。谨防虚假的秘密。
当开始建设社区的时候，你需要拿出一个像样的承诺。程序此时并不需要特别好，它可以简陋、有错、不完整，文档可以少得可怜。但它至少要做到：(a)能运行，(b)让潜在的合作开发者相信，这个软件在可预见的未来，能演变成一个非常棒的东西。
一个协调者是否拥有卓越的原创设计能力，并不是项目成败的决定性因素，但他是否能识别出别人的优秀创意，则一定是最关键的。
最近，Kent Beck在其“极限编程”（extreme programming）技术中提出的结对编程——两个程序员肩并肩共同完成编程——可以看作是一种效仿
集市模式，运用“无私编程”效果的充足能量，强有力地化解了Brooks定律的影响。Brooks定律背后的原理没有失效，但如果有一个大规模的开发群体和一个低成本的沟通机制，Brooks定律的效果将会被其他非线性因素带来的效果淹没，而后者是大教堂模式下看不到的。这很像是物理学上牛顿理论和爱因斯坦理论的关系——在低能量条件下，老的系统仍然有效，但如果把质量和速度推进到足够大的地步，你就会震惊于核爆炸或Linux。
UNIX历史为我们从Linux中获取经验早已做下了铺垫（为验证其有效性，我专门在一个较小规模的项目上拷贝了Linus的方法
果开发协调者有一个至少像Internet这样好的沟通媒介，并且知道如何不靠强制来领导，那么多人合作必然强于单兵作战
来软件产业
未来软件产业的经济关键是服务价值。
她相信开源之所以成功，部分原因是开源文化只接受编程人员中那最有才华的5%。她将自己的大部分时间都花在了组织部署其他的95%，并因而第一手见证到那广为人知的差异：最有才华的程序员和那些刚刚及格的程序员之间，生产率能相差100倍
在两方面（资源调配和组织）都没有胜算，而且似乎在第三点（动机）上也快要玩完了。
目前来看，传统的开发管理相对于开源，至少在两方面（资源调配和组织）都没有胜算，而且似乎在第三点（动机）上也快要玩完了。
一个快乐的程序员是一个既没有被浪费也没有被压垮（由于不适当的目标或过程中充满压力与冲突）的人，乐趣预示着效率。
beta测试即“β测试”，和“α测试”相对应。对于一个即将面世的软件产品，α测试是指软件公司组织内部测试人员模拟各类用户行为对产品(此时为α版本)进行测试。随后的β测试是指软件公司组织各类典型用户在日常工作中实际使用（此时产品为β版本），并要求用户报告错误及异常情况。最后软件公司再对β版本进行改错和完善。
呆伯特（Dilbert）是美国作家和漫画家Scott Adams创造的广为流行的职场卡通人物。他是一名计算机工程师，热爱科技、待人友善、憨厚老实，但很不成功，在公司里人微言轻，常常被主管过分要求和利用