起步

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

每一个好的软件都始于挠到一个开发者的痒痒处。（来自）

注意Raymond并没有说只有当某些开发人员心里痒痒之后才会导致一个开源项目的诞生。相反，他是说只有当程序员对解决某个问题产生了个人兴趣之后，才能产生优秀的软件；这一点同自由软件的联系在于，大部分自由软件项目的最初动机都是始于一个人的痒痒处。这仍然是大部分项目的动因，但自从1997年Raymond写下这些话之后这种现象正在慢慢减少。今天我们有了一些组织—包括盈利性的大企业—从零开始大型的，集中式管理的开源项目。单个的程序员为了解决一个个人问题敲出一些代码而最后意识到可以有更广泛地应用的例子仍然是许多新自由软件的源头，但不再是唯一的故事。然而Raymond的观点仍然是真知灼见。关键在于软件的生产者对它的成功有直接的兴趣，因为是自己用。如果软件没能达到期望的目标，那些编写它的个人或是组织会在日常工作中感到不满。例如，OpenAdapter项目（），这是一个由德累斯顿·克莱沃特投资银行（investment bank Dresdner Kleinwort Wasserstein）发起的一个用于集成不同财经信息系统的开源框架，就很难说是始于哪个程序员的个人痒痒处。它始于一个组织的痒痒处。这些痒痒处直接来自这个组织和他们的合伙人的经验，因此如果这个项目没能减轻这些痒痒症，他们立刻能够感觉到。这种情形产出了优秀的软件，因为形成了一个良性的循环。程序不是为了卖给其他人而编写的，不是为解决他人的问题。它是为解决某个自己的问题而编写的，之后再同其他的人分享，足可以把问题想像成疾病，而程序是分发的药物，用来彻底地消灭传染病。本章是关于如何将一个自由软件项目介绍给全世界，但是其中的很多建议听起来会很像一个卫生组织在分发药物。两者的目标的确非常相似：你要弄清楚药品的作用，把它发放到需要的人手中，并确保那些人知道如何使用它。但对一个软件，你还需要诱使那些接受者加入研究计划来改进“药物”。自由软件的发布是一项双重任务。软件既要满足使用者，也要满足开发者。这两种需求不一定是冲突的，但是会为项目初期的展示增加复杂度。其中有些信息对两者都有用，有些只是对其中一类有用。对两种信息都应该依照展示的比例原则：描述的详细程度应该同读者在该阶段所应该花费的时间和努力程度相对应。更多的努力应该带来更多的回报。当这种关系发生偏差时，人们有可能很快失去信任并且停止投入精力。这一点的必然结果就是形象的重要性。程序员们对这一点总是嗤之以鼻。对本质超越形式的热爱成了他们职业自豪感的一部分。所以毫不意外，许多程序员表现出对营销和公关工作的厌恶，同样，职业图形设计师往往也对程序员们的产品感到惊恐万状。这是一个遗憾，因为有时候形式就是本质，并且项目的展示就是这种情形之一。例如，浏览网页的人对一个项目的第一观感就是来自网站的外观。这种观感的形成要早于任何一种实际的内容之前—包括文字和链接。不管这看起来多么不公平，人们无法不形成一个即时的第一印象。网站的形象向读者传递了一个信号，即网站的展示是否经过了精心安排。人类对检测心思的投入有着极为敏锐的感觉。我们中的大多数人都能在一瞥间看出一个网站是随便拉起来的还是经过认真思考的。这是你的项目展现出信息的第一步，它所建立起来的印象将对整个项目的后续部分施加影响。因此，尽管本章的大部分篇幅谈论的是你应该用什么样的内容开始你的项目，但别忘了外观和感觉同样重要。因为项目的网站同时为使用者和开发者两类人服务的，相应的投入也要透明和有针对性。虽然这不是一本讨论网页设计的专著，但是当网站是为多种类型的读者服务时，有一条重要原则是值得一提的，在点击一个链接之前用户应该对它的去处有一个大概的了解。例如，当看到“用户文档”的链接时，明显应该是链接到用户文档，而不是开发者文档。运作一个项目一方面是为了提供信息，但同时也是提供舒适。当用户和开发者们正在犹豫要不要加入时，你应该在预期的地方用一套肯定性的标准来使他们安心。它表明项目有统一的管理，已经预估到了人们可能提出的问题，并且致力于在只花费提问者最少的精力的前提下来解答这些问题。通过显现这种充分准备的氛围，该项目发出了一个信息：“如果加入，你的时间不会被白白浪费，”而这正是人们想听到的。但首先环顾四周开始一个开源项目之前，给你一个重要的告诫：一定要找找看是否有一个现存的项目已经做了你想做的。有很大的几率有人早于你已经解决了你想解决的问题。如果他们已经解决了它，并且在一个自由许可证下发布了他们的代码，那今天你就没有必要重新发明轮子了。当然有例外：如果是为了练习才开始一个项目，那现有的代码对你没用；或者你脑中的计划非常特别，你肯定不会有其他人有同样的想法，那你也不妨试试看。但总的来说没有理由不先看一看，而收获总是很大。如果常见的互联网搜索引擎发现不了什么，试试在（一个开源项目的新闻站点，有关它的更多介绍将在后面提到）和上找找看，同时自由软件基金会有一个自由软件的目录在。即使你找不到跟你的想法一模一样的项目，你也许能找到十分接近的，然后加入这个项目为它增加功能比你自己从零开始一个项目要更有意义。从你所拥有的开始你环顾了四周，没找到真正适合你的软件，因而决定开始一个新的项目。现在应该做什么呢？开始一个自由软件最难的部分是将个体的设想转化传达给公众。你或是你的团体也许对要做的事情已经十分明了，但是将这一目标清楚地传达给世界还需要付出一番努力。然而，那是必须花时间做的事情。你和其他的创建人必须决定你们项目的作用—也就是说，划定项目的范围，做什么，不做什么—然后撰写一份项目任务陈述。这部分通常不太难，但有时候能暴露出一些有关项目本质的臆想，甚至于分歧，那也没关系，现在解决这些问题总比拖到以后好。下一步就是将项目打包展示给公众，而那纯粹是单调乏味的工作。之所以这样说是因为打包的工作就是把大家都已经知道的东西组织和编辑成文件—这里所说的“大家”指的是到目前为止参与项目工作的人。因此，对于那些做这项工作的人来说，没有什么立竿见影的好处。他们并不需要一个README来了解整个项目的概况，也不需要一个设计文件或是用户手册。他们不需要仔细排列好的，与非正式而又普遍采用的软件源码发布方式相一致的代码树形图。对他们来说，无论代码怎么安排都没问题，因为他们已经对此十分熟悉，只要源码能够运行，他们就知道怎么用。甚至于，项目最根本的设计设想没有做成文件对他们来说也是无关紧要的；因为他们对那一方面也很熟悉了。然而，新参与的人需要这些东西。好在他们并不是在一开始就需要全部的资料。在一个项目公之于众之前，你不必提供每一个有关的细节。在一个理想的世界里，每一个新的开源软件项目在开始的时候就具备了一个详细的设计文件，一套完整的用户手册（对已经计划好但还未实施的特性有特别的标识），漂亮地而又可移植地打好了包的代码，并且还可以在任何电脑系统平台上运行等等。然而在现实当中，做好上述各项工作是非常耗费时间的，可是一旦项目启动之后，这些工作可以指望一些自愿人员协助完成。重要的是必须做好展示这一步，以便新的参与者能够顺利通过开始时因对项目不熟悉而造成的障碍。设想自举过程中的第一步，就是将项目启动所需的能耗降到最低点。我听说过人们用切入能耗这个词来形容这一开端：即一个新的参与者在收获之前所必须付出的能量。一个项目的切入能耗控制得越低越好。你的首要任务就是将切入能耗降低到能够鼓励人参与项目工作的水平。以下各小节分别描述了开始一个新项目的一个重要的方面。排列顺序大致是按照一个新的访问者将遇到的情形安排的，当然你在实际操作时可以不按照这个顺序进行。你可以将它们看作是一个检查列表。当你开始一个项目时，只要一一检查，确保每一步骤都做到了，或者在你省略某一部分时，至少你对将来可能出现的后果有把握就行了。选择一个好名字设想你是另外一个人，恰好听说过你的项目，或者是是在搜索一个软件来解决某个问题时碰巧看到了你的项目。他首先看到的是项目的名字。一个好名字不会自然而然地使你的项目成功，而一个不好的名字也不会终结你的项目—当然了，一个真正糟糕的名字也许会，但是让我们首先假定谁也不会迫不及待地让自己的项目失败吧。确实，一个不好的名字会延缓他人接受该项目的速度，要么是因为人们不会认真对待它，要么是因为人们很难记住它的名字。一个好名字：告诉人们有关项目性质，或至少名字与性质是明显相关联的一些概念，这样人们看到名字时就知道了项目能做什么，那么人们以后便很容易想起这个名字。便于记忆。在此，我们必须承认英语实际上已成为网络默认语言这一事实。“便于记忆”就意味着“便于能阅读英语的人记忆”。例如，某一非英语发音的双关语对于该语言之外的许多能阅读英语的人来说是很难理解的。要是这个双关语特别精彩并且令人难忘，那或许值得一试；但必须记住，这个名字在许多人的脑海里并不会产生在母语人士身上所有的效果。不与另一个项目重名，也不侵犯任何商标权。这既表现职业美德，也是良好的法律意识。你要避免制造身份混乱。即便没有不同的东西重名的现象，我们现在要搞清楚网络上已有的东西已经很不容易了。在前面里提及的资料有助于你发现是否另一个项目已经采用了你正在考虑的名字。免费的商标搜索见和。尽可能成为.com、.net、以及.org顶级域中的一个域名。你应该选择其中的一个，或许是.org吧，作为项目正式的网址；而另外两个网址都转发到前一个，这还可以防止其他人用项目的名字制造身份混乱。即使你打算将项目放在其它的网站空间上，（见），你仍然可以注册自己项目的域名，而转发至你存放项目的主页上。对用户来说，使用一个容易记忆的URL是十分有帮助的。有一份清楚的使命陈述人们找到了项目的网页之后，下一步就要看一份简短的项目描述，即使命陈述，以便（在30秒之内）决定他们是否对该项目有兴趣并获取更多信息。因此，这份使命陈述必须放在首页显著的位置，最好是紧贴着项目名字的下方。使命陈述必须具体，紧凑；而最重要的是简短。以下是一个很好的例子，来自：

