# Chapter 1. 介绍 大部分自由软件项目是失败的。 人们总不太喜欢听太多失败的故事，只有成功的项目才能吸引我们的注意力。林林总总的自由软件的总数是惊人的[[2](#)]，尽管只有一小部分的项目成功了，但这仍然只是那些广为人知的项目的一部分。有太多的项目由于不为人知，即使失败了我们也不会听到。我们无法用一个确定的时间点来宣判一个项目的死刑，人们只是停止工作无所事事。即使我们知道一个项目的最后一个变动是何时添加的，但是在当时那些做这些工作的人通常并不知道这会是最后的晚餐。我们甚至无法明确地定义何时一个项目才算是断气了。是停止活动6个月之后？是用户数量停止增长并且人数还少于开发者的数量时？当一个项目的开发者发现他们只是在重复别人的工作，而决定放弃项目，然后他们决定加入另一个项目，并且在项目中使用之前的一些工作成果？原先的项目死亡了，或者只是搬了一次家？ 因为是如此复杂，得出一个精确的失败率是不可能的。但是十多年以来流传于SourceForge.net或是用Google搜索得到的开源运动传闻，都指向同一个结论：这个比率是非常高的，也许能达到90–95%。如果把那些虽然存活但是内忧外患的项目算在内，这个比率还将更高，这些项目通常仍然*在*生产可执行的代码，但已不再是开发者的乐园了，要么是无法尽其所能的快速和互相依赖的作出进展了。 这本书的目的旨在说明如何避免失败。它不仅演示了如何才是正确的做事方法，而且告诉你错误出在何处，以便你及时发现和纠正错误。我希望在读过此书之后，你不仅能对如何避免开发过程中的常见陷阱有丰富的技术储备，而且对如何使一个成功的项目得到成长和维护有深入的了解。成功不是一场零和游戏，此书也不是教你如何在竞争中获胜或是领先的。相反，运作一个开源项目的重要部分就是流畅地同关联项目合作。在更高的层次上，每一个成功的项目都为在世界范围内自由软件的成长作出一份贡献。 如果说导致自由软件项目失败的原因类型与私有软件是相同的，那是令人诱惑的。实际上，在自由软件内不会有诸如建立在不切实际的需求上的垄断，含混不清的规范，可怜的代码管理，设计阶段不足等等笼罩在传统软件工业上的幽灵。有关这些主题的书已经是汗牛充栋，我不打算重复。我想做的是描述自由软件独有的问题。当一个自由软件项目开始运转，最常见的问题是开发者（或是经理）难以识别开源软件开发过程中的独特问题，尽管他们可能已经在那些闭源软件的常见问题上摔打了多年。 一个最常见的错误就是急于从开源的形式本身获得好处，但这是不切实际的。一纸开放许可证不会一下子让成群的活跃开发者自愿地把他们的时间交给你的项目，将一个原本问题多多的项目开源也不能自动地修正这些问题。实际上很可能相反，与不开源相比，开放一个项目短期内会带来一系列全新的复杂问题和代价。开放意味着要让完全陌生的人读懂代码，建立一个开发网站和邮件列表，通常还会第一次需要写文档。这些事情的工作量是相当大的。当然如果有开发者*表示*出了兴趣，在他们为你的项目带来好处之前回答他们的问题也是一个额外的负担。如同开发者Jamie Zawinski回忆Mozilla项目早期的混乱状况所说地： > *开源的确行，但它绝不是万能药。我对你的忠告是：你不能指望在一个垂死项目上洒一点"开源的精灵魔粉"就能让所有事情奇迹般地运转起来。做软件是困难的。问题不会那么简单。* > （来自**[http://www.jwz.org/gruntle/nomo.html](http://www.jwz.org/gruntle/nomo.html)**） 一个相关的错误是对展示和打包的轻视，特别是当一个项目顺利运转时总认为这些以后再做不迟。展示和打包有很多的目的，所有的一切都是为了减低进入的门槛。使项目对那些后来者有吸引力意味着编写用户和开发者文档，建立为新来者提供信息的网站，尽可能自动化软件的编译和安装工作，以及其他。很不幸，很多程序员认为与编码相比，这些工作都是次要的。导致这种情况的原因有很多。首先，他们感觉这些都是附加作业，因为对熟悉项目的这部分少数人来说，它的益处是显而易见的，反之亦然。毕竟这些编写代码的人并不真需要打包。他们知道如何安装，管理和使用这些软件，因为代码就是他们编写的。其次，展示和打包所需要的技术通常和写代码完全不同。人们总是倾向于专注自己所擅长的，即使另外的工作能对整个项目起到事半功倍的作用。 [Chapter 2, *起步*](# "Chapter 2. 起步")将详细讨论展示和打包，并且解释从项目的一开始就确定这些工作的优先地位的重要性。 接下来的一个谬误是认为开源几乎或完全不需要项目管理，或者照搬商业开发的那一套管理模式也能在开源中做得很好。在一个开源项目中，管理总是不起眼的，但在成功的项目中，它通常在幕后起到推动的作用。一个简单的心理试验就足够显示其原因。一个开源项目由来自四面八方的程序员组成—一群臭名昭著的自由独立思想者—他们中的大部分人从来没有互相见过面，为这个项目工作只是出于他们的个人目标。心理试验能很简单地预测如果*没有*管理，在这样一个团体中会发生什么。除非发生奇迹，否则他们很快就会四分五裂。事情不会如我们希望的那样自己运转。管理偶尔会相当活跃，但是大部分时候是非正式的，微妙的，低调的。只有一件事情能把开发者团结在一起，就是他们相信团队合作比单干能做得更多。因此最重要的管理目标是确保他们继续相信这一点，做到这点需要设定交流的标准，需要让能干的开发者不会因为个性而受到排斥，总之要使项目成为开发者的留恋之地。我们将在后面讨论这些工作需要的具体技术。 最后还有一种类型的问题也许我们可以称之为“文化引导失败”。十年之前，甚至五年之前，谈论自由软件运动的整体文化都还为时过早，但现在不是了。一种清晰的文化正在慢慢浮现，虽然它不是一个整体—如同很多地域约束的文化，易于产生内在的异议和派别—但它有一个基本的一致的核心。大部分成功的开源项目展示了这个核心中的部分或全部特质。他们奖励符合这种文化的行为，惩罚相反的；他们创造了一种鼓励计划外的参与氛围，甚至不惜中心协调时间的代价；他们对粗野和礼貌的概念与流行观念有本质上的区别。最重要的是，长期的参与已经内化了这些标准，所以他们能够对将要发生的举动能大体上取得共识。失败的项目通常显著的背离了这个核心，尽管并非本意，但通常是因为没有对建立合理默认行为方式达成共识。这意味着一旦问题出现，由于参与者缺乏通过弥补分歧而对问题做出反馈的现成文化储备，形势会迅速恶化。 此书是一本实用的指南，而不是一篇人类学论文或是史书。然而了解今天的自由软件文化的起源对任何一个实际的建议都是必要的基础。一个理解这种文化的人能在开源世界任意驰骋，即使遇到很多的各地风俗和方言，仍然可以自信和有效地参与。相反，一个没能很好理解这种文化的人将会在组织或是参与一个项目的过程中处处遇到困难和意外。由于自由软件的开发人员的数量仍然在飞速增长，其中有很多人属于后一种情况—这多半是一种新近加入的文化，并且会持续一段时间。如果你自认为是其中的一员，下一节为你在以后将在本书或是互联网上遇到的讨论提供了背景材料。（另一方面，如果你已经在开源中工作了一段时间，你也许早已了解了这段历史，你可以选择跳过这一节。）