理解开放源码的哲学原旨要简单的多，一旦你知道了少量的其文化历史，以及与电子计算机时代所有其他东西一样古老，它到底是关于什么的。
开放源码的哲学源于分时系统时代，源于有大研究机构的大学例如麻省理工大学，斯坦福大学，以及卡耐基梅隆大学。在1960和1970年代，这些学校拥有研究实验室，他们的研究员以及项目创造了软件――包括基本的平台例如操作系统和编程语言以及高级别的应用类型软件。这是有必要的，因为这些研究工作本身是在操作系统和编程语言领域的，也没有合适的商用或者“专业”系统能够承担相关角色。
这些实验室使用的计算机几乎都是独占分时机器，拥有少量连上的终端。白天，机器使用率很高，不仅仅因为研究，也因为写论文以及行政和文书目的。千真万确，在1960年代就有电子邮件了。想象一下仅仅数兆字节的内存，1个MIP的计算机，被100到200个人共享使用。很多实际工作是在晚上完成的。
那时候通常在一个公司的办公室，晚上门都是锁着的，唯一考虑大堂的人是保安，他们拥有每一个办公室的钥匙。终端通常是在办公室里面的，如果这些办公室锁住了，没有钥匙，任何人也不能使用终端。几乎可以肯定终端比人少，因此固定资源也和计算资源一样被共享使用。我们可以假定上班时间完成普通的工作，因此在晚上，计算资源要么空闲，要么在一些特别授权的人的控制下运行。无论如何，计算机是昂贵的，需要公司合理的使用。
想象一下大学实验室也是同样的情况。人们可以开始大规模计算然后回家，实验性的操作系统可能崩溃，实验性的计算机可能让操作系统崩溃――简而言之，事情很容易出问题。而且，在非锁定的区域和办公室，想要工作的人比可用的终端要多。
想象一下1960年代，下午两点的时候，控制一个失控计算任务的终端在一个锁着的门后面，并且问题足够对其他人的工作造成妨碍。你能做什么，假定除了得到那个控制终端，没有办法杀死或者挂起那个计算任务的话？是否所有人都要回家，要等到那个人第二天上班呢？时间是宝贵的，并且可能因为一个人锁了他或者她自己的门而让50个人回家。或者假定操作系统严重崩溃了，以至于重新启动都不能修复――固定环境变化了，操作系统得修复才能用(也许添加了一个新硬件，例如机器人手臂)。你愿意等到你可以和某个程序员说上话，付费修改吗，当你自己足够内行去修复的时候？
不，与传统的过程不同，你们促成了3个变化：
从某些标准上来看，这可能会很可怕，但是它确实很好的工作了，并且创建了一种文化，一种极高生产力的文化。首先，与拥有一个或者几个系统管理员不同，这样的实验室培养了几个土生土长的系统管理员，也许一个200人的实验室有几打。这些人可以做今天的系统管理员所做的大部分事情，并且我敢打赌他们都是非常棒的系统管理员――对于一个操作系统或者其他系统软件的每一个部分，通常有一到两个创建它的专家，另有三到六个足够能干的人来维护和改善它。加入了实验室的人可以拿到所有的源代码，这样就可以知道功能是怎么完成的，并且实际上也可以学习怎么更好的编程。有什么比学习大师程序员写的工作代码更好的办法来学习编程呢？
结果就是那些机器一天24小时，一年365天被高效的使用，还有支持。操作系统，编程语言，以及现在普遍接受的很多软件，都是花了若干年时间，由数百程序员――包括职业的或者业余的――逐步开发出来的。
社会压力和某种形式的贡献排名用来过滤哪些人可以在什么上工作。蓄意破坏，坏习惯，以及有害的恶作剧即使有也很少发生，因为在这种条件下发展出来的道德约束是如此之强。
这里有一个旧故事――细节上可能不真实，但基本上是准确的:
一个有能力的新成员加入了某个类似开放源代码的实验室，并且在自己的办公室有一个终端。因为习惯与更传统的环境，他开始了一个任务，晚上锁门回家了。这个任务“跑飞了”，锁住了系统，以至于要么需要利用那个终端去杀死它，要么必须重启系统。某个系统程序员不得不破门而入，把门边的铁链拉断了。第二天早上，这个有本事的家伙发现他的门歪着倒在墙上，碎了一地，在他的座位上有一个便条解释发生了什么，并且这个实验室的总裁也留了一个便条，告诉他可以使用他的非受限基金去修门和铁链。
这就是形成了开放源码的文化。该文化观点是人们会举止优雅，并且有正在推广的公共利益。源代码是共享经验的一部分，构成和支持了这种文化。
因此，如果当你阅读了以下的原旨你就感到与你当前的工作不一样，与你的感觉不一致，与你能够工作的方式不一致，那么你就不能够适应这种文化，而适应这种文化恰恰是创造一个成功的开源项目的必须。如果是那样的话，你不应该继续开源你的项目：你的项目不会成功，你的项目会让你的公司在公众的眼中感到难堪，并且你将毁掉你的项目，让你不得不放弃它。
严重警告，是的，开放源码并不适合每一个项目或者适合每一个人――至少现在不是。
让我们看看开放源码的一些原旨。
当一个制作人演出了一个戏剧，观众没有选择，只能作为评论家的一个角色：你要么喜欢这个演出，要么不喜欢，并且你会告诉你的朋友你是怎么想的。但是如果剧作家在写剧本的时候或多或少向潜在的观众寻求帮助，这些潜在观众成员很可能尽最大努力并且或多或少认为(从他们自己的视角)自己的合作作者的角色。合作作者很难像批评家一样持尖锐的批评态度。
邀请人们阅读源代码就把他们放到了一个思维的框架中，从而能够帮得上忙。你不仅仅能够获得很多测试人员，并且这些测试人员都有源代码，并且他们中的很多人将能够在源代码中定位问题的根源。运行软件的大量人群将拥有各种不同的经验和专业知识，因此我们有理由假设你代码中每种类型的bug已经被这些人中的某个人在某个时候看见了。就像有一千个人校对一本书，找出拼写和排版错误一样。
你通常将获得非常博学和专注的测试人员。可以获得源代码的事实意味着他们中的很多人至少可以自己开发对问题的绕过方案，因此他们将更久的使用这个软件。并且同样重要的是，你将获得一批人，他们想要对核心源代码做经常是很大的贡献。
组织外面的人有对源代码进行贡献的想法，一个非常普遍的反应是，你不想要“一群把事情搞砸的失败者”。我们的经验正好相反。首先，在开放源码中，并不需要让每一个提议的改变都带到主源代码分支。因此，你可以选择采纳什么样的修改建议，并且你可以修改或者改进这些建议，只要你愿意。其次，是由你而不是别人来决定是否足够可以信赖一个人，让他直接向主源码树提交代码。你将和所有这些人发展一种关系，观察他们的工作，并且与他们一起工作以便用你的风格改进他们的技能，并且大多数情况下你会希望你能够雇用他们。第三，无论如何都没有那么多这样的人。对于Linux，这个最大的开放源码项目，有上百人被允许在没有监督的情况下提交代码到源码树。其中很多人“拥有”部分代码或者模块，并且他们监督其他的贡献者。第四，几乎所有对源码有访问权限的人都能够认定甚至隔离错误，这对开发者来说事情就简单得多。事实上，多数人都害怕把事情搞砸了并且只是简单的报告问题。
短语“创新在别处”基于这样的观察，那就是并不是所有的聪明人都为你工作。但是假设他们为你工作：假设相对于你的项目和软件来说，外面的人都是失败者。如果你的一个开发者生病了或者离开了你的公司你怎么办？无论怎么替换都必须从这些失败者找人。你真的相信你是这样的处境吗？最好给你的开发人员良好的健康收益，传说中的补偿费，以及保镖。
认为开放源码真的就只是让源码可以让人们看见，也许是吸引人的想法。如果你把代码扔到公共的地方，并且继续在公司内部开发一个私有拷贝，你不是在做开放源码。你是在运行一个源码访问项目或者简单的说提供额外的文档。要发展出正确的信任级别，外面放出来的代码必须是你的开发人员工作的真正代码。你也许有不同的检出模块，当开发者正在这些代码上工作的时候，但是这必须是基于模块的而不能基于整个源码。
并且，你的开放者仅仅是大多数开发者的一部分。他们也许更加专注，也许他们能更好的工作，或者他们也许对你的公司来说有重要的目标，但除此之外他们与所有的外面那些开发者在同一条船上。
这就意味着很多――如果不是全部的话――在其他情况下成为内部开发邮件列表需要被公开。所有的影响了公共源代码的设计和实现决定都必须公开的做出。“我们”与“他们”没有什么区别。
作为这个的回报，你创造了难以置信的忠诚，以及从一个共享的视角把代码推向前进的强烈欲望。你从市场上得到了即时的的和完全相关的反馈。假如你资源短缺的话，也许外面能够提供这些资源。在人力管理上有强烈影响的著作《人件》(由汤姆.德马克以及蒂莫斯.李斯特合著)就建议，打造一个团队的好方法是开始一个共享的项目，然后这个项目变成了这个组的符号象征。也许一开始把人合起来能够搞一个即兴演出，然而最终是所有人的努力完成了一个艺术品才达到了目的。这里有类似的目的。但这不是目的，这是人的社会性的一部分。
你不能付钱给人以便使用他们正在写的或者写完了的代码。这就意味着你不能简单的拿走代码然后直接卖钱。你必须选择一个支持开放源码的商业模式。下面是经典的开放源码商业模式：
还有两种商业模式可用，如果你拥有所有的源码版权，并总是期望从外部开放人员获得最小的贡献的话：
无所不在，赢得人心，几千双眼睛盯着代码，更好的平台安全性，以及从外部世界获得额外的帮助是做开放源码的一些原因。典型的例子是你需要创建一个无处不在的平台，这个平台是为了某些其他的商业目的而存在，你就用开放源码作为达到无处不在目的的导管。
很多人认为开放源码不需要动脑子――你可以为你的团队增加开发人员而不必付薪水给他们。然而，你却需要吸引、培养并且支持这些外部的开发人员，这些需要内部资源。首先也是最总要的一点，它需要你的内部开发者花时间参与到公共的邮件列表中去，回答外部开发者的问题，并且对缺陷修复和代码贡献做出恰当的反应。你的开发人员也需要把系统架构写成文档，因此外面的大牛能够从源代码中理出头绪。你也许甚至需要重写源代码，让它模块化更好，尤其是它当前是一团泥的时候。
另外一项开销是建立和维护开放源码项目所需要的基础设施：一个CVS代码库，一个缺陷数据库，不同的邮件列表，以及一个项目网站。对于大型项目来说，这每一项都需要一个全职工作人员。
要理解开放源码，如果能够把资本主义社会的商品经济和(非资本主义的）礼品经济区分开来会有帮助。在礼品经济中，礼物是互相交换的，以相互欠债的方式达成了一种契约：在最简单的礼品交换的形式中，当一个人送给另外一个人礼物的时候，接收者就欠了给与者的，但不是以钱的形式――反而是接收者变得更像给与者的家人一样，互相欠债是很多的，不同形式的，并且是长期的。一个人给出礼物，通常有现实的期待那就是有一天会收到等值或者超值的礼物，或者说接收者会进一步传递礼物。在开放源码项目中，源代码礼物的回报是建议，缺陷报告，调试，辛勤的工作，赞美，以及更多的源代码。
商品经济建立在短缺之上。最著名的原理“回报递减”，其前提是固定的供给。原材料短缺或者竞争对手短缺能够创造高额的边际利润。“回报递减”的原理因为竞争而成立。
礼品经济是一种“富有”的经济――礼物交换式没有止境的。礼品经济通常在没有经济关系的机构内部，例如血缘关系，婚姻，款待客人，艺术赞助，以及宗教友谊。一个健康的西方家庭运转着一种礼品经济。在一个开放源码的项目中，个体的状态和声望取决于他所贡献的礼物的质量。
要让开放源码在包含公司的社区中成功，基于源代码的礼品经济必须在其外界的商品经济中发展壮大。
礼品经济的概念与我们所称的“工作进行中”的效果有关。这个效果是文学界的作者工作室和软件模式世界工作得如此之好的主要原因。当还有时间影响最终结果的时候，早早的打开窗帘的举动看起来引入了观众深深的反馈，并且当观众被邀请成为合作作者的时候这种反馈变得更加强大了。严厉的批评变成了建设性的批评。责任变成了共有。这些合作作者列出了他们对于作品的关注点，尽管这些关于如何去做的个体的观点也许非常的不同。关注点变成了如何让这个工作做得最好而不是评论作品或者是作者。
开放源码依赖这个反馈。
小结一下，决定让一个项目开放源码意味着它将会与你的私有项目非常不同。所有的决定和设计都必须公开做出。进度计划将依赖与你无法控制的公司外部的人。慢慢壮大的社区将会选择属于自己的生命，很可能会把项目引入你没有想到也不希望的方向。
你的商业模式和过程必须不同，否则你不会成功。你不能把开放源码作为你传统过程的附加过程。决定做开放源码就像决定去结婚组建家庭一样：给出了承诺，一旦开始走那条路了就会改变你生活的方式。
【本文翻译仅为外语学习及阅读目的，原文作者个人观点与译者及译言网无关】