创建一个以社区为基础，领先的国际化办公室套件，能够在所有主要的平台上运行，并借基于API和XML文件格式的开放组件，提供对所有功能和数据的接入性。

这份使命陈述仅仅用了简短的几句话，通过大量依赖读者已有的知识明白无误地传达了所要传达的信息。 “以社区为基础”表明该软件不受任何一家大公司控制其开发；“国际化”指的是该软件允许人们在本地及多种语言环境下工作；“所有主要的平台”说的是该软件可移植到Unix，苹果和视窗操作系统。其余的文字则说明开放接口以及易读的文件格式都是该软件目标中重要的组成部分。这份使命陈述并没有在字面上告诉读者它旨在成为微软Office的开源替代品，但是人们从字里行间便能看出它的含义。乍一看，这份使命陈述似乎有些空泛，但实际上界定得相当明确：“办公室套件”对那些熟悉这个软件的人来说是非常具体的东西。在此，读者已有的知识（这里指的是读者有可能对微软Office软件的了解）又一次用来把使命陈述变得简洁明了了。一份使命陈述的性质不单单是由它所描述的软件决定的，而在一定程度上得看是由谁来写的。例如，OpenOffice.org使用"以社区为基础"这个词是很有道理的，因为这个项目最初是由Sun Microsystems发起，而至今仍主要是由这家公司赞助的。在其使命陈述中使用"以社区为基础"这几个字，Sun表明它对一些担心该公司有可能试图垄断开发这一软件的忧虑是有敏感度的。这样的处理方法，即表明对一个有可能出现的潜在的问题有意识，就给将来完全避免这个问题的出现奠定了很好的基础。话又说回来，如果项目并非由一家大公司赞助，那或许根本不需要这样的词语；说到底，社区开发已经成为今天的模式了，因而没有理由要特别将那样的词语写在使命陈述中。声明项目是自由软件看过使命陈述之后仍对项目有兴趣的人自然想要了解更多的情况，或许要看一看用户文件和开发人员文件，最终可能下载一些东西。但在做这些事情以前，他们要确定这是一个开源项目。网站的首页必须清清楚楚地写明这是一个开源项目。这看起来好像无需加以强调，但是你会惊讶有多少项目忽略了这一点。我见过不少自由软件网站，其首页不但没有说明该软件是在哪一个自由许可证下发布的，而且根本没在首页表明这是一个自由软件。有时候这一至关重要的信息被次要地放在了下载页，或是开发人员页，或是其它的一个需要多点击一次鼠标才能看到的一个地方。在一些极端的例子中，网页上哪儿都找不到自由许可证—只有下载软件打开之后才能看到。别犯这个错误。这一忽略有可能让你失去许多潜在的开发人员和用户。务必在首页，也就是使命陈述的正下方，声明该项目是“自由软件”或是“开源软件”，并注明确切的许可证。有关选择许可证的快速指南，见本章后面的，而有关许可证问题的详细讨论见。至此，我们假想中的访问者已经决定—或许在随后的一分钟之内—他打算至少再花5分钟的时间研究一下这个项目。下面几个小节要描述他在之后的5分钟里将遇到的情形。特性和需求列表你应该列出一个简短的清单，说明软件支持的各种特性（如果某些特性还未完成，也可以列出，但是在旁边注明计划中”或“建设中”），以及运行该软件所要求的系统环境。列这份清单时，你只要设想一个人请你简短地介绍这个软件的特性/需求是什么。通常，那只是按照逻辑对使命陈述作进一步的扩充。例如，使命陈述可能写的是：

