关于开源软件的12条模因

题记

开源之道的主要作者适兕在LC3中国的会议上拜会了知名的社区人物：Stephen R. Walli， 并表达了自己心中的崇拜之情。Stephen R. Walli先生不仅对于开源有着切身的理解和认识，也希望能够让更多的人知道他的想法，于是开源之道经过Stephen R. Walli先生的允许，将陆续的将他的文章翻译为中文，将他对于开源和商业的思考介绍给本土的读者。本文是他的第二篇，第一篇根本就没有所谓的开源商业模式。

何为memes？ memes 一般翻译为模因，对于模因目前比较公认的定义是“一个想法，行为或风格从一个人到另一个人的文化传播过程。 ” – wikipedia

开源软件意味着什么？当你向其他人解释的时候，你是如何传达开源的价值及其本质的？而不是自己另外创一套。要知道开源自从1997年被发明以来，已经有很多成功的案例，但是也有很多惨痛的教训。

为了未来的人们更少的犯错，我特地整理了12条memes，这些对于我来说意义非凡，均是我个人里程碑式的见解，为开源软件提供了背景知识，以及其对整个软件行业的意义。

注：前三条是和软件本身的构造有关，我坚信之所以我们能够看到成功的开源项目，是因为软件本身的根基所决定。软件在宽松的许可下以及社区的工作方式，或许是最好的、最高效的软件重用机制，这就是让我们能够创造和维护更好的软件的条件。

Meme #0: 人类从撰写软件的哪一天开始就是分享软件代码的

IBM是在上世纪50年代后期开始做计算机研讨会，一直持续到现在，他们称之为：共享。DEC 则在上世纪60年代开启的，支持了一个叫做“DECUS”的社区，在那里我们可以购买（仅介质的价格）到由其他人撰写、贡献的软件磁带。USENIX 是在稍后的70年代出现的，与早期UNIX版本的磁带分发兼容。所有的这些分享行为都可以追溯到19世纪40年代普林斯顿高等研究所，那里的第一台可编程计算机上就是如此工作的。

Meme #1: 撰写优秀的软件是非常难得的

我深信人们之所以愿意分享，可以归结为一个简单的事实：撰写优秀的软件是非常困难的。 关于软件的创造工作可以用两个维度来说明，即开发人员平均每天的代码开发行数，和来自合理过程的每千行代码的错误数量。无论是编程语言演进还是架构重用，所有软件都是试图用更少的代码编写更多更好的软件。软件构建的稳定性、配置管理、审核工具和流程、以及测试，所有的这些举措，目标都是在合理的软件交付过程中减少缺陷的数量。

Meme #2: 没有规矩无以成方圆

能够撰写好的软件，一定要有相应的约束条件。当我们去审视一款成功的软件产品，亦或是一个成功的开源项目时，通常情况下，其该有的都会有，如创建过程中进行同行评审，版本控制和配置管理、使用软件构建自动化和测试框架。若是没有这些，则就不可能在使用它的社区中传播，更不用说让成千上万的用户当作产品来使用了。项目的核心成员需要用心来维护，来回答“软件在执行什么”这样的恒久问题。否则，一切将陷入混乱、停止增长的状态。

Linus法则，不够严肃的说法是：足够多的眼球，缺陷就无处藏身。 我认为这实际上是一个关于提交、审核过程的陈述。经研究表明，代码审核相比于测试，能够捕获更多的缺陷。一个健康的社区总是有较为严谨的审核程序的。

Meme #3: 软件本质上动态发展的

程序在被使用的过程中逐渐的进行演进。缺陷渐渐的被发现并修复，发现新的用途并进一步驱动新的功能项。程序随着岁月的演进，逐渐的稳定、健壮。而且从一个环境移植到另外的环境。然而，在上世纪80年代，版权成为了“保护”软件分发管道的方式。伴随着互联网的发展，软件的发展速度、衍生品被创建超乎人们的想象。我们所共享的网络带宽，已经从mag-tape-sized 数据包、会议日程、日志发布，演进到全天候在全球范围内的实时创建、分发和维护。

接下来，我们来看看一些关于开源软件社区方面的memes

Meme #4: 对于开源，得到的总是比给予的多

这是一个在社区协作开发的经济效应问题。贡献流程是项目软件演进的生命之泉。贡献者只需花费很小的代价就可以贡献代码和修复缺陷，但是对于软件本身来说却受益颇多，相对来说，驱动持久的贡献，对于开发者来说收获的还有经验和专业的提升。

得到的总是比给予的多，不仅适用于个人，也适用于公司。如红帽、英特尔、IBM等专门对开源投入资源和资金，从而在整个Linux操作系统追求不同的业务战略。企业可以将好的软件项目打磨成专业的产品，进而满足客户的需求。

Meme #5: 吃瓜群众是成功的关键

有江湖传言是这么讲的：“一个开源项目每有一千个用户，相应就会有100为报告bug的同学，对应会有不到10位同学会修复一下，而其中仅会有一人会去读贡献者指南。”

虽说是传言，但是说明了一个道理，就贡献者流量和增长亮而言，社区的成功有三个上升趋势来度量。

• 该软件易于安装和使用，因此该项目获得了大量用户。
• 在这些用户当中，会有开发者。软件需要能够很容易的被构建，在已知的状态下做测试，那么这些开发者（为了自己的需要）就会上手去修改代码。
• 在这些开发者中，也会有能够有能力提交到项目中优质开发者。所以贡献的流量乃衡量之根本也。

