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