开源软件意味着什么?当你需要向别人解释时，如何省心又省力地传达开源的价值和精髓?自从开源这个短语在1997年首次提出以来，业界在开源方面已经获得了许多来之不易的经验教训，我们不应该忘记这些经验教训。
为此，我收集了12个文化基因，在我看来它们有助于分享历史、搭建舞台，并为开源的定义以及它对整个软件行业的意义提供上下文。
这头几个文化基因涉及软件的构建。我认为，它们定义了我们所认为的成功的开源项目，因为它们就是涉及软件本身的基本方面。了解这些文化基因的项目才会成功。采用宽松许可证、注重社区的软件可能是我们用来构建和维护优秀软件的最出色、最高效的软件重复使用机制。
第一个文化基因：自我们编写软件以来就共享软件。
上世纪50年代末，IBM开办了一场计算机大会，这个大会一直持续到今天，名叫SHARE。DEC在60年代开办，支持DECUS社区，你可以在其会议上购买装满其他人编写和贡献的软件的磁带。USENIX起源于70年代，当时适逢使用磁带发布早期UNIX版本。但是这种共享的做法完全可以追溯到40年代普林斯顿高级研究所的第一台可编程计算机上的开发工作。
第二个文化基因：编写优秀软件是艰苦的工作。
我认为，共享归结为这个简单的现实：编写优秀软件很困难。软件开发领域有两大比率：开发人员在一天之内平均可以编写的代码行数，合理开发流程出来的每千行代码的错误数量。从语言进化到架构重复使用的所有软件方面的进展围绕这个中心思想：用更少行的代码编写出更多更优秀的软件。软件构建可靠性、配置管理、审查工具和流程以及测试方面的进步，都旨在减少合理的软件交付流程出来的错误数量。
第三个文化基因：没有毫无章法的规模扩展。
编写优秀软件离不开章法。如果你看一下作为成功产品或者开源项目的软件，构建时通常会由同行审查，实行版本控制和配置管理，构建自动化和测试框架与软件一同完善。要是没有审查、配置管理以及构建和测试自动化，软件无法在用户社区里面进行扩展，作为一款产品也无法在成千上万的用户当中进行扩展。需要维护软件的核心小组一定要能够回答“软件执行什么”。
林纳斯定律可以笼统地表述为“给予足够的关注，所有代码错误都会浮现出来。”我认为这实际上表明了提交审查过程的重要性。研究表明，审查环节发现的错误比测试环节发现的还多。一个健康的社区势必在代码签入(check-in)方面有一套严格的审查流程。
第四个文化基因：软件天生是动态的。
程序因使用而完善。错误被发现后要加以修复。发现新的用途，从而推动新功能。程序不断得到磨练和加强。程序从一个环境移植到另一个环境。遗憾的是，版权在1980年成了“保护”软件发布管道的机制。人们也许不明白软件的发展有多快、衍生版的开发有多快，或者也许不明白物联网和万维网问世后，这种动态性只会加快。我们共享网络带宽已从磁带大小的口袋、会议日程表和杂志出版延迟变成了全天候的实时全球构建、发布和维护。
不妨看一下与开源软件的社区方面有关的几个文化基因。
第五个文化基因：你得到的总是多过给予的。
这是社区协作式开发的经济效率。不断贡献可谓是项目软件发展的生命线。贡献者贡献代码或提供修正版没有多大的风险，但是得到的好处是，整个软件可以按贡献者觉得合适的方式来使用。而至于路过式贡献，这可能是开发人员给予的唯一重大贡献，不管他们的经验和专长如何。
得到的回报大于贡献既适用于个人，也适用于公司。来自红帽、英特尔和IBM等几家大公司的专用资源和投入让它们得以借助整个Linux操作系统来实行不同的商业战略。公司可以将优秀的软件项目变成解决客户问题的产品。
第六个文化基因：有人吃白食是成功的关键。
坊间传闻，在一个开源项目的每1000个用户中，有100人可能报告软件错误，其中10人贡献潜在的修正版，其中只有1人仔细阅读贡献准则。实际上，社区成功有三条途径（社区成功的衡量标准是代码贡献）。一个是软件需要异常容易安装和使用，那样项目才会获得大量用户。二是用户群当中会有开发者。软件需要异常容易构建和测试，那样想要更改（为了自己的私利）的开发者很容易更改。三是需要异常容易能够回过头来向项目贡献变更，那样贡献才会源源不断。有大量吃白食的人意味着你干得不赖。这样，如果有大量用户，对开发者来说会大有潜力，贡献的可能性也会随之而来。但是项目的责任是确保容易。
试图构建开源项目的公司常常很难了解社区。他们想，有人得为自己提供东西。他们习惯于向社区（比如开发者网站）发号施令，而不是协作。有三个文化基因适用于公司和开源。
第七个文化基因：不混淆产品和项目。
项目其实是一组安装和运行后可以解决某个问题的切实可行的软件。它是一种以代码来说话的协作和交流。你需要了解项目不是产品。产品是以解决客户的问题来盈利的东西。虽然很多出色的软件来自于运作良好、为工程技术减少一些工作的开源项目，但是仍有艰巨的工作要做，才能将它变成对客户而言解决问题的产品。比如Linux内核是项目，Fedora是发行版项目，RHEL却是产品。产品以满足客户对价值的期望来盈利。产品可默认安装、运行，附带保证和赔偿，还有服务（支持、升级、培训和咨询）以及针对特定产品的说明文档。它们可能是包括硬件和服务的更庞大产品组合的一部分。
这个文化基因的一个推论可能是：“没有人来为你构建你的产品。”
第八个文化基因：不混淆客户和社区。
如果说第七个文化基因涉及工程技术和商业模式，那么第八个文化基因就涉及讯息和销售。社区和客户的价值观不一样。客户是花钱来加快解决问题，消除风险，而社区（及社区中的个人）通过合作，构建自己的解决方案。使用开源软件的一些公司认为，项目社区是产品管道的一部分；他们在社区论坛中找到客户时，就会进一步这么认为。他们甚至可能认为，社区项目是一种先试后买的东西。可是，这一切都是错误的。
公司与相关社区的交流跟其与付费客户的交流不一样。每次交流都有特定的工具和交战规则，以及需要记录和考虑的度量指标。社区成员非常具有价值，但他们不是客户。
第九个文化基因：早在开源定义之前，公司就共享宽松许可证的软件。
Project Athena(X11，Kerberos)始于1983年。开放系统基金会(OSF/Motif，OSF / 1)始于1988年。DEC和Sun从早期的BSD版本分别开发出了Ultrix和SunOS。这不是新的行为。
最后，几个文化基因涉及开源软件方面的许可和法律讨论。
第十个文化基因：软件自由和开源许可是不同的讨论话题。
争论软件自由与开源软件就好比争论民主主义是否比资本主义更好，或者争论言论自由是否比自由市场更重要。它们本身都是重要的讨论，人们往往对于某个主题有天然的倾向性，但它们是不一样的讨论。软件自由语言由用户权利来界定，开源软件语言则由许可证的属性来界定。这些是不同的讨论。
第十一个文化基因：每个开源项目都需要许可证。
许可证定义了别人可以如何使用软件。软件受版权法保护，需要选择经OSI批准的许可证。你选择的许可证声明了你在社区中想要的那种社会契约。虽然近年来，很多人默认选择Apache软件许可证为“对商业友好”的许可证，但它未必就是如此。互惠许可证还是随意许可证并不是谈论自由软件还是开源软件。互惠许可证也许是对生态系统友好的最佳许可证。
第十二个文化基因：基金会有一席之地。
非营利性组织可提供公平的竞争环境和IP（知识产权）所有权的中立性，从而让公司能够专门致力于一家运行良好的开源项目。
结束语
上世纪90年代中期至末期，我和同事利用宽松许可证软件开办了一家软件公司，那时候开源软件这个术语还没有问世。这其实没有太大的神秘性可言。我们收集并移植了大约250个采用25个不同许可证的程序包（这些许可证包括伯克利许可证、MIT许可证和GPLv2），并结合我们自己的软件，还有一些重要软件是微软拥有的，其许可证允许我们使用。我们把它开发成了一款我们公司全力支持的产品，这款产品采用了我们自家产品的许可证。我们以不同方式参与了那些不同的协作社区。作为一批工程师和商界人士，我们能够在UNIX系统社区中不断成长，得益于悠久的协作和共享历史。
回头看看这些文化基因，我认为它们与我在20年前会写下来的文化基因一模一样。
你会补充什么样的文化基因?你有什么样的经验之谈?欢迎留言交流。
转载请注明：开发者关系 »
