大教堂与集市

[美] Eric S.Raymond

只要眼睛多，bug容易捉。

“早发布、常发布”策略的一个效果就是快速传播反馈回来的修复，从而使重复劳动最小化。

“用户越多，bug越多”是因为增加用户就会增加程序检验的方式。当用户是合作开发者时，这种效应会被放大，每个着手去发现bug的人，都会有不同的视角，并使用各自略微不同的捕捉方法和分析工具。

只要能有一个对出错条件在源码级别上的提示性描述（即便不完整），大多数bug在大多数时间里就很容易被发现。如果你的beta测试人员中有人指出“在第n行有一个边界问题”，或者仅仅指出“在条件X、Y和Z下，这个变量会溢出”，你扫一眼那部分代码，往往很快就能准确找到出错模式并得出修正办法。

对于复杂的多症状错误，要想从表面症状追踪到实际bug，往往有多种路径，开发者或测试者追踪时经由何种途径，取决于千差万别的个人运行环境，并且该环境会随时间产生不确定的变化。

对于简单和容易重现的bug，重点要放在“半”而非“随机”上，此时，调试技能以及对代码和架构的熟悉程度会大显身手。对于复杂的bug，重点就要放在“随机”上了，这种情况下多人共同追踪bug远比少数几个人循序追踪要有效得多——即便这几个人的平均技能要高很多。

设计上的完美不是没有东西可以再加，而是没有东西可以再减。

探索在本质上是分散行动，并通过一种可扩展的通信机制来协调整体行为。

你必须要有一个非常强大的设计创意并完全投入，以至于这个结果就像是不可避免、自然而然和预先设定的。

任何工具都应具备预期内的功能，但一个伟大的工具能给你带来预期外的功能。

写网关类软件时，尽可能不要干扰数据流，而且绝不要扔掉信息，除非接收方强迫你这么做。

最好的程序一开始只是作者对自己每天遭遇问题的个人解决方案，程序流传开来则是因为作者遇到的问题成了一大类用户的典型问题。

想要解决一个有趣的问题，先去找一个让你感兴趣的问题。

无论如何，在一个廉价PC和快速Internet连接的世界里，我们发现始终如一真正有限的资源是技术人员的关注，开源项目如果失败了，根本不会是因为机器、网络或办公场地，它们死掉的唯一原因就是开发者们不再感兴趣了。

开源社区最强大的一个长项就是非中心化的同行评审，所有致力于细节不被疏漏的传统方法，都无法和它相比。

在资产可以被无限复制和轻易改变，且其环境文化既不是强制权力关系也不是物质稀缺经济的情况下，“所有权”该如何理解呢？实际上，开源文化对这个问题有着简单的回答：一个软件项目的“所有者”就是在社区中众所周知的对软件版本改动有唯一发布权的那个人。

“别为名声工作，如果你做得好，名声将伴随结果而来”

声誉竞争模型解释了一个常被引用的格言，即“自称是黑客不代表你就是黑客，只有其他黑客认为你是黑客，你才是黑客”。