介绍
自由软件—开源软件正如在里提到的，这两个词是同义的。详情参见— 已经成为现在IT产业的支柱。它不仅仅能够在手机、笔记本和台式电脑上运行，而且也能够在嵌入式控制设备上运行，其中包括家用设备、汽车和工业生产使用的机器；甚至还有数不胜数的各种我们意想不到的设备，在提供在线服务的服务器上，开源尤为流行。每当你发送邮件，浏览网站或者是使用你的智能手机查询信息，很大一部分的工作都是由开源软件完成的。
然而大部分人都注意不到这些开源软件，甚至很多做技术工作的人也是如此。开源的天性就是工作在幕后，如果不是工作直接接触的关系，可能没有人会注意到它。这就像计算领域的浮游生物。正如我们每个人都在呼吸，但很少人停下来思考氧气从而何来。
不过，如果你已经读到这一句了，你已经在思考氧气的来源，大概还想自己创造一些了吧？
这本书不仅研究如何做开源比较好，同时也研究出差错的缘由，所以你能容易的识别和纠正问题。我希望在读过此书之后，你不仅能对如何避免开发过程中的常见陷阱有丰富的技术储备，而且对如何使一个成功的项目得到成长和维护有深入的了解。成功并不是零和博弈，而且本书也并非教你如何在竞争中脱颖而出。诚然，运营开源项目的一个重要部分就是和其他相关的项目合作。长远看来，每一个成功的项目都为在世界范围内自由软件的成长作出一份贡献。
我禁不住认为，当自由软件项目失败的时候，它们失败的缘由和其他非自由软件项目失败的原因也差不多。实际上，在自由软件内不会有诸如建立在不切实际的需求上的垄断，含混不清的规范，可怜的代码管理，设计阶段不足等等笼罩在传统软件工业上的幽灵。有关这些主题的书已经是汗牛充栋，我不打算重复。我想做的是描述自由软件独有的问题。当一个自由软件项目开始运转，最常见的问题是开发者（或是经理）难以识别开源软件开发过程中的独特问题，尽管他们可能已经在那些闭源软件的常见问题上摔打了多年。
一个最常见的错误就是急于从开源的形式本身获得好处，但这是不切实际的。一纸开放许可证不会一下子让成群的活跃开发者自愿地把他们的时间交给你的项目，将一个原本问题很多的项目开源也不能自动地修正这些问题。实际上很可能相反，与不开源相比，开放一个项目短期内会带来一系列更多的复杂问题和代价。
开放自己的项目意味着，要让完全没接触过这个项目的人都能理解代码，要写开发文档，并且需要弄个论坛和其他的合作工具（更多的细节在这里）。
所有这些都要费心费力，起初完全是投入（而无回报）。当然如果有开发者确实感兴趣，在他们为你的项目带来好处之前回答他们的问题也是一个额外的负担。如同开发者Jamie Zawinski回忆Mozilla项目早期的混乱状况所说地：
开源确实有用，但它绝非是万能的。我对你的忠告是：你不能指望在一个垂死项目上洒一点"开源的精灵魔粉"就能让所有事情奇迹般地运转起来。做软件是困难的，问题不会那么简单。
(from https://www.jwz.org/gruntle/nomo.html)
一个相关的错误是对展示和打包的轻视，特别是当一个项目顺利运转时总认为这些以后再做不迟。展示和打包有很多的目的，所有的一切都是为了减低进入的门槛和减少新人认知上的困难--减少他们在进入下一步前的工作量。网站最好看上去不错，软件的编译打包和安装要尽可能的自动化等等。
很不幸的是，很多程序员认为与代码本身相比，这些工作都是次要的。导致这种想法的原因有很多。首先，他们感觉这些都是附加作业，因为它们主要是给最不熟悉项目—的这部分人带来好处，反过来也一样（对最熟悉项目的这些程序员来说，没有什么好处）。毕竟这些编写代码的人并不真需要打包。他们知道如何安装，管理和使用这些软件，因为代码就是他们写的。其次，一个好的展示和打包，往往需要与写代码完全不同的技巧。即使展示打包能对整个项目起到事半功倍的作用，人们总是钟情于专注自己所擅长的。 将详细讨论展示和打包，并且解释从项目的一开始就确定这些工作的优先地位的重要性。
还有一个谬论是说开源需要很少甚至完全不需要项目管理，相反地，认为照搬商业开发的那一套管理模式也能在开源中做得很好，也是一个谬论。
在一个开源项目中，管理总是不起眼的，但在成功的项目中，它通常在幕后起到推动的作用。一个简单的心理试验就足够显示其原因。一个由来自四面八方的程序员—这已经是一群臭名昭著的独立样本—组成的开源项目，他们中的大部分人从来没有互相见过面，为这个项目工作只是出于他们各自的目标。心理试验能很简单地预测如果没有管理，在这样一个团体中会发生什么。除非发生奇迹，否则他们很快就会四分五裂。事情不会如我们希望的那样自己运转。管理偶尔会相当活跃，但是大部分时候是非正式的，微妙的，低调的。只有一件事情能把开发者团结在一起，就是他们相信团队合作比单干能做得更多。因此最重要的管理目标是确保他们继续相信这一点，做到这点需要设定交流的标准，需要让能干的开发者不会因为个性而受到排斥，总之要使项目成为开发者的留恋之地。我们将在后面讨论这些工作需要的具体技术。
最后还有一种类型的问题也许我们可以称之为“文化上的引导失败”。二十年之前，甚至十年之前，谈论自由软件运动的整体文化都还为时过早，但现在不是了。一种清晰的文化正在慢慢浮现，虽然它不是一个整体—如同很多地域约束的文化，易于产生内在的异议和派别—但它有一个基本的一致的核心。大部分成功的开源项目展示了这个核心中的部分或全部特质。他们奖励符合这种文化的行为，不符合的也有惩罚；他们创造了一种鼓励计划外的参与氛围，甚至不惜中心协调时间的代价；他们对粗野和礼貌的概念与流行观念有本质上的区别。最重要的是，长期的参与已经内化了这些标准，所以他们能够对将要发生的举动能大体上取得共识。失败的项目通常明显的背离了这个核心，尽管并非本意，但通常是因为没有对建立合理默认行为方式达成共识。这意味着一旦问题出现，由于参与者缺乏通过弥补分歧而对问题做出反馈的现成文化储备，形势会迅速恶化。
那最后一个类型，“文化上的引导失败”，包含一个有趣的现象：有些类型的组织从结构上来看和开源开发就更难兼容。在准备写本书第二版的时候，有一个很大的惊喜是我认识到，总体上经验表明，相比于盈利组织，统一管理并没有那么适用于自由软件项目，而非盈利项目位于两者之间。这其中有很多原因（参见），这些问题当然是可以克服的，但值得一提的是，当一个已经存在的组织—特别是层级结构分明的组织， 特别是层级结构分明、不愿面对风险、在意公共影响的那种组织—建立或加入一个开源项目，这组织往往都需要做一些调整。
运营一个开源项目比一个闭源项目所需要的额外努力并不多，但项目初期所需要的工作就很明显多了。相较之下初期的优势很不明显，不过随着项目的发展，优势会越来越明显。（开源）会给开发者带来深层次的满足感：这种感觉当然源自于在一个开放的环境，能够欣赏同伴们的工作同时也能得到他们的赞许。很多开源开发者在同一个项目里会保持活跃--作为他们工作的一部分--甚至在他们换了雇主以后还保持活跃。开源还有很多更显著的组织上的好处：你们组织参与的开源项目就好像一层渗透膜，通过它你们的经理和开发员能够接触到你们组织以外的人。这个好处就犹如参加一个会议，但你却能继续做每天的工作也不用出门的花销。当然了，对他们来说，能参加一个真的会议也很不错。 参见 in .在一个成功的开源项目里，一旦这些好处逐渐显露，那这些好处会极大的超过你们的投入。
此书是一本实用的指南，而不是一篇人类学论文或是史书。然而了解今天的自由软件文化的起源对任何一个实际的建议都是必要的基础。一个理解这种文化的人能在开源世界任意驰骋，即使遇到很多的各地风俗和方言，仍然可以自信和有效地参与。相反，一个没能很好理解这种文化的人将会在组织或是参与一个项目的过程中处处遇到困难和意外。由于自由软件的开发人员的数量仍然在飞速增长，其中有很多人属于后一种情况—这多半是一种新近加入的文化，并且会持续一段时间。如果你自认为是其中的一员，下一节为你在以后将在本书或是互联网上遇到的讨论提供了背景材料。（另一方面，如果你已经在开源中工作了一段时间，你也许早已了解了这段历史，你可以选择跳过这一节。）
历史
软件分享自从软件诞生的那一天起就出现了。在计算机工业的早期，厂商认为竞争的优势在于对硬件的创新，因此并不太认真把软件当成商业资产看待。这些早期机器用户许多都是科学家或是技术人员，他们有能力自己修改和扩展随机附送的软件。有时用户不仅将补丁反馈给厂商，而且分发给相似机器的其他用户。厂商经常允许甚至鼓励这么做：在他们眼里，无论是哪一种渠道，对软件的改进都使得机器对其他的潜在消费者更有吸引力。
虽然今天的自由软件文化在很多方面都和早期相似，但是有两点重要的不同。首先，当时几乎没有硬件的标准—那是一个计算机设计创新的黄金时代，但是繁多的计算机架构也意味着所有的事情都无法同其他的兼通。因此，为一台机器编写的软件一般无法在另一台上工作。在一种特定的架构或是架构族上程序员需要专门的知识（今天程序员更多的是学习一种编程语言或是语言类型的专门知识，他们对他们的专业知识能移植任何一台遇到的机器上非常自信）。因为个人的专门知识总是针对一种特定类型的计算机，这些专门知识的积累能让计算机对他们以及同事变得越来越有趣。这就是为什么厂商对让特定机器的代码和知识尽可能广的得到传播感兴趣的原因。
其次，当时没有互联网。虽然当时对分享的法律约束比今天少，但却有更多的技术约束：也就是说，和说话相比，把数据从一个地方移到另一个地方是笨重不便的。在一些公司和实验室里员工之间，可以通过一些不错的小型的局域网共享信息。但当一个人想同不限地点的所有人分享时，问题依然存在。克服这些问题的途径有很多。有时独立的团体之间会互相联系，通过邮局寄送磁盘或是磁带，有时厂商扮演了补丁的中心情报交换所的角色。厂商还会帮助在大学里的早期计算机开发者，那里的气氛是鼓励知识传播的。但是数据传输所必须的物理媒体意味着分享总会遇到阻力，和（实际上的或是组织上的）距离成正比的阻力。现在这种广泛的，几乎没有阻力的分享，在那时还是不可能的。
私有软件和自由软件的兴起
随着工业的成熟，接连发生了一系列相关的变化。众多硬件设计中的赢家—逐渐清晰起来有技术优势的赢家，有行销优势的赢家，或是两者结合的赢家。与此同时，被称为“高级”语言的编程语言的发展意味着一个用某种语言写成的程序能够转移到（“编译”）另一种类型的计算机上运行。硬件厂商不会忽视这其中的含义：现在客户无须再把自己捆绑在一种特定的计算机架构上就可以开展一个大型的软件工程项目。随着各类计算机的性能差异日益变小，以及低效率设计的消失，硬件成了厂商为未来利润率下降的唯一指望。原始的计算能力成了一种可替代的产品，而软件成为差异化优势。销售软件或至少将它视为硬件销售不可分割的一部分，看起来是一种不错的策略。
这意味着厂商必须开始更严格地在他们的代码上强制执行版权。如果用户之间继续简单地分享和修改代码，他们可能会独立完成一些改进，现在被供应商当成“附加价值”用来销售。更糟的是，分享代码可以落入竞争对手的手里。讽刺的是，这一切都发生在互联网即将破壳而出之时。就在无障碍的软件分享在技术是终于成为可能时，计算机行业内发生的变化则使它在经济上无法受到欢迎，至少计算机公司的观点是如此。供应商手段强硬，要么拒绝客户访问自己机器上的源代码，要么是通过保密协议使方便的共享成为不可能。
有意识的反抗
虽然无障碍代码分享的世界正在慢慢凋零，但至少有一名程序员的心中保持着清醒。理查德·斯塔尓曼（Richard Stallman）在70年代和80年代早期一直为麻省理工学院的人工智能实验室工作，那里是代码分享黄金时代的黄金圣地。人工智能实验室有很强的“黑客精神”，斯塔尓曼的“黑客”指的是“喜欢程序并且喜欢用它炫耀聪明的人”，不是近些年来的新含义“非法进入计算机的人。”那里的人对分享为系统做出的任何改进有狂热的爱好。正如斯塔尓曼后来写到的：
我们没有把我们的软件称为“自由软件”，因为那时这个术语还不存在，但它确实是。无论外面的大学或是公司来的人来索要程序，我们都很高兴这么做。如果你看到在用的一个少见还有趣的程序，你总可以要求看源代码，所以你能读它，修改它，或者用拆取部分写一个新程序。
（来自）
1980年之后不久工业界发生的变化最终影响到了人工智能实验室，斯塔尓曼周围伊甸园式的社区坍塌了。一家创业公司挖走了很多实验室的程序员去开发一个操作系统，这个系统同实验室正在开发的非常相似，但使用了独占许可证。与此同时，人工智能实验室购买了带有私有操作系统的新设备。
斯塔尓曼见一叶落而知秋：
那个时代的现代化计算机，比如VAX或68020都有自己的操作系统，但都不是自由软件：为了得到一份能运行的拷贝，你甚至得签署一份保密协议。
这就是说使用一台计算机的第一步是承诺不帮你的邻居。一个互助的社区是被禁止的。私有软件的拥有者定下了规矩，“如果你和你的邻居分享了，你就是强盗。如果你想要改变，来祈求我们做吧。”
此时，他性格中的怪僻萌动了，他决定反抗这种趋势。他既不想继续留在人去楼空的人工智能实验室，也不想在一家新公司里写代码，因为他写出的代码会被锁在保密箱里，最终他从实验室辞职，随后创建了GNU项目和自由软件基金会（FSF）。GNU“GNU's Not Unix”的缩写，扩展后短语中的GNU其实是同一意思。的目标是开发一个完全自由和开放的操作系统和配套的应用软件，它们的用户永远不会阻止去破解或是分享它们的修改。本质上他是要重建人工实验室内被摧毁的那些东西，但是这一次是在全世界的规模上，并且还要避免导致人工实验室的文化被动摇破裂的那些弱点。
除了新操作系统的工作，斯塔尓曼还设计了一套确保他的代码无限自由的版权许可证。GNU通用公共许可证（GPL）是法律博弈中的奇招：它声明允许无限制地复制和修改代码，同时拷贝和派生产物（即修改版本）必须在原始版本的相同许可证下发布，不得附加限制。实际上，它用版权法去达到一个同传统版权法相反的目的：取消对软件分发的限制，它阻止任何人，甚至是作者本人对此的限制。对斯塔尓曼来说，这要比简单地把他的代码分发到公共领域好得多。因为在公共领域，一份实际的拷贝有可能被包含在一个私有程序中（这样的事情我们在使用宽松的版权许可证的代码中听到很多了参见这里 获取更多关于“permissive”协议和GPL风格的"copyleft"协议. 关于协议的介绍还有一个很好的资源是The opensource.org FAQ。—参见https://opensource.org/faq#copyleft.)。）。虽然这种包含不会在任何方面减弱原始代码的持续可用性，但它意味着斯塔尓曼的努力可能会帮助敌人—私有软件。GPL为自由软件提供了一套保护机制，因为它阻止了非自由软件利用GPL许可证下代码的优势。GPL同其他自由软件许可证关系的详细讨论在。
在很多程序员的帮助下──其中有些是认同斯塔尓曼的思想体系，有些只是为了能看到自由软件的代码──GNU项目开始发布操作系统中最重要组成部分的自由替代品。因为计算机硬件和软件已经高度的标准化了，使用GNU替代其他的非自由操作系统成为可能，许多人也这么做了。GNU文字编辑器（Emacs）和C编译器（GCC）特别的成功，它们获得大量忠实的拥护者，这不是因为其理想主义的基础，而是因为其技术价值。约在1990年GNU已经生产了一个自由操作系统的大部分，除了内核— 实际负责引导计算机、管理内存、磁盘和系统其他资源的部分。
不幸的是，GNU项目选择的内核设计要比预想的更难实现。随后的延期使得自由软件基金会没能及时地发布一个彻底的自由操作系统。这缺失的部分最终由一个芬兰的计算机科学系的大学生Linus Torvalds补完，在遍布全世界的志愿者的帮助下他用更加保守的设计完成了一个自由内核。他将其命名为Linux，当把内核同GNU项目的已有软件和其他免费软件(特别是X窗口系统)组合在一起，结果就是一个完全自由的操作系统诞生了。第一次，你不再需要任何的私有软件来启动和使用你的计算机。从技术上来说Linux不是第一个。在Linux之前不久已经有了一个能在IBM兼容机上运行的自由操作系统，386BSD。然而386BSD的启动和运行还不太稳定。Linux的飞速发展不仅因为它是自由软件，而是因为安装之后你有更大的几率能启动计算机 。
这个操作系统上的很多软件都不是GNU项目的产物。实际上，GNU不是唯一的开发自由操作系统的团体（例如，当时最终发展为NetBSD和FreeBSD的代码已经开始编写）。重要的不仅仅是自由软件基金会产出的代码，而且是它们的政治修辞。把自由软件当成一个目标而并非一种手段讨论，让那些对此并没有政治意识的程序员们很为难。即使那些并不认同自由软件基金会的程序员也不得不面对这些问题，只要他们处于不同的位置。自由软件基金会通过在他们的代码上附带有关GPL和其他文字的信息，成功地扮演了鼓动家的角色。随着他们的代码广泛地被分发，思想也随之流传。
意外的反抗
在自由软件运动的早期还发生了很多其他事情，其中很少有如斯塔尓曼的GNU项目般清晰的思想体系。其中一个最重要的是伯克利软件发行版（Berkeley Software Distribution，BSD）一个Unix操作系统的重新实现—这个项目可以一直追溯到1970年代晚期AT&T公司—由加州大学伯克利分校负责的一个松散的私有研究项目。BSD并没有什么要程序员们联合起来并且共同认可的政治信条，他们通过高度分散地开发方式从零开始重写了Unix命令行工具和代码库，最终是操作系统内核本身，这一切的大部分都是由志愿者完成的，用天才和热情实践了这个信念。BSD项目成了非意识形态的自由软件开发的主要例子，并且他们为那些在开源世界继续保持活动的开发者提供了训练场地。
另一个合作开发的重镇是X Window
System，一个由MIT联合其他有兴趣为客户提供窗口系统的硬件厂商在80年代中期开发的自由的网络透明的图形计算环境。和私有软件恰恰相反，X许可证故意允许在自由核心之上建立私有扩展—每一个成员都需要机会加强默认的X发布，这样就会获得了超越其他成员的竞争优势。X Windows正式的称呼是“X Windows System”，但实际中人们通常称之为“X Windows”，因为三个单词太繁琐了。自身是自由软件，但其主要目的是为了平衡商业利益竞争中的差距，对终结私有软件的统治没有丝毫的诉求。还有一个早于GNU项目很多年的例子是TeX，Donald Knuth的自由排版系统。他使用的许可证允许任何人修改和分发代码，但如果未能通过一个非常严格的兼容性测试，则不允许冠以"TeX"的名称（这是自由许可证的“商标保护”的一个例子，更多的讨论在）。Knuth并非对软件应该是自由还是私有的问题有什么意见或是其他诸如此类的目的，他需要一个更好的排版系统是为了完成他真正的目标—一本计算机编程的书—当书完成了，没有理由不把他的系统公之于众。
虽然没有列出每一个项目和每种许可证，但还是可以确信，在1980年代末，出现了许多基于各类许可证的项目。许可证的多样性反映了动机的多样性。即使是一些选择GNU GPL的程序员也没有和GNU项目同样强烈的意识形态动机。尽管他们很享受为自由软件工作，但是许多开发者并不把私有软件视作社会恶魔。确实有些人是受到道德冲动的驱使要去消灭“囤积软件”（斯塔尓曼对非自由软件的称呼）的世界，但其他人更多的是出于对技术的狂热，或对能和志同道合者合作感到愉悦，甚至简单地出于人类对荣耀的渴望。大体上说，这些不同的动机并没有造成冲突。部分原因是和其他的创造性活动如散文和视觉艺术不同，软件必须通过半客观测试才能成功：它必须能运行，去除绝大部分的bug。这自动地给了一个项目的全部参与者一个共同的背景，一个理由，一个无需为除了技术以外的问题担心的协同工作的框架。
开发者们还有另一个团结互助的原因：自由软件世界生产了很多质量非常高的代码。要么是令最接近的非自由对手都望尘莫及，要么是可以匹敌，或至少价廉物美。虽然也许会有一些人是出于严格的意识形态的背景才使用自由软件，但绝大部分人是因为它更出色才使用自由软件的。在这些人中，总有一定比例的人乐意将自己的时间和技术贡献出来帮助维护和改进软件。
这种产出优秀代码的趋势并非是普遍的，但在全球的自由软件项目出现的频率越来越高。这引起高度依赖软件质量的商业公司的关注。其中的许多发觉他们其实早已经在日常的操作中使用自由软件，只是并没有意识到（管理层并不总是能意识到IT部门做的每件事）。公司开始在自由软件项目中扮演越来活跃和公开的角色，他们向自由软件的发展捐助时间和设备，有时甚至是直接的资助。在最好的情形下，这些投资能获得数倍的回报。这些赞助商只需要为少数全职投入的专家级程序员支付工资，获得的回报却包括了无偿的志愿者和领取其他公司薪水的程序员的全部工作成果。
“自由”还是“开源”
随着商业世界越来越多的关注自由软件，程序员们面临新出现的问题。首先是单词“自由”本身。第一次听说“自由软件”（free software，在英语中free既有自由的意思，也有免费的意思）这个词的时候，许多人都错把它理解成“免费软件”。确实大部分的自由软件都是免费的，发放自由软件的人可以收取一定的拷贝费用，但是由于他无法阻止受领者去免费地再发放，价格还是会很快接近于零。
但不是所有的免费软件都是自由的。例如在1990年代的浏览器大战中，为了抢占市场份额，网景和微软都无偿地发布他们的网络浏览器。这些浏览器都不是“自由软件”。你无法得到源代码，即使得到了也没有权利修改和再发布。网景Navigator浏览器的源代码最终在1998年在一个开源许可证下发布，成为后来的Mozilla网络浏览器的基础。参见。你唯一能做的是下载一个运行文件，然后运行。这些浏览器的自由不会比从商店里购买的盒装软件更多；它们只是有较低的价格。
围绕自由一词发生的混乱，很不幸地完全是由于英语本身的多义性造成的。大部分的其他语种对“免费”和“自由”明确地区别对待（例如在罗曼斯语中gratis和libre的差别对听众而言是一清二楚的）。但英语是互联网事实上的桥梁语言，所以一个英语的问题在某种程度上来说即是每个人的问题。围绕自由一词的误解是如此之广，以至于最终自由软件程序员们发明了一个公式来应对：“It's free as in
freedom—think free
speech, not free beer。”但一遍又一遍的解释还是让人厌倦。许多程序员认为，即使加以解释，对自由的岐义正在阻碍公众对这种软件的理解。
但实际的问题更复杂。free一词承载了一个无可避免的道德内涵：如果自由是它自身的最终目标，它同自由软件是否被更多人接受，是否能从商业中赚取更多的利益无关。这个动机唯一的光明面从根本上说既不是技术也不是商业，而是道义。此外，“free as in freedom”的定位也迫使那些既想在生意的某一方面支持实用的自由程序，而另一方面又继续推销私有软件的公司陷入前后矛盾的境地。
本已陷入身份危机的社区又迎来了这些困境。如果说自由软件运动有一个总体目标的话，那些实际上写自由软件的程序员们并不都为了同一个目标而工作。甚至于从一个极端走向另外一个极端的观点会引起误解，因为我们会错误地以为只有两种极端的观点，而实际上存在着多层次的看法。然而，如果我们忽略其间的细微差别，他们都可以被归入两类信念。一个团体追随斯塔尓曼的观点，认为共享和修改的自由是最要的事，因此如果你不再谈论自由，你就忽略了核心问题。另一些人认为软件本身才是最重要的因素，并且对公开地宣布私有软件本质上是坏的而感到不舒服。部分的自由软件程序员相信作者（或是雇主，如果是有偿工作）应该有权利控制分发的条款，选择何种条款不应该受到道德的审问。尽管其他人不这么认为。
在很长时间里这些分歧并不需要认真对待，但自由软件在商业世界里的快速成功使得这些问题无法再回避。1998年一群程序员结成一个团体，也就是后来的开源促进会（Open Source Initiative，OSI）OSI的主页。创造了开 源一词来替代“自由”。OSI认为“自由软件”不仅有潜在的岐义，而且“自由”一词本身就是一系列问题的根源。运动本身需要一个在商业世界里的营销程序，而谈论道德和社会公益在公司董事会里是不受欢迎的。用他们自己的话说：
开源宣言是自由软件的一个营销程序。用务实的基础推动自由软件远比慷慨激昂大谈理想有用得多。成功的本质没有变，失败的象征和看法已经变了。 ...
需要告知大多数技术人的不是开源的概念，而是名字。为什么我们不再像从前那样称之为“自由软件”呢？
一个直接的原因是“自由软件”一词容易以一种导致冲突的方式被误解。 ...
但真正更名的原因是营销上的。我们现在想打入商业世界。我们有成功的产品，但在过去我们的定位是可怕的。自由软件一词被商人们误解了，他们把这种描述理解成反商业主义，甚至更糟，贼。
主流公司的CEO和CTO们绝不会买"自由软件"。但如果我们保持非常相似的传统，人还是那些，相同的自由软件许可证，只是换了一个“开源”标签的话—他们会买这样的。
一些黑客觉得这很难相信，但那是因为他们的技术化思维已经僵化，被条款所束缚，不能理解当你推销某样东西时形象有多重要。
做营销时，外表是很现实的问题。我们打算用什么样的形象来消除同公司打交道的障碍，和我们的行为，我们的信念，我们的软件同样重要。
(来自 https://www.opensource.org/. 或者 更正式的这个页面—OSI把这些页面取消了，尽管我们还能在这里看见：
https://web.archive.org/web/20021204155057/http://www.opensource.org/advocacy/faq.php
与
https://web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/case_for_hackers.php#marketing [sic].)
通过上面的文字我们可以一窥争论的冰山一角。它提到了“我们的信念”，但是巧妙地回避了这些信念到底是什么。对有些人呢，这种信念也许是认为开放的开发过程将产出更好的代码，对其他人也许是认为所有的信息都应该共享。他们用到了“贼”一词（据推测是）影射非法的复制—许多人反对这一点，认为如果原持有人随后仍然保留原件就不能视作贼。这里有一个明显的暗示说自由软件运动被错误地划入了反商业主义，但它小心翼翼地回避了这种归类是否有现实依据的问题。
其中没有一条可以说明OSI的网站是自相矛盾或是误导的。确实没有。相反，这个例子表明了OSI所主张的，正是自由软件运动所缺少的，也就是好的营销，此处的“好”指的是“能在商业世界生存”。开源宣言给许多人带来他们一直寻找的—一套将自由软件作为开发的方法论和商业策略而不是道德圣战的语汇。
开源促进会的出现改变了自由软件的面貌。它将长久存在的矛盾摆上了桌面，迫使运动承认与外部一样，其自身内部同样有派系斗争。由于大部分的项目都包括了来自两个阵营的程序员，加上一些很难明确归类的参与者，如今二者都已经找到了共同的基础。这不意味着人们从不谈论道德动机—例如，有时人们会讨论传统的“黑客精神”的流失的问题。但是很少有自由软件/开源开发者在一个项目中公开地质疑他人的基本动机。作出贡献远比贡献者本身重要。如果有人代码写的不错，你不会问他们到底是出于道德原因还是因为雇主付给他们工资或是为了在推荐信上添加砝码，或其他什么原因。你从技术角度评估贡献，从技术角度反馈。甚至Debian这样毫不讳言政治的组织（他们的目标是提供一个100%自由的操作环境），也已经不再那么严格的对待集成非自由代码和同目标不一致的程序员共事了。
现状
当运作一个自由软件项目时，你不必在日常工作中谈论沉重的哲学命题。程序员不会要求项目中的其他人和自己在所有事情上能够看法一致（那些这一点上坚持的人很快就会发现他们无法在任何项目内工作）。但是你必须了解“自由还是开源”之争的存在，部分原因是避免谈论引起部分开发者抵触的事情，部分是因为理解开发者的动机是管理一个项目最好的方法—有时，是管理一个项目的唯一方法。
自由软件是一种有关选择的文化。你必须首先理解为什么人们会参与其中，才能成功地运作一个项目。强制是不管用的。如果一个项目让人不高兴了，他们会立刻转移到另一个项目。自由软件的独特之处还在于志愿者社区的投资强度。大部分内部的人从来没有和另一个参与者面对面地交流过，只是在高兴时捐助一点时间。通常人类用来互相结识并结成牢固的团体的渠道被压缩成了一条细管：在键盘上打字然后通过电缆传输。因此，形成一个有凝聚力和专注力的组织需要花上很长时间。相反，在首次接触的五分钟内流失一个潜在的开发者是非常容易的。如果对一个项目没有良好的第一印象，新来者很少会给予第二次机会。
关系的无常性，或者是潜在的无常性，也许是面对一个新项目时最让人畏惧的一点。如何才能使这些人尽可能长时间的呆在一起做一些有用的事？这个问题的答案足可以用本书剩余的篇幅来说明，但如果必须用一句话来回答，会是这样：
人们应该能感到他们同一个项目的联系和对它的影响力是直接同他们的贡献成正比的。
没有哪类开发者或是潜在的开发者应该感到自己由于非技术原因而被区别对待。确实存在一些情况，你由于非技术上的东西，歧视某一些开发者，这种其实可能会破坏项目。其中大有道理，因为他们的行为长期来看迟早会对项目有负面影响。人们文化太丰富了，我也没办法给一个简单的规则来考虑到所有的情况，但我认为，你应该尝试欢迎所有潜在的参与者，如果你一定要有所歧视的话，请一定要基于某种确定的行为，而不是仅仅是依据参与者的所在公司或所在团体。。特别是项目的赞助商或是领取报酬的开发者在这一点上要特别小心，这一点将在后面的详细讨论。当然，这不是说如果没有公司赞助商的话就可以高枕无忧了。钱只是能影响项目成功的许多因素之一。还有诸如语言的选择、许可证的选择、何种开发过程、设立何种类型的基础架构之类的许多其他因素。在良好的基础上开始一个项目是下一章的主题。