开源软件 是什么意思？当您向别人解释时，您如何在不重新发明它的情况下传达开源的价值和精髓？自从 1997 年首次提出这个词以来，开源领域已经有了许多来之不易的教训，我们不应该忘记这些教训。
为了帮助理解，我收集了 12 个对我来说有意义的迷因，以帮助分享历史、奠定基础，并为开源软件是什么以及它对整个软件行业的意义提供背景。
这些最初的迷因与软件的构建方式有关。我相信它们定义了我们所看到的成功的开源项目，因为它们是关于软件本身的基本原理。理解这些迷因的项目会成功。以宽松许可授权并在社区中协作开发的软件，可能是我们用于创建和维护优秀软件的最佳和最有效的软件重用机制。
迷因 #1：自从我们编写软件以来，我们就一直在共享软件。
IBM 在 20 世纪 50 年代后期开始了一个计算机会议，至今仍在继续，名为 SHARE。DEC 在 20 世纪 60 年代开始并支持 DECUS 社区，您可以在他们的会议上购买（媒体成本）装满由其他人编写和贡献的软件的磁带。USENIX 始于 20 世纪 70 年代，与早期 UNIX 版本的磁带发行同时进行。但这种共享可以追溯到 20 世纪 40 年代在普林斯顿高级研究院进行的第一个可编程计算机的工作。
迷因 #2：编写优秀的软件是一项艰苦的工作。
我相信共享归结为编写优秀的软件很困难这个简单的现实。软件创建主要受两个比率支配：普通开发人员一天可以编写的代码行数，以及合理流程中每千行代码的错误数。从语言演变到架构重用，所有软件的进步都是为了尝试用更少的代码行编写更多更好的软件。软件构建可靠性、配置管理、审查工具和流程以及测试方面的进步都旨在减少合理软件交付流程中的错误数量。
迷因 #3：没有纪律就没有规模。
编写优秀的软件需要纪律。当您查看作为产品或开源项目获得成功的软件时，通常在其创建过程中会进行同行评审，存在版本控制和配置管理，并且构建自动化和测试框架会随着软件的发展而发展。如果没有评审、配置管理以及构建和测试的自动化，软件就无法在用户社区中扩展，也无法作为拥有数千或数百万用户的产品进行扩展。需要维护软件的核心小组必须能够回答“正在执行什么软件”。否则，就会陷入混乱，并且无法增长。
Linus 定律大致可以表述为“如果有足够的眼球，所有错误都是肤浅的。” 我认为这实际上是对提交审查过程的描述。研究表明，在审查中发现的错误比在测试中发现的错误更多。一个健康的社区总是对签入有一个严格的审查过程。
迷因 #4：软件本质上是动态的。
程序通过使用而演变。错误被发现并修复。新的用途被发现，从而驱动新的功能。程序被磨练和强化。程序从一个环境移植到另一个环境。不幸的是，版权在 1980 年成为“保护”软件发行渠道的方式。人们可能不明白软件演变和衍生品创建的速度有多快，或者这种动态性只会随着互联网和万维网的发展而加速。我们的共享网络带宽已经从磁带大小的数据包以及会议日程和期刊发布延迟，发展到全天候的实时全球创建、分发和维护。
让我们来看看一些与开源软件的社区方面相关的迷因。
迷因 #5：你总是得到比你付出的更多。
这就是社区协作开发的经济效率。贡献流是项目软件发展的生命线。贡献者冒着很小的风险付出贡献或错误修复，但获得了整个可用于贡献者认为合适的软件工作体。对于顺路贡献，无论开发人员的经验和专业知识如何，这都可能是开发人员必须付出的唯一实质性贡献。
获得的回报多于贡献适用于公司和个人。红帽、英特尔和 IBM 等公司的专用资源和投资，使他们每个人都能够利用整个 Linux 操作系统追求不同的业务战略。公司可以将优秀的软件项目塑造成解决客户问题的产品。
迷因 #6：白嫖者对于成功至关重要。
有人偶尔观察到，对于开源项目的每一千个用户，可能有一百人会报告一个错误，其中十人可能会贡献一个潜在的修复程序，而其中只有一个人阅读了贡献指南。现实情况是，根据贡献流和增长来衡量社区成功有三个入口。软件需要非常容易安装和使用，这样项目才能吸引大量用户。在用户群中，将会有开发人员。软件需要非常容易构建和测试到已知状态，这样想要更改某些东西（为了自己的自私利益）的开发人员可以轻松地做到这一点。将更改贡献回项目的能力需要非常容易，这样贡献才能流动。大量的白嫖者意味着你做得对。有了大量的用户，就会有可能出现开发人员，以及贡献的可能性。但项目有责任使其变得容易。
试图创建开源项目的公司通常很难理解社区。他们认为不知何故有人应该给他们一些东西。他们习惯于广播社区（即开发人员网络）而不是协作。有三个迷因适用于公司和开源。
迷因 #7：不要将产品与项目混淆。
项目是可安装、可运行并解决有趣问题的正在运行的软件集合。它是代码中的协作和对话。项目不是产品。产品是为客户解决问题以换取金钱的东西。虽然许多优秀的软件可以来自一个运行良好的开源项目，从而减轻工程方面的一些工作，但要将其转化为为客户解决问题的产品，仍然需要做大量的工作。Linux 内核是一个项目。Fedora 是一个发行版项目。RHEL 是一个产品。产品满足客户对物有所值的期望。它们开箱即用即可安装、运行，并附带保修和赔偿、服务（支持、升级、培训、咨询）和产品特定文档。它们可能是包括硬件和服务在内的更大产品组合的一部分。
这个迷因的一个推论可能是：“没有人会来为你构建产品。”
迷因 #8：不要将客户与社区混淆。
如果迷因 #7 是关于工程和商业模式，那么迷因 #8 是关于消息传递和销售。社区和客户生活在不同的价值空间中。客户花钱是为了加快解决方案并消除风险，而社区（社区中的个人）则协作构建自己的解决方案。一些使用开源软件的公司认为项目社区是产品管道的一部分，当他们在社区论坛中找到客户时，他们会更加相信这一点。他们甚至可能认为社区项目是一种先试后买的东西。所有这些都是错误的。
公司与其相关社区与付费客户进行的对话是不同的。每个对话都有特定的工具和参与规则，以及要捕获和考虑的指标。社区成员非常有价值，但他们不是客户。
迷因 #9：早在开源定义之前，公司就共享了宽松许可的软件。
Athena 项目（X11、Kerberos）始于 1983 年。开放系统基金会（OSF/Motif、OSF/1）始于 1988 年。DEC 从早期的 BSD 版本开发了 Ultrix，Sun Microsystems 开发了 SunOS。这不是新行为。
最后，是一些关于许可和围绕开源软件的法律讨论的迷因。
迷因 #10：软件自由和开源许可是不同的讨论。
争论软件自由与开源软件，就像争论民主是否优于资本主义，或者言论自由是否比自由市场更重要一样。它们各自都是重要的讨论，人们通常会对其中一个主题或另一个主题有自然的亲和力，但它们不是同一个讨论。它们不是连续体上的终点。软件自由的语言由用户的权利定义。开源软件的语言由许可证的属性定义。这些是不同的讨论。
迷因 #11：每个开源项目都需要许可证。
软件受版权法保护。许可证定义了其他人如何使用它。选择 OSI 批准的许可证。您选择的许可证是对您希望在社区中建立的社会契约的声明。虽然最近历史上很多人都默认使用 Apache 软件许可证作为“商业友好”许可证，但情况可能并非如此。互惠许可证与宽松许可证的讨论不是关于自由软件与开源软件的讨论。互惠许可证可能是最佳的生态系统友好型许可证。
迷因 #12：基金会有其存在的意义。
非营利组织可以提供知识产权 (IP) 所有权的公平竞争环境和中立性，从而使公司能够对运行良好的开源项目进行专项投资。
最后的想法
在 20 世纪 90 年代中期至后期，在 开源 软件这个术语被创造出来之前，我和同事们用宽松许可的软件建立了一家软件公司。这没有什么神秘之处。我们收集并移植了大约 250 个软件包，这些软件包涵盖了大约 25 种不同的许可证，包括 Berkeley 许可证、MIT 许可证和 GPLv2，以及我们自己的软件，以及微软拥有的一些重要软件，并受他们给我们的许可证的约束。我们将其开发成我们公司支持的产品，该产品受我们产品许可证的约束。我们以适当的方式参与了那些不同的协作社区。作为一群工程师和商业人士，我们在 UNIX 系统社区中成长，因此我们受益于丰富的协作和共享历史，可以从中汲取经验。
当我回顾这些迷因时，我认为它们与 20 年前我会写下的迷因相同，但也许少了历史和经验带来的清晰度。
您会在列表中添加哪些迷因？您有什么经验？
8 条评论