创建一个全文索引器并配备丰富API的搜索引擎，用于编程人员搜索大批量文本文件。

特性和需求清单将列出更详细的内容，对使命陈述的范围加以说明：

特性：搜索纯文本，HTML和XML文件字或词搜索（计划中）模糊匹配（计划中）增量更新索引（计划中）索引远程站点需求： Python 2.2或更高版本足够的硬盘空间以储存索引（大约原文件大小的2倍）

有了这样的信息，读者便能很快地决定这个软件是否适用于他们，也可以考虑是否以开发人员的身份参与其中。开发状态人们总是希望了解一个项目的状况。对新的项目，他们想知道项目的承诺和现实之间存在着多大的距离。对成熟的项目，他们想知道维护得如何，新发布的频率怎样，以及对Bug报告反应的及时性等等。要回答这些问题，你应该建立开发状态页，列出项目的近期目标和需求（例如，需要具备某方面专长的开发人员）。开发状态页也可以列出过去发布的记录，其中包含特性清单，以便访问者了解项目是如何定义“进展”的，并根据这一定义了解项目进展的速度。别因为你的项目看起来没准备好而感到害怕，也不要向夸大开发状态的诱惑妥协。谁都清楚软件是分阶段开发的产品；你不必觉得难以开口说出：“这是仍带有Bug的alpha软件，它可以运行。而且至少有时候能正常工作，但你使用这个软件就得自己承担风险。”这类语言不会吓跑你在这个阶段需要的开发人员。然而，对于用户来说，最糟糕的事情莫过于在软件准备好之前就吸引用户。一旦冠上了稳定性差或是Bug多多的名声，软件就很难再正名了。采取保守的策略对长远的目标是非常有益的；软件的稳定性超出用户的预期总比达不到用户的期望好得多，而给用户惊喜就会给产品带来最佳口碑。 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数据库，或者Bug数据库里空空如也的项目给予人们更好的印象。当然，如果你的项目刚刚起步，那么Bug数据库里就只有为数不多的Bug，而对此你也没有什么办法。但是如果在开发状况页强调项目仍处于初创期，且人们看到bug数据库里大多数的文档都是近期建立的，他们便可以由此推断出该项目仍然有良好的解决率，也就不会因为看到相对较低的已经记录的Bug绝对数量而产生不适当的警觉。请注意Bug跟踪系统的用途不止追踪软件的Bug，而且也用来跟踪扩展请求，文档变更，待解决的任务，以及其它一些问题。运行一个Bug跟踪系统的详细内容见中的，所以在此我就不赘述了。重要的是，Bug跟踪一定要显示出来，而且要确保项目的首页上便能看到这一点。沟通渠道项目的访客通常都希望知道如何能联系上参与项目的有关人员。提供邮件列表地址、聊天室、IRC频道、以及任何其它形式的论坛，以便其他参与项目的人同样可以联系上。告诉人们你和项目的其他有关人员都在邮件列表上，因而人们便知道他们有途径将回馈传递给开发人员。你在邮件列表上并不意味着你承诺回答所有的问题，也不等于你要满足所有人提出的有关特性的要求。长远来看，大多数用户或许根本从不参与论坛，然而，如果他们知道他们需要的时候可以那样做，那对他们就是一种欣慰。在项目开发初期，没有必要将用户论坛与开发人员论坛分开。更好的办法是让所有与软件有关的人员在“同一间屋子”里进行交谈。在早期使用软件的人当中，开发人员与用户之间的界线通常很模糊；不是没有界线，但是开发人员与用户之间的比例在项目早期远远高于后面的阶段。尽管我们不能假设每一位早期与项目有关的人都是想要介入软件开发的编程人员，但是我们可以肯定他们至少很有兴趣地关注项目发展中进行的讨论，并了解项目发展的方向。由于本章只讨论项目的初建，所以在此我们只要说明有必要建立以上所说的交流论坛就行了。稍后，在中的，我们将讨论在什么地方以及如何建立这样的论坛，及可能需要的协调和其它方面的管理，另外，在时机成熟的时候，如何分离用户与开发人员的论坛而避免造成无法逾越的鸿沟。开发者指南如果有人考虑参与项目，她会寻找开发者指南。与社会性文档相比，开发者指南通常没有很多的技巧：只需要解释开发者之间，以及与用户之间如何交互，以及如何最终完成任务。这部分的细节可以看中的，但开发指南的基本元素包括：与其它开发者交流论坛的链接报告Bug和提交补丁的指导说明进行开发的方法—项目是仁慈专制、还是民主的、还是其它。对于“专制”这里没有任何轻蔑的含义。如果存在一个开发者对所有变更拥有否决权，这完全没有问题。许多成功的项目以这种方式进行。关键是项目能够说出来它的做法。一个假装民主的独裁会让人厌恶；如果独裁者只要有能力并被信任，一切都会很好。完整的开发者指南实例可以看，或者是更加关注管理和参与精神，而较少关注技术事务的。为程序员提供单独的软件指导的问题会在本章后面的讨论。文档文档非常必要。需要有一些用户可以读的内容，即使它非常基本和不完整。在初期这样做确实是一件“苦差事”，经常成为新开源项目的第一个失败之处。提出使命声明和特性列表、选择一个许可证、概述开发状态—这都是相对的小任务，完成后通常可以不必返回继续工作。而另一方面，文档永远没有真正的结束，这可能也是人们总是延迟开始文档的一个原因。一个隐伏的事实是，文档对于编写者的功用与阅读者的功用是相反的。对于初始用户来说最重要的是基础文档：如何快速配置软件，软件如何工作的概述以及一些常规操作的指导。而这些通常是编写者所非常熟悉的内容—以至于很难从读者的角度看问题，因而他们不会费力去表述一些非常明显而不值一提的步骤。对这个问题没有神奇的解决办法。必须有人坐下来写好内容，然后交给普通的用户来验证它的质量。使用简单和容易编辑的格式，例如HTML、纯文本、Texinfo或一些XML的变种—便于在激励下可以轻型和快速的作出改进。这不仅是为了消除最初作者进行增量改进所带来的代价，也是为了希望修改文档的新加入者。一个保证基本初始文档完成的方法是预先限制其范围。这种方法至少不会让我们感觉是在完成一个开放结尾的任务。一个经验是它必须达到下面的最低标准：告诉读者他们所需的技术技能。清楚和完整的描述如何配置软件，并在文档的开头部分告诉用户如何运行确认安装成功的诊断测试或简单命令。启动文档有时候比使用文档更重要。一个人投入到软件安装和开始的努力越多，她就越有可能持续的搞明白没有很好文档描述的高级功能。当人们放弃时，他们会很早就放弃；因此，在早期阶段，例如安装时，需要最多的支持。提供一个普通任务的教程式的实例。很显然，不同任务的例子越多越好，但是时间有限，最好还是选择一个任务并完整的完成它。一旦人们看到这个软件可以使用，他们会开始探索其他需要的功能—如果你足够幸运，他们会自己补充文档。这将会让我们到下一点... 标示文档中未完成的部分。通过向读者展示这些不足，可以实现你与他们观点的联盟。你的移情作用可以使他们恢复信心，不必为确定什么是项目最重要的事情而挣扎。这些标示不需要承诺填补这些空白的期限—它等于是合情合理的公开征集志愿者。最后一点更广泛重要，也更实际，并可以应用到整个项目中，而不仅仅是文档中。开源领域中一个都知道的问题就是项目规范。你不必夸大项目的这种短处，你只需小心冷静的识别出需要这种规范（说明文档、Bug跟踪数据库或邮件列表讨论中都可以）的场景。就项目而言，没有人会视其为失败主义，也不会认为这是对在特定日期完成的承诺，除非项目明确作出这种承诺。因为使用软件的所有人都会发现这种不足，他们最好能在心理上做好准备—然后项目就有了解决这些问题的坚实知识。维护FAQ 一个FAQ（“常见问题列表”）就教育意义的回报来讲，可能是最好的投资之一。非常提倡将FAQ调整为用户和开发者实际提出的问题—而不应该是你期望他们提出的问题—因此，一个维护良好的FAQ可以让咨询者从中准确的找到寻找的答案。在遇到问题时，FAQ通常是用户首先查找的地方，甚至比正式手册更受人偏爱，可能成为其他站点链接最多的文档。但很不幸，你不可能在项目的开始就完成FAQ。好的FAQ不是写成的，而是长成的。它们是通过定义响应文档，随着人们对软件的日常使用而进化。因为不能预感到用户将会提出的问题，所以我们无法从头开始编写有用的FAQ。因此，不要在这方面浪费时间了。但无论如何，你或许会发现创建一个FAQ的空白模板会很有用，很明显这样可以帮助人们在项目进行中贡献问题和答案。此时，最重要的性质不是完整，而是方便：如果添加FAQ非常简单，人们就会去添加。（正确的FAQ维护应该是特殊和迷惑性的问题，将会在的详细讨论。）文档的可用性在两个地方必须有文档：在线（直接在网站上），以及软件可下载分发版本（见的）中。它必须以可浏览的形式在线，因为通常人们会在第一次下载软件之前首先阅读文档，以决定是否下载。但是也必须和软件配套，因为原则上下载中必须包括使用软件包的所有必须内容。对于在线文档，要确定有一个指向包含完整文档的（请在链接旁注明"monolithic"或"all-in-one"或"single large page"，以提醒人们知道需要更长的下载时间）单独HTML页的链接。这是因为人们经常会在整个文档中寻找特定的词汇或短语。通常是他们已经知道他们在找什么；只是记不住具体的章节。对于此类人，最郁闷的就是遇到一个目录页面、然后是指导页面、然后是安装指导等等。当页面是如此琐碎时，浏览器的搜索功能将变得毫无作用。分页的样式适合那些知道他们所需章节，或是从头到尾阅读的人。但这不是访问文档的常规方式。通常是某人已经熟悉了软件，返回来搜索特定的词汇或短语。如果未能提供一个单独的、可搜索的文档会让他们活的很辛苦。开发者文档开发者文档主要为了帮助程序员理解代码，从而修改和扩展软件。这与更关注社交性而不是技术性的开发者指南有些许不同。开发者指南告诉程序员如何与代码本身打交道。为了方便，这两个文档通常会整理为一份文档（例如前面提到的），但是这不是必须的。尽管开发者文档可能很有用，但也没有为了它而影响发布。只要原始作者还在而且愿意，就可以回答关于代码的问题，一开始这就足够了。实际上，反复回答相同的问题是编写这个文档的动力所在。但即使文档还没有写，坚定地参与者也依然会设法以自己的方式处理代码。驱使人们花时间研究代码基的原因是他们发现这些代码对他们有用。如果人们相信这一点，他们就会花时间去搞明白；如果他们不相信，再多的开发者文档也留不住他们。如果你有时间为一个读者写文档，那还是写给所有用户吧。所有用户的文档，和开发者文档有同样的效果；为软件工作的程序员一定对如何使用也非常熟悉。之后，当你看到程序员反复询问相同的问题时，你就应该为他们编写单独的文档。一些项目使用wiki作为初始文档，甚至作为他们主要的文档。在我的经验里，只有文档是被少数认可文档的组织方式和包含内容的成员编辑时，才能正常工作。更多细节在的。输出和屏幕截图实例如果一个项目包含图形化的用户界面，或者生成图形和其他特别的输出，那么就应该将这些样例放到项目网站上。如果是界面，那应该是截图；对于输出，可以是截图或只是文件。但是为了迎合人们立刻满足的需要：一个单独的截图比大段描述文字和邮件列表的唠叨更让人信服，因为截图是软件能正常工作的不容争辩的证据。它可能充满bug、可能难于安装、可能文档不全，但是截图是一个人投入足够的精力，可以使之运行的证据。屏幕截图如果没做过截图，可能会感觉有点麻烦，这里是一些制作截图的基本指导。使用Gimp（），打开File->Acquire->Screenshot，然后选择Single Window或 Whole Screen，然后点 OK。然后你的下一次鼠标点击就会捕捉窗口或屏幕，成为Gimp的一个文件。如果必要，还可以对图像进行剪裁和大小调整，相关指导在。还有一些东西需要放置到网站中，如果你有时间，或者如果出于某种原因而显得特别合适：一个新闻页、一个项目历史页、一个相关链接页、站点搜索特性和捐赠页等等。开始时这些都不是必要的，但将来要一直留意。包装主机有一些站点为开源项目提供免费的主机和基础设施：web站点、版本控制、bug跟踪、下载区、讨论论坛和定期备份等等。具体细节站点之间各不相同，通过使用这些站点，你可以免费得到基础服务。但是很明显你也同时放弃了通过用户经验，来进行细化控制的能力。主机服务决定了站点运行的软件，也控制了或至少影响了项目站点的感观。的是包装主机优缺点的详细讨论，也有提供这种服务的站点列表。选择许可证并应用这部分是关于选择许可证的快速粗糙指南。阅读可以理解不同许可证的法律含义细节，以及这些许可证如何影响人们将你的软件与其他自由软件混合的能力。确实有大量可供选择的许可证。其中大多数我们这里不必讨论，因为他们通常是为了满足公司或个人的特定法律需求，不会适合你的项目。我们会限制为大多数常见的许可证；大多数情况下，你会从其中选择一个。 “可以做任何事情的”许可证如果你能够接受你的项目代码会潜在的使用到私有程序中去，可以选择MIT/X-样式的许可证。这是一些最小许可证中最简单的一种，只保留署名版权（实际没有限制拷贝）并指明代码没有任何保证。细节见。 GPL 如果你不希望你的代码在私有程序中使用，可以使用GNU的通用公共许可证。GPL可能是当世最广泛公认得自由软件许可证。在本质上是一个巨大的优势，因为许多潜在的用户和贡献者已经对此许可证十分熟悉。更多细节看的。如何为你的软件应用许可证一旦你选择了一个许可证，你必须在项目首页注明。你不必引入许可证的实际文本；只需要提供许可证的名称，并提供到完整许可证文本的链接。这告知公众你希望软件按照何种许可证发布，但是对于法律目的还不足够。这个软件本身必须包含许可证。一个常见的做法是将许可证全文保存到一个叫做COPYING（或LICENSE）文件中，其中包含了许可证的全文，然后还要注意在每个源文件的开头，注明版权日期、所有者和许可证，以及何处可以找到版权全文。这个模式也有许多变种，所以我们这里看一个实例。GNU的GPL说可以在每个源文件的开头放置如下的提醒： Copyright (C) <year> <name of author> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 并不是说随程序收到的许可证拷贝在文件COPYING中，而是它通常放置在那个地方（你可以在上面的声明中直接注明位置）。这个模板给了获取许可证版权的地理地址。另一个常见的方法是提供包含许可证的网页链接。只要使用你的判断并指出你认为版权能够永久保存的位置，也可以是你项目网站的某个位置。一般来说，你在每个源文件放置的通告不会和上面这个完全一样，只需要其包含版权持有者和日期，以及版权的名称，并明确指明完全许可证的位置即可。设置风格我们已经覆盖了配置项目时的大多数一次性任务：选择一个许可证，安排初始的网站等等。但是开始一个新项目时最重要的方面是会变化的。选择一个邮件列表地址很容易；而保证列表的对话不走题且有效率则完全是另一回事情。如果项目经过多年的关闭，内部的开发，重新开始时开发过程将会改变，你需要准备开发者来应对这种变化。第一步是最难的，因为未来管理的先例和预期都没有设置。正式的规则还没有带来项目的稳定性，而是由开发过程中共享的难以稳定的团体智慧带来。也许有已经写好的规则，但通常是通过难以预料的，不断进化的协议来引导项目。写好的规则不能定义其描述的项目文化，即使后来也是近似而已。这里是如此解决问题的一些原因。成长和高转化率不会像一般人想象的那样损坏社会规范的积累。只要变化不要太快，就有时间让新来者学会如何做事，在他们学会之后，他们自己就会来加强这种方式。考虑一下数世纪以来儿童歌曲的发展。现在孩子们演唱的歌曲和几百年前有大致相同的韵脚，即使现在的孩子从来没有生活在那个时代。小点的孩子听到大点的孩子唱歌，然后当他们长大了，他们又会在更小的孩子面前演唱。孩子不是故意参与这个传递程序，当然，这些歌曲的传承确实是因为有规律和重复的传递。自由软件项目不会以世纪（我们还不能知道）作为测量的时间刻度，但是变化和传递非常类似。转化率更快，不管怎样，必须以更活跃和慎重的传递投入来作为补偿。人们通常会期望和寻找社会规范的事实，会成为这种努力的辅助。这也是人类的做法。在任何以共同努力统一的团队中，加入者都会凭直觉寻找可以将自己标记为团队一部分的行为。尽早设定先例的目标是让这些“组内”行为对于项目发生作用；一旦建立，多半会生生不息。通过特定实例，你可以设置好的先例。这不必是一个完整的列表，但是通过尽早设置这样的协作情绪的方法，可以大大的帮助项目。从物理上讲，每个开发者都在自己的房间独立工作，但是你可以设法让他们感觉是在一个房间一起工作。他们这样的感觉越多，就会在项目上花费更多的时间。我选择了这些例子，因为这些实例来自Subversion项目（），而我从一开始就参与并观察了这些实例。但是这不仅仅对Subversion有效；大多数开源项目中都会遇到类似的情形，这是开个好头的好机会。避免私下讨论即使你已经将项目公开，你和你的创始人也会经常希望通过私下讨论来解决困难的问题。这在项目的开始阶段尤其明显，因为此时需要做出许多重要的决定，而只有少量志愿者能够胜任。你会发现公开讨论的明显缺点：邮件对话本身的延迟性，需要保留足够的时间来达成一致，处理自以为是的幼稚的志愿者（每个项目都有；有些将来会成为明星贡献者，而有些会永远保持幼稚），也就是那些不能理解你为什么只希望解决问题X，而X明显是大问题Y的子集的人。秘密决定并使之成为既成事实，或者至少成为联合和有影响力的投票集团的坚实推荐，确实非常有吸引力。不要这样做。尽管公开讨论可能很笨重，但是从长远来看这样做更合适。私下里做出重要的决定就像是将贡献者排斥出项目一样。没有重要的志愿者会愿意呆在这样一个由秘密委员会做重要决定的环境里。此外，公开讨论也会从其副作用中获益，无论是多么短暂的技术问题，一经发起都会一直讨论下去：讨论有助于训练和教育新开发者。你不知道有多少双眼睛在关注着讨论；即使大多数人不会参与，仍然可能有很多人在静静的跟踪，收集软件的信息。讨论会训练你如何向不熟悉软件的人们解释技术问题。这种技巧需要练习，你不能从已经知道你所知道的人那里获得这种练习。之后，讨论和结论将会一直存放在公共归档中，可以保证以后的讨论不会回到同样的步骤中。见的。最后，很有可能某个人会提出一个你从想到过的好主意，给对话带来真正的贡献。很难说这有多大的可能；这仅仅由代码的复杂程度和需求的专业程度决定。但是如果允许我使用轶事作为证据，我会证明这样做比直觉所期望的结果更好。在Subversion项目，我们（创始人）相信我们面对的是一组深入而复杂的问题，为此我们痛苦思考了几个月，我们很明确的怀疑在新建立的邮件列表中的会有任何人做出真正的贡献。所以我们选择了一条比较懒惰的方式，开始通过私下邮件讨论技术想法，直到项目的一个观察者我们这里不是为了还债，而是实践我前面讲的说教：这位观察者的名字是Brian Behlendorf，他指出了除隐私原因以外，保持所有讨论公开的普遍重要性。嗅出了问题，并要求将讨论公开。眨了眨眼我们这样做了—后来的结果让我们十分惊讶，我们很快便获得了许多有见地的回复和建议。大多数情况下人们提供的想法都是我们从来没有想到的。结果是邮件列表中一下子多了许多非常英明的人；他们只是在等待正确的诱饵。可以肯定地是公开讨论比私下讨论会保持更长的时间，也能得到更多的产出，花费额外的时间是值得的。我们不必把问题总结为：“团结就是力量”（我们已经见过许多更成功的团队），但可以确认的是有一些事情适于在团队中完成。首先是有了大量的审阅；其次是快速产生大量的想法。想法的质量由其所针对的思想决定，当然，在你用挑战性的问题刺激他们之前，你无法判断这些思考者是那种人。当然，也有许多讨论必须在私下进行，通过此书我们会看到这种例子。但是我们有一个指导原则如果没有保持秘密的原因，那就公开进行。要想使之发生，我们需要行动。仅仅保证自己所有的通告公开是不够的。你也需要劝说其他人放弃不必要的私下讨论。如果某个人尝试开始没有必要的私下讨论，你要义不容辞的立刻进行恰当的元讨论。在你将讨论成功的引入公开场所之前，不要对原始主题做出任何回复，或者去确定私下进行是否必须。如果你一贯如此，人们会很快会意，并开始首选公开论坛进行讨论。防无礼于未然从项目的一开始，你就应该保持论坛中粗鲁和无礼行为的零容忍。零容忍不是指技术上的实质强制。当有人侵犯其他用户，你不需要将其从邮件列表中删除，或因为其无礼的回复而收回其回复权限。（理论上讲，可能最终你必须诉诸这类行动，但应该是其他方法失败之后才采用—这需要清晰的表述，而不应该是项目开始的情况。）零容忍指的仅仅是决不漏掉任何此类坏行为。例如，有人发布的技术回复中掺杂了对某一个项目开发者的个人偏好的攻击，首先你应该紧急回复来指明这种个人偏好的攻击，并指出作为技术问题本身，应该只包含技术内容。不幸的是这并不很容易，更普遍的是，建设性的讨论演变为破坏性的论战。人们会在邮件里谈事情，而永远不会面对面谈论。讨论的主题只是放大了这种效果：在技术问题中，人们经常感觉对大多数问题有一个唯一的答案，而对此答案的异议只能被解释为无知或愚蠢。某人技术提议的愚蠢与某人本身的愚蠢不算太远。实际上，有时候很难说出技术争论和人身攻击从哪里开始，这也是激烈回复或惩罚不是好主意的一个原因。相反，当你发现此类事件发生，你应当回复来强调保持友善讨论的重要性，而不要指责任何人是故意为害。可惜这种“软规则”回复有点像幼儿园老师教导学生学习好的行为：