有很多吃瓜群众其实意味着你做对了事情，只有拥有了足够多的用户，就会有开发者参与的可能性，那么一旦开发了就可能成为贡献者。但是作为项目的发起者要做的事情是将上述所有过程都变得更为容易。

企业在尝试创建开源项目时，常常困惑于理解社区的时间。这些企业会想当然的认为，我都开源了，人们应该对项目做些什么。要知道，基于这个思路就不太对路。这样的理解适用于广播社区（如开发者网络），而并非协作的社区。以下三条Memes适用于这些企业。

Meme #6: 不要将产品与项目混淆。

一个软件项目可能是很多能够独立安装、运行、工作的软件的集合，以解决特定的问题。这一切都围绕代码来进行协作和讨论。项目不是产品。一款产品是某些能够解决用户问题的，且用户会为此而付费。虽然许多优秀的软件是从一个运行良好的开源项目中所孵化出的，从而减少了工程上的工作量，但依然还有大量的工作要做，以便将其变成为客户解决问题的产品。

举例来说，Linux内核就是一个项目，Fedora是一个发行版项目，RHEL就是一款产品。产品可以满足客户的预期，用户就会为此价值而付费。产品可安装开箱即用、运行、并提供保修和赔偿，服务（支持，升级，培训，咨询）和产品特定文档。软件产品还可能是更大产品的其中一个部分，其余的包括硬件、服务等。

此memes可以进一步推论为：“没有人去为你而构建你自己的产品。”

Meme #7: 不要将客户与社区混淆。

假如说 Meme #6 是关于工程和商业模式的话，那么本meme就是关于信息和销售的。社区和顾客是完全不同的价值观的群体。顾客是付费，希望问题得到解决，而且降低风险，然而社区（社区中的独立个体）则是协作创建自己的解决方案。一些公司使用开源软件是认为社区的项目可以成为产品线的一个部分，而且这些公司还认为可以在社区的论坛上找到一些顾客。他们甚至可以认为社区项目是一个尝试购买之前的事情。所有这一切都是错误的，想当然的。

公司的相关社区和付费顾客在对话上完全是不同的。就对话而言，每个会话都有具体的工具和参与规则，以及捕获和考虑的指标。社区成员是非常有价值的，但他们不是客户。

Meme #8: 公司在开放源代码定义之前就已经拥有自由许可的软件。

著名的Athena项目（X11、Kerberos）是开始于1983年，开放系统基金会（OSF/Motif、OSF/1）是1988年成立的，又如DEC开发Ultrix，太阳微系统公司开发SunOS均是在BSD发布之前进行的。所以说商业公司玩共享这套，并不是新鲜事。

最后，关于许可的一些memes以及开源软件的法律讨论。

Meme #9: 自由软件和开源软件的许可是不同的话题

对于自由软件和开源软件的争论，这就好比于辩论民主是不是优于资本主义，或者说是自由言论一定比自由市场更卓越。这些主题都是人们根据自己的权利做出的重要讨论，且人们会自然而然的这个或那个有更多的倾向性，但是这完全是不同的话题。他们都在持续发展，远远没有终点。自由软件的主题更多的是关于用户的权限定义，而开源软件的主题则是许可证的属性所定义。

这完全是两个不同的话题。

Meme #10: 每个开源项目都需要许可证

软件受版权法保护。 许可证定义了其他人该如何使用它，请选择一个OSI 指定的许可证。你所选择的许可证，则表明了你希望社区遵守何样的社会契约。虽然近期的很多人都将Apache软件许可证默认为“商业友好”许可证，但事实并不一定是这样。互惠许可协议针对宽松许可协议，并不是讨论开源软件和自由软件。要知道，互惠许可协议可能才是最佳的生态友好型许可协议。

Meme #11: 基金会有其存在的价值

非营利机构可以提供IP（知识产权）所有权的公平竞争环境，并保持中立性，从而让公司能够投资于运行良好的开源项目。

结语

在上世纪90年代中期，在开源软件开发之前，我和同事们在自由许可的软件下创建了一个软件公司。它没有太多神秘的地方，我们收集和移植了约有250多个软件包，囊括了25个不同的许可协议，其中包括伯克利许可证、MIT许可证、GPLv2，还有我们自己编写的一些软件包，甚至还有微软授权给我们的。我们以公司的名义将其开发成为一款软件产品，整体看起来只有一个我们公司的许可协议。我们对各个社区进行了权衡利弊，以不同的方式参与了不同的社区。作为一群工程师和商业人士，我们在UNIX系统社区长大，我们亦受益于其协作和共享。

当我回顾这些memes时，我认为它们和我20年前写的没有什么两样，只是20年前的结论缺乏时间的验证罢了。

你是否有自己认识的memes添加进来？有何种经验？

作者介绍

Stephen R. Walli 是一名技术主管、创业者、咨询顾问、作家、国际商务人士、系统开发者、软件架构Geek、典型的外交官。热爱构建让客户欣喜若狂的团队和产品。自1980年以来，我一直在IT行业担任客户和供应商。曾是Hewlett Packard Enterprise的杰出技术专家。目前在Docker公司担任顾问。