读书摘要，构建开源项目

制造开源软件

选择

自由软件是一种有关选择的文化。你必须首先理解为什么人们会参与其中，才能成功地运作一个项目。强制是不管用的。如果一个项目让人不高兴了，他们会立刻转移到另一个项目。自由软件的独特之处还在于志愿者社区的投资强度。大部分内部的人从来没有和另一个参与者面对面地交流过，只是在高兴时捐助一点时间。通常人类用来互相结识并结成牢固的团体的渠道被压缩成了一条细管：在键盘上打字然后通过电缆传输。因此，形成一个有凝聚力和专注力的组织需要花上很长时间。相反，在首次接触的五分钟内流失一个潜在的开发者是非常容易的。如果对一个项目没有良好的第一印象，新来者很少会给予第二次机会。

动机

有关自由软件是如何发起的经典模型是由Eric Raymond提出的，在一篇今天已广为人知的有关开源开发的论文《大教堂和集市》中，他写道：一个好的软件都始于挠到一个开发者的痒痒处

注意Raymond并没有说只有当某些开发人员心里痒痒之后才会导致一个开源项目的诞生。相反，他是说只有当程序员对解决某个问题产生了个人兴趣之后，才能产生优秀的软件；这一点同自由软件的联系在于，大部分自由软件项目的最初动机都是始于一个人的痒痒处。

Alpha和Beta

术语alpha这个词通常指的是第一次发布，但是用户可以使用该软件进行工作，并且软件也具备了最初计划的所有功能，但已知的Bug仍然存在。Alpha软件的主要目的在于获取回馈，以便开发人员了解他们应该做什么。下一个阶段，beta是指软件中所有厉害的Bug都已经被消灭了，但是软件还未经过足够的测试，因而还不能正式发布。Beta软件的目的有二，一是在未发现Bug的情况下正式发布软件，二是提供给开发人员详细的回馈，以便他们能够尽快解决问题之后正式发布软件。Alpha和Beta的差别通常是由判断而决定的。

Bug管理

对于项目的Bug跟踪系统来说，也是同样的道理。Bug跟踪系统之所以重要不只因为它对开发人员十分有用，而且对关注项目的人来说是一种标志。在许多人看来，一个可以进入的Bug数据库是一个项目是否严肃认真的重要标志之一。再者，数据库中的Bug数量越多，项目看起来越好。这听起来似乎有悖常理，但是请记住Bug数量的记录实际上取决于三个因素：软件中存在的Bug绝对数量，使用该软件的用户人数，以及用户记录新发现的Bug的方便程度。在这三个因素当中，后两个比前一个重要得多。任何具有一定规模和复杂性的软件基本上都存在一定数量有待被发现的Bug。真正的问题是，一个项目在记录和优先解决Bug问题方面做得有多好？如果一个项目有一个较大而又维护得很好的Bug数据库（意思是bug问题得到及时地回应，重复bug被合并等等），那么这个项目就会比那些没有Bug数据库，或者Bug数据库里空空如也的项目给予人们更好的印象。

避免私下讨论

即使你已经将项目公开，你和你的创始人也会经常希望通过私下讨论来解决困难的问题。这在项目的开始阶段尤其明显，因为此时需要做出许多重要的决定，而只有少量志愿者能够胜任。你会发现公开讨论的明显缺点：邮件对话本身的延迟性，需要保留足够的时间来达成一致，处理自以为是的幼稚的志愿者（每个项目都有；有些将来会成为明星贡献者，而有些会永远保持幼稚），也就是那些不能理解你为什么只希望解决问题X，而X明显是大问题Y的子集的人。秘密决定并使之成为既成事实，或者至少成为联合和有影响力的投票集团的坚实推荐，确实非常有吸引力。不要这样做。

尽管公开讨论可能很笨重，但是从长远来看这样做更合适。私下里做出重要的决定就像是将贡献者排斥出项目一样。没有重要的志愿者会愿意呆在这样一个由秘密委员会做重要决定的环境里。此外，公开讨论也会从其副作用中获益，无论是多么短暂的技术问题，一经发起都会一直讨论下去：讨论有助于训练和教育新开发者。你不知道有多少双眼睛在关注着讨论；即使大多数人不会参与，仍然可能有很多人在静静的跟踪，收集软件的信息。讨论会训练你如何向不熟悉软件的人们解释技术问题。这种技巧需要练习，你不能从已经知道你所知道的人那里获得这种练习。之后，讨论和结论将会一直存放在公共归档中，可以保证以后的讨论不会回到同样的步骤中。见Chapter 6, 交流的the section called “归档的显著使用”。