首先，请减少带有个人倾向的回复；例如，称J的安全层设计对“计算机安全基本原理的幼稚和无知”。这样说对错都有可能，但是无论何种情况，我们都无法进行讨论。J真心诚意地提出意见。如果存在Bug，请指出来，我们会进行修正并得到新的设计。我确定M对于J并无人身攻击，但是措辞是不合适的，我们会努力保持事务的建设性。现在，对于这个建议。我认为M所说的是正确的...

因为此回复的不自然，会有显著的效果。如果你对于坏的行为保持一贯的行动，而不是要求攻击方进行道歉和承认，这样就让人们可以自由的冷静下来，而在下一次能够表现的更有礼貌一点—他们会的。这样做能成功的诀窍是不要将元讨论作为主题。它必须放在一边，成为回复主要部分的简短序言。通过顺便提及指出“我们这里不是这么做的”，然后转移到真正的内容，这样你就给了人们一些可以回复的话题。如果有人抗议他们不应该受到你的责难，只需要拒绝讨论这个问题。除了不回复（如果你认为他们只是精力过剩，不需要回复），也可以说你为反应过度而道歉，而且在邮件中很难感到这种微妙之处，然后回到主题。绝不在任何时候要求一个人为不合适行为作出承认，无论是公开还是私下的。如果他们选择随自己的意愿进行道歉，那样很好，但是要求他们那么做只会导致怨恨。总体目标是将好的礼节视为“团队内”的行为。这可以帮助项目，因为开发者会由于论战而流失（即使是他们喜爱和希望提供支持的项目）。你可能甚至不知道他们为什么离开；有些人可能一直潜伏在邮件列表，考虑到加入到项目需要的厚脸皮，就会决定放弃加入。保持论坛的友善是一个长期生存策略，在项目还比较小的时候，这很容易。一旦这成为了文化的一部分，你就不是唯一提升这种文化的人。所有人会一起维护。实践明显的代码评审促进开发生产率的一个最好的办法就是让人们互相察看代码。需要一些技术基础设施来进行有效的支持—特别是提交邮件应该开启；更多细节见。提交邮件的作用就是每当有人提交了源代码的修改，就会发送一封包含日志信息和变更差异（见的）的邮件。代码评审是在代码来到时对提交邮件进行评审，寻找Bug和可能的改进的实践。无论如何，这是开源项目常见的做法。在更集中式的项目中，“代码评审”也也意味着许多人坐在一起，一起察看打印的源代码，寻找特定的问题和模式。代码评审同时满足多个目标。这是开源世界的同级评审中最明显的一个例子，直接促进维护软件的质量。软件的每一个Bug都是提交进来的，而且没有被发现；因此，关注的眼睛越多，将会带入越少的Bug。但是代码评审也有非直接的目标：它确认了人们所真正关心的东西，因为很明显一个人不会去花时间评审他不关心的功能。当人们知道会有人花时间评价他的工作，他们就会倾尽全力。评审必须是公开的。即使有时我与其他开发者坐在同一个物理房间，我们中的一个做出了提交，我们也尽量不在房间中进行口头评审，而是将其发送到开发邮件列表。所有人会从看到发生的评审获益。人们紧跟着评论，有时会在其中发现瑕疵，即使没有发现，这也会一直提醒他们评审是一个预期的，有规律的活动，就像刷盘子和割草坪。在Subversion项目，开始时并没有建立有规律的代码评审实践。无法保障所有的提交会得到评审，尽管如此，还是会有人在看到感兴趣的代码块时看一下修改。一些小Bug确实能够，也应该被发现。一个叫Greg Stein的开发者，从以前的工作知道代码评审的重要性，决定通过评审每个单独提交到源代码库的每一行来设立一个范例。每当有人提交，邮件列表就会紧跟着出现Greg的邮件，解剖这次提交，分析可能的问题，偶尔还会赞扬一下聪明的代码。很快，他就发现了其他人会略过而不会注意的Bug和非最优的代码实践。更深刻的是，他从没有抱怨他是唯一评审所有提交的人，尽管这样做占用了他很多时间，但是他确实一有机会就会盛赞代码评审。不久之后，其他人，包括我也开始了有规律的提交评审。我们的动机是什么？不是Greg有意识的让我们为此感到羞愧。而是他已经证明代码评审是值得花费时间的方法，它的贡献与编写新的代码不相上下。一旦他证明了这一点，它就成为预期的行为，以至于如果一个提交者发现没有人对其提交有任何反应，他会感到担心，甚至会在列表中讯问是否有人愿意花时间为其评审。不久之后，Greg得到一个工作，他也没有更多时间为Subversion工作，结束了有规律的评审。但是之后，他的习惯深深影响了我们，似乎这样做是天经地义的。从第一个提交就开始评审。差异评审中最容易检查出来的问题包括安全漏洞、内存泄露、注释不足或API文档问题、位偏移错误、调用/被调用不匹配以及其他在较小的上下文就能发现的问题。然而，即使这类未能将重复的模式抽象到一处的较大规模问题，在经过有规律的评审后也可以被定位出来，因为对以前差异的记忆提醒了对当前差异的评审。不要担心你未能发现任何需要回复的内容，或者你不是很清楚代码的每个部分。通常几乎每一次提交都会要说什么事情；即使你没有发现任何事情可以提问，你还是可能发现一些事情可以对其称赞。最重要的是让每个提交者清楚，他们所做的事情都正在被关注和理解。当然，代码评审不能让程序员逃脱在提交之前评审和测试他们所做变更的责任；人们不应该依靠代码评审来捕捉本应该他自己捕捉的问题。将一个封闭项目开放时，对于改变的影响要格外敏感如果你开放一个已存在的项目，其中已经有了许多习惯于在封闭源代码环境下工作的活跃开发者，你必须确保每个人理解正要发生的重大变化—你必须设身处地的为他们着想。想象一下他们面对的情形：以前，所有的代码和设计决定都是由一组程序员做出，他们对软件有差不多相等的熟悉程度，而且都是从同一个管理中接受相同的压力，而且清楚其他人的长处和弱点。现在你让他们将代码暴露给随机的陌生人监视，而他们只会根据代码形成判断，而不会考虑造成这种决定的商业压力。这些陌生人会询问很多问题，这些问题让已有的开发者发现无论如何为文档苦干，仍然不足（不可避免的）。最关键的是，这些新来者是未知的，未露面的实体。如果你的一个开发者已经感觉到他的技艺不够安全，想想一下当新来者指出他所写代码的Bug时的严重性，更严重的，在他的同事面前。除非你有一个拥有完美编码员的团队，这是不可避免的—实际上，对于每一个人开始都会发生这种情况。这不是因为他们不是好程序员；只是因为任何超过一定规模的程序都会有Bug，而同级评审可以发现一些此类Bug（见本章前面的）。而此时，新来者开始本身并没有受到同级评审的支配，因此他们在熟悉项目之前不能贡献代码。对你的开发者，感觉指责正在到来，绝不会离开。因此，要小心这些老手的人心散了。防止发生这种情况的最佳方法是警告每个人即将发生的情况，告诉他们开始的不适是完全正常的，鼓励他们一切都会好起来的。有一些警告应该在私下发生，在项目开放以前。但是你也会发现如果在公共列表中提醒人们会有好处，告诉他们这是项目开发的新方式，需要一段时间来调整。你能做的最好的事情是通过实例进行引导。如果你看到你的开发者无法回答足够多的新手问题，那么只要告诉他们回答更多也于事无补。也许他们对于何种问题需要保证回复没有太好的感觉，或者他们对于如何排定代码工作和新的外部沟通交流负担的优先级没有感觉。让它们参与进来的方法是你自己参与进去。作为一个公开邮件列表，确保在那里回答一些问题。当你没有回答某个问题的技能时，要明确的交给能做的开发者—然后观察确保有回答或至少是一个回应。当然现在还是有长期开发者进行私下讨论的诱惑，因为他们一贯如此。请确定你已经订阅了可能发生问题的内部邮件列表，并且告知他们此类讨论应该立刻公开。对于开放的封闭项目，还有一些其它的长期关注。探索了混合付费和未付费开发者的技巧，讨论了当公开的私有代码基包含其它组织编写或“拥有的”软件时所必须承担的法律义务。通告一旦项目可以展示了—不必完美，只要能看—就可以将其通知给世界了。这是一个非常简单的过程：来到，在顶端的导航栏点Submit，然后输入你的新项目的通告。Freshmeat是一个大家关注新项目通告的地方。你只需要在那里用项目新闻抓住一些眼球，就会众口相传。如果你知道某个邮件列表或新闻组会对你的项目合题或感兴趣，那么请在那里通告，但请注意，一个论坛只有一个通告，将人们引向项目本身的论坛，进行后续的讨论（通过设定Reply-to头）。这种发布一定要简短扼要： To: discuss@lists.example.org Subject: [ANN] Scanley全文索引项目 Reply-to: dev@scanley.org 这是关于Scanley项目的一次性公告，Scanley是一个包含丰富API的开源全文索引和搜索引擎，主要为程序员提供对于大组文件的搜索服务。Scanley 现在是可运行的代码，正在进行活跃的开发，征集开发者和测试者。主页: http://www.scanley.org/ 特性: - 查找纯文本、HTML和XML - 单词和短语查询 - (计划) 模糊匹配 - (计划) 增量更新索引 - (计划) 索引远程网站前提条件: - Python 2.2或更高 - 包含索引的足够空间 (大约原始数据的2倍大小) 更多信息，请访问scanley.org。谢谢， -J. Random （有关后续发布版本，以及项目其他事件的通告建议，请看的。）对自由软件世界是否应该以一个可执行的代码作为开始，以及在设计/讨论阶段就进行公开是否有益还存在着争议。我过去认为从一个可执行的代码开始是非常重要的因素，这是成功项目和玩具的重要区别，慎重的开发者只会加入有一定事实的软件。但也有例外。在Subversion项目，我们从设计文档、一组核心的感兴趣和紧密联系的开发者、许多热闹的介绍和不能运行的代码开始。完全出乎我的意料，项目从一开始就获得了活跃的参与者，当我们可以运行什么时，已经有不少志愿开发者已经深入参与进来。Subversion不是唯一的例子；Mozilla项目也是从不能运行的代码开始，现在成为了成功和流行的web浏览器。面对这种证据，我必须回过头来看可运行代码是启动项目必要条件的断言。可运行程序仍然是成功的最重要基础，一个好的经验法则是直到可以运行再开始公告项目。然而，有一些环境下，尽早通告是有意义的。我想这时起码要有完成良好的设计文档，或其他代码框架—当然，这也许需要根据公共反馈调整，但是要有一些实际的东西，比好的意图更确切地东西，让人们可以动动牙齿。无论你何时通告，不要指望立刻有一大堆志愿者会到来。通常情况下，通告的结果是得到很少随意的询问，以及一些人加入你的邮件列表，除此之外，一切如常。但随着时间的流逝，你会逐渐发现代码贡献者和用户参与的增加。通告仅仅是播下种子。消息的传递需要很长时间。如果项目持续回报参与者，这个新闻就会传播，因为人们喜欢分享他们所发现的好东西。如果一切都好，指数级交流网络的动力会慢慢将项目改变为复杂的社区，你不必再知道每个人的名字，也不必跟踪每一次对话。下一章我们将讨论在这个环境下如何工作。