案例研究
PDF案例研究
社区的力量
开源的挑战
与 Reynold Xin、Wes McKinney、Alan Gates 和 Chris McCubbin 的讨论
在开源开发者面临的众多挑战中，最令人望而生畏的是一些其他程序员几乎从未考虑过的问题。这是因为大多数程序员在“其他人”处理这些事务的环境中工作——例如，在法律部门或人力资源部门工作的人。但是，当没有这样的人可以求助时，该怎么办？
构建成功的开源社区取决于许多不同的要素，其中一些是任何开发人员都熟悉的——清晰且存在的市场机会、明智的方法、高效的编码等等。同样重要的是招募、激励、指导、管理和调解纠纷的技能——所有这些都无需使用各种形式的报酬来奖励和激励贡献者。
到底需要做些什么才能完成所有这些工作？我们将让一些最成功的开源项目的领导者根据他们自己的经验来解答这个问题。参与以下讨论的有 Databricks 首席架构师 Reynold Xin，他以在 Apache Spark 上的工作而闻名；Hortonworks 联合创始人 Alan Gates，他在雅虎实验室工作期间帮助开发了 Hadoop、Pig、HCatalog 和 Hive；以及 Ursa Labs 创始人 Wes McKinney，他负责创建 pandas（Python 数据分析库），目前负责领导 Apache Arrow 项目。
Chris McCubbin 代表 参与讨论，他是亚马逊网络服务公司的高级应用科学家。
CHRIS McCUBBIN Linux 于 1992 年以开源形式发布。然后在整个互联网泡沫时代出现了第二波开源产品。现在启动一个开源项目是什么样的？
REYNOLD XIN 一个很大的不同是整个基金会概念确立了。Linux 早期基本上只是一个业余爱好项目，在这方面，它与 90 年代开始的许多其他开源项目类似。现在有了 Linux 基金会，它拥有数百万美元的年度运营预算。虽然由志愿者运营的 Apache 软件基金会没有像那样的运营预算，但它已经成功地为自己创建了一个重要的品牌。
从 90 年代末到特别是 2010 年，许多开源项目一开始就成为基金会的原因之一是为了更好地处理围绕这些项目发展起来的社区。在过去的几年里，这种趋势有所逆转。很大程度上由于 GitHub 的兴起，现在越来越多的开源项目只是通过将存储库放在那里来启动。许多以这种方式启动的项目在没有任何基金会的帮助下也取得了相当大的成功。我绝对认为这是当前更重要的趋势之一。
CM 当然，近来这个领域变得更加拥挤。也就是说，对于每个问题，现在似乎至少有几个项目提供潜在的解决方案。但有时很难弄清楚其中哪些项目实际上正在积极维护。
RX 完全正确。但即使与基金会相关联也不一定意味着一个项目将得到积极维护。项目社区可能会来来去去。事实上，许多开源项目——尤其是较小的项目——都依赖于一两个关键贡献者。一旦这些贡献者离开，就没有太多东西可以支持该代码。此外，即使是中等规模的、由成功的基金会支持的项目，您也不能完全确信代码会得到良好维护。
ALAN GATES 从另一个角度来看，我想说在过去的 20 年里，我们也见证了企业影响力的日益增长。即使在 15 年前，当 Hadoop 推出时，也有公司会支持某些项目并提供各种类型的支持。到那时，很多人已经在使用 Linux 了。
公司也开始公开他们支持哪些项目，以便将其作为自身形象的一部分进行宣传。红帽是第一个真正成功做到这一点的公司之一。然后其他一些公司也开始支持 Linux。在这一点上，企业对开源项目的参与已经远远超出了这一点——无论是在他们如何使用开源以及如何组织他们的开发工作方面。
RX 从某种意义上说，开源已经赢了，引用一位不愿透露姓名的朋友的话。
CM 我绝对认为情况是这样的。我自己的经验是，在我 2012 年帮助启动的一家初创公司中，我们基本上完全使用了开源作为我们的框架。这代表着与我以前做过的任何事情都截然不同的巨大转变，我以前所做的一切几乎都是 DIY。
您是否仍然看到这种趋势？或者现在是否对开源有更多的抵制，因为可维护性问题和诸如此类的事情？
AG 现在有一些抵制。一些公司开始说：“我们真的想参与开源，但现在正确的方法是什么？”您会看到不同的公司尝试不同的许可模式，所以感觉他们确实想继续参与。正如 Reynold 所说，开源已经赢了。但问题是，正确的参与形式是什么？
WES McKINNEY 总的趋势是，公司越来越希望他们依赖的核心平台完全开源。但是，多年来，在 npm/JavaScript 生态系统等地方出现了一些令人不安的安全相关问题，这些项目不受基金会监督，或者可能只是没有大型集中式开发团队的好处。越来越多的公司已经开始决定，虽然他们希望他们所有的核心平台软件都是开源的，但他们也愿意为高级企业功能的开发以及支持和赔偿——或者至少是一级和二级错误修复付费。
即使追溯到 2010 年之前，也存在一种摆脱专有产品和供应商锁定的趋势，但人们花了一些时间才认识到与维护良好和支持良好的开源软件合作有多么重要。事实上，作为 Apache Hadoop 生态系统一部分出现的供应商——特别是 Cloudera 和 Hortonworks 等公司——正是那些专门为大型公司、金融机构和保险公司提供安心和安全级别，以及所需支持的公司，以便他们有足够的信心将他们的业务押在开源软件上。
因此，我认为发生的事情是，公司仍在为软件付费，但方式与以前不同。过去他们为软件许可证付费，但现在他们为防止故障和潜在损失的保证付费。也就是说，随着组织开始投入数十亿美元，赔偿已成为一个更大的问题。然而，我们仍然存在像 Equifax 黑客攻击这样的问题，这是由于该组织未能应用开源生态系统中已 readily 提供的安全补丁而造成的。这现在已成为一个经典案例，说明用户未能正确维护其开源软件时会发生什么情况。
CM 这就是商业软件提供有趣对比的地方。例如，微软等供应商强制用户进行更新。您认为开源世界应该开始朝着这个方向发展吗？
AG 在许多开源生态系统中，实际情况已经是，提供基于开源软件的商业产品的供应商倾向于提供通常被称为下游构建的产品，这些产品基本上将开源版本与任何适用的错误修复或安全补丁组合在一起。
在某种程度上，这减轻了开源项目本身承担全部支持负担的压力。如果在一款开源软件中发现安全漏洞，那么与该项目相关的供应商有关系的客户很可能会向该供应商寻求该软件的修补版本，主要是因为他们知道他们可能会更快地获得修补软件。事实上，这就是许多组织最初与这些供应商签订合同的原因。
RX 开源不一定关于免费软件。相反，它更多地与公司对构建生态系统和社区的内在兴趣有关，这将帮助他们降低雇用新员工然后让他们快速上手的成本。也就是说，如果您的开发环境基于一些非常流行的开源技术，那么找到满足您要求的人才将不会那么困难。
WM 这让我想起了大约 10 年前我第一次参与开源软件的时候，当时我在一家名为 AQR Capital Management 的公司工作，这基本上是一家量化投资管理公司。当时我提出了与 Reynold 刚才提出的相同的论点，以解释为什么我们应该开源我一直在开发的一个库——理由是外界的人们会开始熟练地使用该软件，这反过来会为我们创建一个人才库，我们可以从中招聘。顺便说一句，我在这里谈论的软件最终成为了 pandas 项目的基础。
那时，在 2009 年，我的论点有点牵强附会，但现在这几乎已成为常态。将内部开发的软件作为开源软件提供，以便它可以吸引用户社区的模式已被证明对那些首先产生这些新软件能力的公司有利。当然，许多大型公司已经开始启动开源项目，希望吸引大量用户——其中一些用户他们稍后可能会招募。
AG 假设您有一个好的项目，实际上设法解决了常见问题，我绝对认为这是让人们加入您的软件的好方法。
WM 另一个问题与项目治理有关，这是人们在 GitHub 上开始的现代草根项目中往往较少考虑的事情。也就是说，治理现在通常只是事后才想到的，仅仅是因为如此多的项目只有一两个核心开发人员或维护人员做出所有决策。
但是，随着项目的增长，您了解到有数十甚至数百人拥有对您的项目存储库的写入权限，决策过程以及确定谁来决定是否应该合并补丁或拉取请求的任何决定开始变得更加重要。而且，特别是当许多商业利益相关者参与一个项目时，这可能会变得更具政治色彩。事实上，您有时会遇到直接竞争对手为彼此都认为重要的项目做出贡献，这通常会导致关于谁的工作应该合并以及某些工作是否已准备好合并的争吵。
就一些较大的项目而言，我认为关于治理问题的冲突最终消耗了这些项目委员会的大量精力。因此，我经常鼓励开源开发人员提前计划他们打算如何处理治理问题，同时还要考虑一旦他们扩展到更大的开发人员社区后他们将要做什么。拥有 20 个核心开发人员或 100 个核心开发人员将要出现的问题与您只拥有两个核心开发人员将要看到的问题确实截然不同。
重要的是讨论您将使用哪种机制来做出决策，无论是共识还是任命某种终身仁慈独裁者，或者其他任何方式，因为您希望避免在您已经面临冲突时才开始弄清楚这一点时肯定会产生的挫败感。
在任何实际编码开始之前，还有很多事情需要理清。除了明确定义治理结构和争端解决机制外，还需要确定适合手头工作的工具和测试。
但是，当然，并非项目的所有要求都可以在事先预料到，并且始终需要一定程度的适应性。随着项目的进展，个性会改变，优先级也会演变。没有什么比社区规模的持续增长更能严重考验早期做出的假设和准备。角色会改变，会提出更多额外的功能，并且会积累越来越多的需要管理和跟踪的问题。项目根据这些要求进行扩展的能力对于这项事业的成功，乃至生存都至关重要。
CM 您会如何描述项目维护人员一天的工作？
WM 这取决于哪一天。在某些情况下，感觉就像消防员的一天。但是，特别是对于那些包含大量贡献者的项目，我想说，日常关注的大部分都与确保贡献者及时获得关于他们的工作在测试和持续集成方面的进展的反馈有关。
确保某些东西确实准备好合并到项目中的持续集成工作需要及时进行，否则您最终会积压。这可能会导致贡献者感到沮丧，如果他们觉得他们没有及时获得反馈，或者没有看到他们的工作在合理的时间范围内被合并，他们可能会脱离该项目。在最坏的情况下，一旦人们开始觉得他们无法为项目做出有意义的贡献，甚至可能导致分支。
AG 另一方面，我想说没有人仅仅为了成为维护人员而加入开源项目。我鼓励维护人员尝试取得某种平衡。正如 Wes 所说，您肯定需要花一些时间与贡献者互动，并努力及时合并他们的代码。
但您也需要完成自己的工作，如果贡献者开始认为这就是为什么他们的东西没有像可能的那样快地被合并，这可能会让贡献者感到沮丧。但是，看待这个问题的另一种方式是，也许这表明时候到了，让那些贡献者中的一些人晋升为提交者角色，以便工作可以稍微分散开来。
RX 我多年来注意到，我在 Spark 上所做的工作类型发生了很大变化。最初，我大部分时间都花在宣传和开发上。在项目的那个特定阶段，我们总是很高兴引入新的贡献者。但是，在某个时候，工作类型变成了我对补丁和新功能说“不、不、不、不”，因为在某个时候，一个项目必须集中精力，仅仅是因为带宽有限。即使您拥有世界上每一位软件工程师，您仍然无法同时承担整个世界的工作。
此外，贡献者通常不会随意加入项目。通常是因为他们自己或他们的公司需要从项目中获得一些东西。他们通常带着非常强烈的动机来推动他们自己的议程。
有时这可以自然地融入项目的重点，但情况并非总是如此。随着项目委员会变得越来越大，人们倾向于开始推动偏离项目核心重点的事情——即使该重点本身也在不断扩大范围。因此，维护人员需要习惯于基本上拒绝任何可能分散该重点的事情。
否则，一个项目很容易变成一堆杂乱无章的目标的大杂烩。然后，一切都会慢下来，并且越来越难以使项目保持在正轨上。
CM 您如何处理每个人都在推动自己的议程的情况？
RX 这取决于项目的通信架构以及其治理结构。不同的项目对此有不同的处理方式。但是一些项目——包括 Spark 和 Kafka——采用了通过项目改进提案来确定项目方向的想法。这些提案随后由项目的治理机构投票表决。在该级别做出的任何决定都通过邮件列表和网页传达给社区的其余部分。
AG 另一种方法类似于我们在 Pig 项目上所做的事情，我们在早期作为一个社区坐下来，写下我们对 Pig 是什么和不是什么的看法。通过这种方式，我们基本上塑造了 Pig 哲学。然后，每当出现添加这个或那个功能的想法时，我们都能够参考我们作为一个社区商定的这个指导框架，以确定新想法是否合适。
这种方法有所帮助，因为明确项目究竟是关于什么的不仅简化了决策过程，而且还有助于所有参与者理解任何决策背后的理由。
CM 贡献者责任呢？假设您有一个人正在积极处理您项目的关键部分，但最终由于某种原因离开了您。鉴于这些人是志愿者，您能做些什么？
AG 您唯一的防御措施是拥有一个庞大的活跃社区，这样，如果任何一个人离开，都不会最终削弱项目。您只需要假设有些人会来来去去——通常是出于完全正当的理由。
RX 在实践中，在一些较大的项目上工作的工程师中有相当一部分实际上完全由参与组织支付薪酬，无论这些组织是公司还是非营利组织。这些组织通常完全有能力为任何离开的工程师进行替补。但是，一个人在一个项目中的资历越深，就越难取代这个人。
WM 既然我们正在谈论一些挑战，我想指出另一件经常消耗大量精力的事情——那就是问题分类和问题管理。当然，所有项目都跟踪和管理问题，GitHub 和 Jira 都为此提供了流行的解决方案。它们也可以用于许多其他任务。除了报告和跟踪错误之外，它们还倾向于用于跟踪设计讨论以及由此产生的决策。例如，如果一些工程师有他们想要提出的设计文档，他们可能会将其放在问题跟踪器中以进行讨论。
您也可以使用邮件列表来完成大致相同的事情，但是，很多时候，人们都在提出问题甚至提出功能。因此，随着项目变得越来越受欢迎，问题的数量和数量也随之增加——这意味着对于已经存在多年的成功项目来说，在任何时候都有成千上万个问题需要处理并不罕见。事实上，如果一个项目范围很大，并且拥有庞大的开发人员和用户社区，那么它几乎不可避免地最终会有数千个有效问题需要跟踪和管理。
维护人员，仅仅由于他们的角色性质，需要帮助管理所有这些信息，并在报告问题后决定它是否可能是早期报告的重复项，或者可能与已经注意到的其他一些问题相关。真正活跃的维护人员实际上最终充当了他们的问题跟踪器的图书管理员。这样，参与该项目的贡献者就可以开始考虑到一些可能与他们目前关注的问题相关的其他未解决问题，以便更好地协调解决这些问题的工作。也就是说，如果您可以通过一个拉取请求关闭两个问题，那么最好尝试这样做。但是，保持所有这些信息的井井有条，特别是当您谈论超过一千个未解决问题时，这是一个真正的挑战，可能会消耗整体开发工作的大量精力。
CM 作为用户，我非常依赖问题跟踪器中包含的信息，但我的经验是，找到我正在寻找的数据可能是一个真正的挑战。您是否知道解决此问题的方法？我非常确定 Apache 尚未找到它。
AG 如果有解决方案，我不知道。我同意 Apache 肯定还没有找到它。就目前而言，Stack Overflow、Google Search 和 Jira 几乎都将您引导到邮件列表，因此这就是您最终大部分时间都在寻找的地方。
RX 这部分解释了为什么客户希望 Databricks 等供应商支持像 Spark 这样的项目。他们希望知道，如果他们有特定问题，他们可以直接要求支持供应商解决它，而不必自己仔细研究 Jira、Google 和 Stack Overflow。这是我们作为支持供应商必须提供的最大价值之一。
WM 项目负责人还可以做一些其他事情来支持实际的软件开发过程。这与创建执行自动化测试的系统有关，从而使项目能够在贡献数量方面进行扩展。这种价值往往被低估，这就是为什么我认为许多项目往往对测试自动化和相关的支持系统投入不足。结果，随着贡献者数量呈数量级增长，贡献者往往真的很挣扎，因为所有这些核心的开发工具根本无法跟上这种扩展速度。
我认为，当大公司参与开源项目时，这真的让他们感到惊讶，因为他们倾向于将这些类型的能力视为理所当然。他们看到所有这些拉取请求和补丁都进入了项目，然后只是期望它们在短时间内生效。但是他们没有看到的是，围绕该过程的开发人员工具最终落在了极少数核心人员的肩上。
CM 在项目的早期阶段，您是否还有其他希望更关注的事情，以便预测未来潜在的扩展需求？
AG 对于 Apache Hive，我们最终构建了自己的集成测试，因为我们当时认为没有一个很好的开源选项。我们中的许多人都希望我们能在这项工作上投入更多的时间，因为现在测试很难运行。您不能只在一台机器上运行它们；它们太复杂了，除非您有一些可用的基础设施。
因此，我希望我们花更多的时间思考扩展因素，而不是急于尽快完成工作。当时的这个项目规模较小，因此一切都可以相当快地运行。但是没有人坐下来真正思考一旦项目完全实现会是什么样子。我们最终为此付出了代价。
RX 我们的经验有些不同，因为我们决定在项目的早期阶段专注于一些后来证明非常有用的东西。事实上，我们最终将其开源为一个 Spark 的拉取请求查看器。这不仅限于 Spark，因为我们也将其改编用于其他项目。
基本上，它可以让您更好地查看 GitHub 拉取请求。作为其中的一部分，它显示了提交者是谁，最新状态是什么，以及哪些拉取请求长时间处于评论状态。事实证明，这在分类时非常有用。如果 GitHub 可以合并一些类似的东西来提供更好的拉取请求报告，我认为很多人会看到其中的巨大价值。由于这是在 Google App Engine 上构建的，因此它已经发货并且非常容易部署。
WM 这里的一个挑战是，您经常在 GitHub 和开源网站上找到的工具往往针对开发人员数量有限的较小项目进行了优化。这实际上意味着，对于项目扩展 10 倍或 100 倍，它们通常需要更多地依赖于自制工具。像 Apache Spark 这样庞大而活跃的项目发现有必要开发一些自己的工具来支持其流程并帮助其维护人员提高生产力，这并不奇怪。
从某种意义上说，这是一个好问题，但它也可能真的悄悄地影响项目。因此，您会发现一些项目，仅仅运行一个全面的测试套件就可能需要长达五到十小时的 CPU 时间。工具限制也使得难以计划项目将如何在及时的方式中运行所有必要的构建，这最终将损害您在各种可扩展性范围内向贡献者提供反馈的能力。当项目达到那些可扩展性突破点时，它们经常会挣扎。
对于在传统的自上而下的结构化业务环境中工作的程序员来说，开源世界中发现的许多编码挑战和约定应该看起来很熟悉。但是，当涉及到执行这项工作的环境时，存在着更鲜明的对比，因为开源开发人员不是在一个组织内运营，而是作为一个社区的一部分运营——这可能意味着所有社会学维度。
特别是，这意味着采取不同的方法来招募、培养和栽培新的贡献者。是的，它还涉及创建明确的争端解决机制以及行为准则，以解决各种潜在的破坏性人类行为。
CM 您认为开源项目未来面临的最大挑战是什么？
WM 最大的挑战之一肯定与招募新的贡献者并努力让这些人更多地参与进来有关——甚至到培养他们成为维护人员的地步。当然，贡献者并不总是能够成为维护人员，因为通常情况下，您要真正有效地担任该角色，唯一的方法是如果这项工作恰好在很大程度上或全部包含在您的日常工作中。
其中一个结果是，您经常在开源社区中看到那些全职或兼职受雇于项目的人与那些只能不时做出较小贡献的人之间存在分歧。通常，参与社区并为项目做出贡献的体验往往针对那些每天为此工作的人的需求进行了优化。
一位特别多产的开源开发人员 Pieter Hintjens，他已经去世，但曾经非常积极地参与 ZeroMQ 项目以及许多其他开源项目，他建议采取激进的方法，即只要构建通过就继续合并贡献。这是基于这样的假设，即维护人员稍后会跟进以解决需要修复或改进的任何问题——整个动机仅仅是为了减少新贡献者原本会遇到的摩擦量。
RX 我有时使用过这种模式，即使我知道补丁不是很好，我也会接受它，然后我会在之后立即重写它。这不是一种非常可扩展的方法，并且很难推动其他维护人员也这样做。但我个人至少重做了 100 个补丁。
我这样做的部分原因是，这对于新贡献者来说是一次培训练习。我实际上会抄送贡献者并附上一条说明，说：“嘿，这是你如何更深入地研究该补丁的方法，这是关于如何进行操作的稍微好一点的方法。”我的想法是，他们会因为知道他们的补丁被采纳而获得一些动力。然后他们还会了解他们可以如何改进它并成为更好的贡献者。事实证明，这些人中的一些人已经成为项目的核心维护人员。
CM 是否可以做些什么来改善作为项目维护人员的体验？
WM 这就像一句老话，“如果感觉像是一个无法解决的问题，那可能就是无法解决的问题。”我认为这是一个两难境地，因为那些最有能力改善贡献者体验的人往往是那些他们的注意力需要在项目的许多其他领域的人。除此之外，他们通常也是最多产的贡献者之一。还有一种情况是，如果您要求许多最优秀的人员担任维护人员，然后他们成功地让贡献者更容易，您可能会收到两到三倍的贡献。但是，那样的话，您最终也会有两到三倍的代码需要审查。
基本上，如果一个项目被证明是成功的，维护人员几乎不可避免地会负担过重。关于项目的知识和理解，这些知识和理解会影响关于是否接受补丁的合理决策，最终将集中在项目整体贡献者基础的一小部分人手中。这是我们现在面临的核心问题之一：随着项目规模的扩大，您如何保持审查和贡献过程之间某种程度的平衡？
CM 确定项目接下来应该将重点转向何处的最佳机制是什么？
RX 我们有许多不同的方面在推动他们自己的议程。这种张力往往效果很好。但有时您会遇到公地悲剧，因为您有基础设施的这一部分，似乎没有人推动，但事实证明它对整体项目的健康至关重要。在 Databricks，我们有人全职工作基本上只是为了处理基础设施。他们所做的事情实际上有助于上游项目，因为这项工作最终对我们自己的系统产生了重大影响。
CM 就处理公地悲剧而言，也许其中一些工作可以向前支付给其他项目，以改善整个生态系统。
RX 以一种古怪的方式，我们已经用 Spark 做到了这一点。Spark 的构建系统运行良好的原因之一是，在我们早期在（加州大学伯克利分校）AMP 实验室数据中心运营时，我们所有的 Jenkins 产品（用于持续构建和测试产品）实际上都不是在 Apache 基础设施上运行的，而是在 AMP 实验室基础设施上运行的。有一个人的工作是专门维护 AMP 实验室各种项目的重要基础设施。即使现在 Spark 已经从 AMP 实验室的保护伞下迁移到 Apache 的保护伞下，那个人仍在做同样的工作。每当我们有什么东西出现故障时，他都会将其恢复，并且他会为我们进行所有 Linux 升级，以确保我们始终掌握安全漏洞的最新情况。
当然，所有这些对于项目的成功都非常重要，但问题是：他不仅为 Spark 做这件事，还为 AMP 实验室感兴趣的其他四五个项目做这件事。通过这种方式，为改进 Spark 所做的许多工作也使其他项目受益。
CM 然后还有所有那些开源用户。现在正在做些什么来改善他们的体验？
RX 举例来说，Apache Spark 最近的一个更改与数据源 API 有关，您可以使用该 API 指定 Spark 应如何连接到各种数据源。不久之前，我们还采用了一种非常不同的设计，但现在它已被彻底修改，这在很大程度上是用户推动的结果。也就是说，这实际上与 Databricks 的任何付费客户无关，因为他们中的大多数人实际上并不关心这个底层数据源 API。
因此，真正是开源社区不断联系我们，询问：“嘿，你们是如何连接到 Mongo 的？我需要做些什么来为 Spark 编写 MongoDB 连接器？”
开源的魅力在于你可以获得这种多渠道的反馈，我发现这非常有用。但需要注意的一点是，要确保这不会变成“谁的声音大谁就赢”的情况。你需要确保你不仅仅是听到一个人的声音以及他所有朋友的声音，作为推动某个特定方向努力的一部分。实现这一目标的一种方法是识别你的高风险用户，并在提出任何此类更改时主动联系他们以获取他们的反馈。
CM 当人们在这些事情上意见不一致时，你们有什么机制来维护社区的和平？一旦需要仲裁某些争议，你们会怎么做？
WM 嗯，争议肯定会发生。事实上，不久之前，就发生了一起相当引人注目的案例，Scala 社区中的一些开发者实际上设法禁止一位开发者为几个开源项目做出贡献。有些开发者有时被认为是有问题的，这可能是因为他们在项目环境中做过的事情，也可能是因为他们在社区之外做过的事情。在 Richard Stallman 从 GNU 项目以及他在 MIT 的职位上辞职后，GNU 社区肯定经历了一些动荡，原因是他对[已故金融家和被判犯有性侵罪的] Jeffrey Epstein 发表了评论。
我认为不用说，你也会希望避免伴随这类闹剧而来的干扰和分心。拥有一些以有序方式解决争议的方法非常重要。当然，你不想让事情发展到项目最终分叉的地步，因为那是一种真正具有破坏性的行为，势必会产生长期的后果。话虽如此，分叉的可能性始终存在。一旦你走上那条路，它可能会把你带到一个黑暗而危险的地方。简而言之，如果开发者找不到和平解决分歧的方法，社区可能会因此而消亡。
拥有一套行为准则，以及一种强调基于事实和逻辑论证的文明讨论，而不是诉诸情感的文化，这一点非常重要。否则，你经常会看到开发者之间的争端基本上退化为人身攻击和互相谩骂，这永远不会带来积极的结果。
除了为解决争端提供更有效的方式外，行为准则还是在开源软件领域实现更大程度多样性和包容性的一种手段，我很遗憾地说，这个领域仍然由男性主导。当人们看到某些开源社区中存在的有害动态时，他们可能会选择不参与。因此，制定规范行为并创建开发者良好行为期望的结构——除了其他一切之外——还将创造一个更受欢迎的环境。
版权 © 2021 由所有者/作者持有。出版权已许可给 。
最初发表于 Queue vol. 19, no. 5—
在 数字图书馆 中评论本文
更多相关文章
Maya Kaczorowski, Falcon Momot, George V. Neville-Neil, Chris McCubbin - OSS 供应链安全：需要什么？
虽然企业安全团队自然倾向于主要关注对其自身基础设施的直接攻击，但网络犯罪的攻击目标现在越来越多地转向更易受攻击的上游目标。这导致了一场完美的风暴，因为目前几乎所有重要的代码库存储库都至少包含一些开源软件。但是，恶意软件的作者在那里也发现了大量机会。与此同时，更广泛的网络犯罪世界已经注意到，开源供应链通常很容易渗透。目前正在采取哪些措施来应对明显的风险？
© 保留所有权利。