最后，很有可能某个人会提出一个你从想到过的好主意，给对话带来真正的贡献。很难说这有多大的可能；这仅仅由代码的复杂程度和需求的专业程度决定。但是如果允许我使用轶事作为证据，我会证明这样做比直觉所期望的结果更好。在Subversion项目，我们（创始人）相信我们面对的是一组深入而复杂的问题，为此我们痛苦思考了几个月，我们很明确的怀疑在新建立的邮件列表中的会有任何人做出真正的贡献。所以我们选择了一条比较懒惰的方式，开始通过私下邮件讨论技术想法，直到项目的一个观察者[10]嗅出了问题，并要求将讨论公开。眨了眨眼我们这样做了—后来的结果让我们十分惊讶，我们很快便获得了许多有见地的回复和建议。大多数情况下人们提供的想法都是我们从来没有想到的。结果是邮件列表中一下子多了许多非常英明的人；他们只是在等待正确的诱饵。可以肯定地是公开讨论比私下讨论会保持更长的时间，也能得到更多的产出，花费额外的时间是值得的。

我们不必把问题总结为：“团结就是力量”（我们已经见过许多更成功的团队），但可以确认的是有一些事情适于在团队中完成。首先是有了大量的审阅；其次是快速产生大量的想法。想法的质量由其所针对的思想决定，当然，在你用挑战性的问题刺激他们之前，你无法判断这些思考者是那种人。当然，也有许多讨论必须在私下进行，通过此书我们会看到这种例子。但是我们有一个指导原则如果没有保持秘密的原因，那就公开进行。要想使之发生，我们需要行动。仅仅保证自己所有的通告公开是不够的。你也需要劝说其他人放弃不必要的私下讨论。如果某个人尝试开始没有必要的私下讨论，你要义不容辞的立刻进行恰当的元讨论。在你将讨论成功的引入公开场所之前，不要对原始主题做出任何回复，或者去确定私下进行是否必须。如果你一贯如此，人们会很快会意，并开始首选公开论坛进行讨论。

授权

最后，可能是最重要的，使用荣誉系统来鼓励互相尊重和信任的氛围。给一个人对某一区域的访问权限是对他们已经完成技术准备的证明—这是说：“我们已经看到了你已经具备了对某一领域做出修改的专业知识，那就继续吧。”但设置严格的授权控制则是暗示：“我们不仅仅确认你专业知识的限制，而且我们对你的目的也保持怀疑。”如果可以避免的话，你一定不愿意做出这样的评价。将一个人引入为项目的提交者是将其引入互相信任循环的机会。好的方法是给他们比期望所能发挥作用更大的权力，然后告诉他们是否保持在规定的限制内完全依赖于他们自己。

慈善独裁者

慈善独裁者模型这一称号确实名副其实：最终的决定权完全取决于一个人，因为其人格和经验的力量，他被认为可以明智的运用这个权力。

尽管“慈善独裁者”（BD）是这个角色的标准术语，但是更应该将其视为“社区认可的仲裁者”或“裁判者”。通常来说，慈善独裁者并不会作出所有的、甚至大多数的决定。一个人很难拥有在项目所有领域中都能做出正确决定的专业技能，毕竟，如果对于项目的方向没有任何影响，有价值的开发者也不会在此停留。因此，慈善独裁者通常不会非常的独裁。相反，他们会尽可能的让事情在讨论和实验中顺其自然。他们自己也会参与讨论，但是作为某领域的普通开发者，他们一般会尊重拥有更多专业知识的领域维护者。只有当明显无法得出结论时，而且大多数成员期望有人能够指导作出决定，并让开发继续时，他们才会采取坚定的立场并说“这是我们前进的路。”避免使用命令作决定是所有成功慈善独裁者共同的特征；也是他们设法保持这个角色的一个理由。

成为一个BD需要许多特性的组合。首先，要对自己在项目中的影响有经过充分磨练的敏感性，这样可以保证自我约束。在一个讨论的早期阶段，一定不能过于确定的表达自己的意见和结论，以至于让别人觉得继续发生分歧毫无意思.人们应当能自由的放飞思想，即使是愚蠢的想法。BD也会不可避免的屡屡发表愚蠢的意见，所以这个角色也必须具备认可和承认自己作出错误决定的能力—尽管这是一个所有优秀开发者都应该具备的能力，但如果她要长期呆在一个项目，这一点特别重要。但区别是BD无法无视其信誉的长期损害。但资历尚浅的开发者不必如此谨慎，所以BD必须对批评或反对决定的语句小心措辞，对于词汇的分量十分敏感，不仅是技术上的，还包括心理的。

共识为基础的民主（Consensus-based Democracy）

随着项目的成长，通常会从慈善独裁模型转为更开放的民主系统。这不一定是源于对某个BD的不满，借用一个生物学的隐喻，可以简单的认为团队基础的管理更加“进化稳定”。每当一个慈善独裁者引退，或尝试将决策责任更均匀的分配出去，这就是团队选定一个新的非独裁系统的好机会—也就是要建立一套宪法。团队可能错过了第一次机会、或者第二次，但是最终会这样做；一旦做了，这个决定就不太会反转过来。常识解释了原因：如果某个N位成员的团队给某个人特殊的权利，也就意味着有N - 1位成员都愿意降低自己的个人影响。人们通常不愿意这样做。即使他们这样做了，所产生的独裁统治仍然是有条件的：团队推举了BD，团队也可以罢免BD。因此，一个项目的领导权一旦从某个魅力个人转移为更正式的团队为基础的系统，就很少会走回头路。

