假如您是一个程序员，在业余时间参与一个非常成功的开源项目。一般情况下，您下班回家后会检查信箱，如果发现有个新补丁被提交到该项目的Subversion知识库中，您就会认真审核该补丁。您可能会在邮件列表中讨论一个设计中的新特性的主题中跟帖，投票反对该特性，因为您觉得它会导致严重的潜在设计问题，您还会提出更好的方法以解决该问题。通常，您坚信：人们不应提交有缺陷的版本；新的捐献者应该能够很轻松地安装该软件；要让尽可能多的人审查代码，这很重要。您不是孤军奋斗。许多大获成功的开源项目就是以这种方式运转的，而且绝大多数开源开发人员认为这就是项目运转的正确方式。

如果您的职业是专业开发人员，那么在工作中您可能曾尝试引入其中的一些良好实践。如果是这样，则下面这些托辞对您来说应该很熟悉：“我们要开展业务”；“这些想法在理想世界中可能行得通，但我们需要把目光放在我们的代码上”；“以那种方式完成项目可能很不错，但我们没有时间”。只将参与成功的开源软件项目作为一种业余爱好，而以专业方式对待更有挑战性的项目，这真让人沮丧。

当人们谈及开源软件的好处时，第一个想到的就是吸引“更多眼球”：当更多的人认真查看代码，软件就会更完善。开源项目严重依赖于项目各个方面的公开讨论：哪些特性将会（或不会）被写入软件？什么是实现这些特性的最佳方式？如何保持设计灵活性和可维护性以利于后续增补？问题出现时如何解决？出现争论时，通常会以民主和开放的方式进行解决。通常，任何人都可参加讨论，而不管他们的资历以及在项目中扮演何种角色。最成功的开源项目往往是那些最大限度地坚持这些思想的项目。

GIMP项目就是一个绝佳的案例。其开发人员网站为软件开发的每一个方面制定了指导原则。该原则描述了该项目如何管理以及如何协作。该站点说明了开发人员如何使用CVS、如何提交补丁以及如何创建文档。其中有一个用于报告、筛选、修补和验证缺陷的流程。还有一些用于创建、包装、测试和发布新版本的标准。有一些用于通告、文档或供开发人员、用户甚至网站自己使用的邮件列表。有一些教程和常见问题解答，用于帮助新的开发人员弄清工作方向以及学习GIMP团队的工作方式。GIMP项目中的任何事情都由团队规划并一致通过。任何新的开发人员都可回顾历史，并详尽了解决策内容、决策人以及决策原因。开发人员会尽量遵守这些规则。GIMP被公认为最成功和最受欢迎的开源项目并不奇怪。

但GIMP项目并非唯一的开源案例。我们见到的绝大多数成功的开源项目都是以这种方式运转的。有些项目（如GnuCash）在wiki上提供了所有此类信息。其他项目（如KDE)以Subversion知识库的方式驱动开发人员文档。它们的共同之处是，在开发人员希望与团队其他成员交流的各个方面都拥有广泛的文档和编写策略，且整个团队都全力支持对这些策略进行维护和强化。几乎每个成功的开源项目都有类似的网站以及来自团队的类似承诺。
然而在公司环境中，项目团队很少能像在成功的开源项目中那样拥有规划、归档或审查的权限。由于某种原因，一旦涉及预算或截止日期，我们这么多年来学到并成功应用于开源项目的所有经验似乎都不再有效。讨论哪些特性应该实现或不应实现这种情况似乎根本就不会发生。当公司开发人员试图召集人员讨论软件的设计，或者制定计划指导代码的添加或维护方式时，他就会听到这样的抱怨：“又要开会了”。实际上更糟的是，当开发人员设法使团队的每个成员都同意进行设计或代码审查时，他们的主管都会告诫他们：不要在这上面花太多时间，这暗示不知为何除编写代码之外的任何活动都成了无关紧要的。毕竟，他们只是程序员，他们的观点只对那些与软件构建直接相关的问题才显得重要。软件的开发方向应“由公司指定”，程序员只需专心编写代码。
但众所周知，公司项目通常不会产生高品质软件，甚至根本不会产生任何结果！许多重要研究多次说明了这一事实，例如Standish Group的年度CHAOS报告（最近发布的2004年度报告[PDF]指出，只有不到1/3的公司项目被认为是成功的。）

但是许多大规模的开源项目都成功了，而且是在困难得多的情况下获得成功的：没有预算；团队地理位置分散；全部是志愿人员，他们只承担自己喜欢的角色和责任，而且投入的时间也是随各人的意愿。在这样的条件下，即使纪律最严明的公司项目团队也会立即自行解体，那么开源项目团队是如何确保成功的呢？在我们的《Applied Software Project Management》（O'Reilly出版社2005年出版；参见我们的公司网站）一书中，我们介绍了5项基本原则，它们应该被应用于每个软件开发项目。遵守这些原则将有助于开发出成功的项目，而不管是项目是开源的还是专有的。这些原则是：
•永远实事求是
•信任团队
•审查一切，测试一切
•所有开发人员都是平等的
•完成项目的最快方式就是正确地开发项目

每项原则都很重要，但在公司环境中通常都会被忽视，这就严重影响了项目的成功。公司项目中的一些惯例违反了这些原则。相较之下，成功的开源项目非常善于通过采用经过时间验证的、被人们广为接受的协作实践或方法，将这些原则付诸实践。