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