表决与妥协

最难的事情是决定何时开始表决。通常情况下，很少会进行表决—是其他方法都失败后的补救方法。不要将表决当作解决争辩的重要方法。它不是。它可以终结讨论，也会结束关于此问题的创造性思考。只要讨论还会继续，就有可能会有人得出所有人满意的解决方案。这经常令人吃惊：活跃的争论可以产生关于问题的新方法，也会得出使每个人都满意的提议。即使没有出现新的提议，通常采纳某种妥协也比举行表决要好。经过妥协，每个人都或许会有点不高兴，但是表决过后，有些人会开心，还有些人会失望。从政治视角，前一种状态更可取：至少每个人都会感到为自己的不快萃取了一定的价值。他会不满意，但其他人也一样。

结构与格式

不要像编写手机短信那样编写所有的东西。要使用完整的句子，每个句子首字母要大写，也要根据需要分段。在编写电子邮件和其他内容时这一点最重要。在IRC或类似的短命论坛上，忽略大小写或压缩形式的常见短语也无所谓。只是不要把这个习惯带到更正式，会持久化保存的论坛中。邮件、文档、bug报告和其他会永久保存的东西，必须使用标准语法和拼写，并有一致的叙事结构。并不是因为任何事情都有遵循任意规则的内在特性，而是因为规则并不是任意的：他们演化成现在的形式是因为可以让文本更可读，因此你应该遵循这些规则。可读性是令人向往的，并不是因为这样人们就能够理解你所写的，而且是因为这样可以让你看起来像是人们可以花时间进行清晰交流的人：也就是值得人们关注的人。

a minimum resource set for a project of moderate complexity

这本90年代末的开源牛人合集的书里提到管理一个开源项目的基本步骤：

Role 1:

Infrastructure support: Someone to set up and maintain the mailing list aliases, the web server, the CVS (Concurrent Versioning System) code server, the bug database, etc.

• Startup: 100 hours
• Maintenance: 20 hrs/week.

Role 2:

Code "captain": Someone who watches all commits and has overall responsibility for the quality of the implemented code. Integrates patches contributed by third parties, fixing any bugs or incompatibilities in these contributions. This is outside of whatever new development work they are also responsible for.

• Startup: 40-200 hours (depends on how long it takes to clean up the code for public consumption!)
• Maintenance: 20 hrs/week

Role 3:

Bug database maintenance: While this is not free "support," it is important that the public have an organized way of communicating bug reports and issues to the server developers. In a free setting, the developers are of course not even obliged to answer all mail they get, but they should make reasonable efforts to respond to valid issues. The bug database maintainer would be the first line of support, someone who goes through the submissions on a regular basis and weeds out the simple questions, tosses the clueless ones, and forwards the real issues on to the developers.

• Startup: just enough to learn their way around the code
• Maintenance: 10-15 hrs/week

Role 4:

Documentation/web site content maintenance: This position is often left unattended in open-source projects and left to the engineers or to people who really want to contribute but aren't star programmers; all too often it's simply left undone. So long as we're going about this process deliberately, locating dedicated resources to make sure that non-technical people can understand and appreciate the tools they are deploying is essential to widespread usage. It helps cut down on having to answer bug reports which are really just misunderstandings, and it also helps encourage new people to learn their way around the code and become future contributors. A document that describes at a high level the internal architecture of the software is essential; documentation that explains major procedures or classes within the code is almost as important.

• Startup: 60 hours (presuming little code has been documented)
• Maintenance: 10 hrs/week

Role 5:

Cheerleader/zealot/evangelist/strategist: Someone who can work to build momentum for the project by finding other developers, push specific potential customers to give it a try, find other companies who could be candidates for adopting this new platform, etc. Not quite a marketer or salesperson, as they need to stay close to the technology; but the ability to clearly see the role of the project in a larger perspective is essential.

• Startup: enough to learn the project
• Maintenance: 20 hrs/week

ZMQ 用户指南里对好代码的观点

阅读ZMQ的文档，ZMQ UserGuide里写到：

Learn ZeroMQ step-by-step. It's just one simple API, but it hides a world of possibilities. Take the possibilities slowly and master each one.

Write nice code. Ugly code hides problems and makes it hard for others to help you. You might get used to meaningless variable names, but people reading your code won't. Use names that are real words, that say something other than "I'm too careless to tell you what this variable is really for". Use consistent indentation and clean layout. Write nice code and your world will be more comfortable.

Test what you make as you make it. When your program doesn't work, you should know what five lines are to blame. This is especially true when you do ZeroMQ magic, which just won't work the first few times you try it.

When you find that things don't work as expected, break your code into pieces, test each one, see which one is not working. ZeroMQ lets you make essentially modular code; use that to your advantage.

Make abstractions (classes, methods, whatever) as you need them. If you copy/paste a lot of code, you're going to copy/paste errors, too.