ACM通信
实践
它需要一个社区:开源挑战
信贷:MarcoVector
在开源开发人员面临的许多挑战中，最令人生畏的是其他程序员几乎没有想到的一些挑战。这是因为大多数程序员工作的环境中，“其他人”会处理这些事务——例如，在法律部门或人力资源部门工作的人。但如果没有这样的人可以求助，那怎么办?
构建一个成功的开源社区依赖于许多不同的因素，其中一些对任何开发人员来说都是熟悉的——清晰而现有的市场机会、智能的方法、高效的编码等等。同样重要的是招聘、激励、指导、管理和调解争议的技能——所有这些都无需使用各种形式的补偿来奖励和激励贡献者。
到底要怎样才能做到这一切?我们将让那些拥有一些最成功的开源项目领导者的记录的人，从他们自己的经验中来解决这个问题。参与下面的讨论雷诺鑫他是Databricks的首席架构师，以开发Apache Spark而闻名;艾伦•盖茨Hortonworks的联合创始人，曾在雅虎实验室帮助开发Hadoop、Pig、HCatalog和Hive;和韦斯麦金尼,Ursa Labs的创始人，负责创建熊猫(Python数据分析库)，目前负责领导Apache Arrow项目。
克里斯•McCubbin亚马逊网络服务(Amazon Web Services)的高级应用科学家，帮助引导讨论。
CHRIS MCCUBBIN:Linux在1992年以开放源码的形式发布。随后，在整个互联网时代出现了第二波开源产品。现在启动一个开源项目是什么感觉?
雷诺心:一个很大的不同是，整个基础概念扎根了。在早期，Linux基本上只是一个业余爱好项目，从这方面来说，它与20世纪90年代开始的许多其他开源项目类似。现在你有了Linux基金会，它每年有数百万美元的运营预算。虽然由志愿者运营的Apache软件基金会没有这样的运营预算，但它已经成功地为自己创造了一个重要的品牌。
很多开源项目，尤其是从20世纪90年代末到2010年，都是以基金会的形式开始的，其中一个原因是他们可以更好地与围绕这些项目成长起来的社区打交道。在过去的几年中，这一趋势有所逆转。很大程度上要感谢GitHub的崛起，现在越来越多的开源项目只需在那里放置一个库就可以启动。许多以这种方式起步的项目，在没有任何基金会帮助的情况下，都取得了相当大的成功。我绝对认为这是当前最重要的趋势之一。
MCCUBBIN:当然，这个领域最近变得更加拥挤了。也就是说，对于每一个问题，现在似乎至少有几个项目提供了潜在的解决方案。但是有时候很难弄清楚哪些正在被积极维护。
心:完全正确。但是，即使与基金会有联系，也不一定意味着一个项目会得到积极的维护。项目社区可以来来去去。事实上，许多开源项目——尤其是较小的项目——只依赖于一两个关键贡献者。一旦这些贡献者继续工作，代码后面就没有什么东西了。此外，即使是有成功基础支持的中型项目，您也不能完全相信代码会得到很好的维护。
艾伦·盖茨:从另一个角度来说，我想说，在过去的20年里，我们也见证了越来越多的企业存在。甚至在15年前，当Hadoop刚刚推出的时候，就有一些公司会支持某些项目，并提供各种类型的支持。那时，很多人已经在使用Linux了。
公司也开始让人们知道他们在支持什么项目，这样他们就可以把它作为自己身份的一部分来推广。红帽是第一批在这方面真正成功的公司之一。然后，其他一些人也开始支持Linux。在这一点上，企业对开源项目的参与已经远远超出了这一范围——从他们如何使用开源和如何组织他们的开发工作两方面来说都是如此。
心:引用一位不愿透露姓名的朋友的话，在某种程度上，开源已经赢了。
MCCUBBIN:我肯定是这样认为的。我自己的经验是，在2012年我帮助成立的一家初创公司中，我们基本上完全采用了开源框架。这代表了一个巨大的转变，从我以前所做的一切，几乎都是自己做的。
你还能看到这种趋势吗?或者，由于可维护性问题和类似的事情，现在在开源方面有更多的阻力吗?
盖茨:现在有一些阻力。一些公司开始说，“我们真的想参与开源，但现在正确的方式是什么?”你会看到不同的公司尝试着不同的授权模式，所以他们肯定想要继续参与其中。正如Reynold所说，开源已经赢了。但问题是，什么是正确的参与形式?
韦斯·麦金尼:总的趋势是公司越来越希望他们依赖的核心平台是完全开源的。但是，在npm/JavaScript生态系统这样的地方，这些项目没有受到基金会的监督，或者可能没有得到大型、集中的开发团队的好处，这些年来也出现了一些令人不安的安全相关问题。越来越多的公司开始意识到，虽然他们希望所有的核心平台软件都是开源的，但他们也愿意为高级企业特性的开发买单，同时也愿意为支持和补偿——或者，至少是优先级为1和优先级为2的bug修复买单。
辛磊:开源并不一定是免费软件。相反，它更多地与公司在建立生态系统和社区方面的内在利益有关，这些生态系统和社区将帮助他们降低雇佣新员工的成本，然后增加他们的数量。
即使回到2010年以前，人们对专有产品和厂商锁定的排斥仍在继续，然而人们花了一段时间才意识到使用维护良好、支持良好的开源软件是多么重要。事实上，在那个时期作为Apache Hadoop生态系统的一部分出现的供应商——尤其是像Cloudera和Hortonworks这样的公司——是专门为提供安心和安全水平，以及为非常大的公司、金融机构和保险公司提供所需的支持而创建的，这些公司有足够的信心把他们的业务放在开源软件上。
所以，我认为现在的情况是，公司仍然在为软件付费，但方式与以前不同。过去他们为软件许可证付费，但现在他们为防止故障和潜在损失而付费。也就是说，赔偿已经成为一个更大的问题，因为组织已经开始在这条线上投入数十亿美元。然而，我们仍然有像Equifax黑客这样的问题，这是由于该组织未能应用开源生态系统中现成的安全补丁造成的。这现在已经成为一个经典的例子，说明每当用户不能正确地维护他们的开源软件时，会发生什么。
MCCUBBIN:这就是商业软件提供有趣对比的地方。例如，微软(Microsoft)等供应商就有强迫用户进行更新。你认为开源世界应该向这个方向发展吗?
盖茨:在许多开源生态系统中，实际情况是，提供基于开源软件的商业产品的供应商往往会提供我们通常所说的东西下游的构建，本质上是将开源版本与任何适用的bug修复或安全补丁结合在一起。
这在某种程度上减轻了开源项目本身承担全部支持的负担。如果在一款开源软件中发现了安全漏洞，与该项目相关的供应商有关系的客户很可能会向该供应商寻求补丁版本的软件，主要是因为他们知道这样可能会更快地得到补丁软件。事实上，这就是许多组织首先与这些供应商签订合同的原因。
心:开源并不一定是指自由软件。相反，它更多地与公司在建立生态系统和社区方面的内在利益有关，这些生态系统和社区将帮助他们降低雇佣新员工的成本，然后增加他们的数量。也就是说，如果您的开发环境是基于一些非常流行的开源技术，那么找到符合您需求的人就不是那么困难。
麦金尼:这让我想起了大约10年前我第一次接触开源软件，当时我在一家名为AQR资本管理公司(AQR Capital Management)的公司工作，基本上是一家量化投资管理公司。在解释为什么我们应该将我一直在做的一个库开源时，我也提出了同样的观点——理由是世界上的人们会开始熟练地使用这个软件，这反过来会为我们创造一个可供雇佣的人才池。顺便说一下，我在这里谈论的软件最终成为了熊猫项目的基础。
那时，在2009年，我的观点是一种延伸的想象，但现在这几乎已经成为常态。将内部开发的软件作为开源开放，这样就可以吸引用户社区，这种模式已经被证明对那些首先产生这些新软件功能的公司是有益的。当然，许多大公司已经开始着手开发开源项目，希望能吸引大量用户——其中一些用户以后可能会被他们招募进来。
盖茨:假设您有一个很好的项目，它实际上解决了一个常见的问题，我绝对认为这是让人们使用您的软件的一个很好的方法。
麦金尼:另一个问题与项目管理有关，这是人们在现代这个草根项目开始于GitHub的时代很少考虑的事情。也就是说，治理现在常常只是事后才想到的，原因很简单，许多项目只有一两个核心开发人员或维护人员来做所有的决策。
但随着项目的发展，你会发现有几十人甚至数百人可以对你的项目存储库进行写访问，决策过程和决定谁来决定一个补丁或一个拉请求是否应该合并开始变得更加重要。而且，特别是当一个项目涉及到许多商业利益时，这可能会变得更具政治色彩。事实上，您有时会遇到直接竞争对手对每个人都认为重要的项目做出贡献的情况，这通常会导致关于合并谁的工作以及是否已经准备好合并某些工作的斗争。
当涉及到一些较大的项目时，我认为围绕治理问题的冲突最终耗尽了这些项目委员会的大量精力。因此，我经常鼓励开源开发人员提前计划他们打算如何处理治理问题，同时也考虑一旦他们扩展到更大的开发人员社区，他们将做什么。20个或100个核心开发者所面临的问题与只有两个核心开发者所面临的问题是完全不同的。
讨论你将使用何种机制来做决定是很重要的，无论是共识还是终身任命某个仁慈的独裁者，或者其他什么，因为你想避免如果你等到手头已经有了冲突才开始解决问题时必然会出现的挫败感。
在开始编写任何实际代码之前，还有很多事情需要处理。除了清楚地定义治理结构和解决争议的机制外，还需要为未来的工作确定适当的工具和测试。
但是，当然，并不是所有项目的需求都可以预先预料到，一定数量的适应性总是需要的。随着项目的发展，个性会改变，优先级也会变化。没有什么比社区规模的持续增长更能考验早期所做的假设和准备了。角色变化，许多附加特性被提出，越来越多的问题积累需要管理和跟踪。项目的规模与这些需求保持一致的能力不仅对项目的成功至关重要，而且对项目的生存也至关重要。
MCCUBBIN:你会如何描述一个项目维护者生活中的一天?
麦金尼:这要看是哪一天。在某些情况下，这感觉就像消防员生活中的一天。但是，特别是对于那些包含许多贡献者的项目，我想说的是，日常的关注主要是确保贡献者在测试和持续集成方面的工作得到及时的反馈。
持续的集成工作需要及时地进行，以确保某些内容实际上已经准备好合并到项目中，否则您将以积压工作结束。这可能会导致沮丧的贡献者退出项目，如果他们觉得他们没有及时得到反馈，或者没有看到他们的工作在合理的时间框架内被合并。在最糟糕的情况下，一旦人们开始觉得他们不能对项目做出有意义的贡献，这甚至会导致分叉。
盖茨:另一方面，我想说，没有人仅仅是作为维护者来参加开源项目的。我鼓励维护者试着找到一些平衡。正如Wes所说，你肯定需要花一些时间与贡献者接触，并尝试及时地合并他们的代码。
但你也需要完成自己的工作，如果贡献者开始认为这是原因，他们可能会感到沮丧他们的东西进入的速度并不像其他方式那样快。不过，另一种看待这个问题的方式是，它可能标志着让一些贡献者进入提交者角色的时机已经到来，这样工作就可以分散一些。
心:这些年我注意到，我在Spark上的工作类型发生了很大变化。最初，我花了很多时间在传福音和发展上。在项目的那个特殊阶段，我们总是很高兴能够引进新的贡献者。但是到了某个时候，我的工作就变了对补丁和新功能说:“不，不，不，不”因为在这个过程中，某个项目只是有仅仅因为带宽有限，它就能更专注。即使你拥有世界上每一个软件工程师，你仍然不能同时承担整个世界的任务。
此外，贡献者通常不是随机来到一个项目中。这通常是因为他们需要项目之外的东西来满足自己或公司的需要。他们通常会有非常强烈的动机来推动自己的议程。
有时候这能够很自然地与项目的重点相吻合，但情况并非总是如此。随着项目委员会的规模越来越大，人们倾向于开始推动偏离项目核心焦点的事情——即使该焦点本身的范围在不断扩大。因此，维护人员需要对任何可能会偏离重点的事情说“不”。
否则，项目就很容易变成一个混杂目标的大杂烩。然后，所有的事情都会慢下来，并且让项目继续下去会变得越来越困难。
MCCUBBIN:你如何处理每个人都在推进自己的议程的情况?
心:这取决于项目的通信体系结构，以及它的治理结构。不同的项目在这方面的做法不同。但是一些项目——包括Spark和kafka——采用了通过项目改进建议来确定项目方向的想法。这些建议然后由项目的治理机构投票表决。在该级别做出的任何决定都会通过邮件列表和Web页面传达给社区的其他成员。
盖茨:另一种方法是沿着我们在Pig项目中所做的路线，我们作为一个社区早早地坐下来，写下我们对Pig是什么和不是什么的看法。通过这种方式，我们基本上塑造了猪哲学。然后，每当有添加这个或那个功能的想法出现时，我们就可以参考我们作为一个社区所同意的指导框架来决定这个新想法是否合适。
这种方法很有帮助，因为明确项目的内容不仅可以简化决策过程，还可以帮助每个参与的人理解所做决策背后的原因。
MCCUBBIN:贡献者责任呢?假设你有一个积极参与项目关键部分的人，但最终因为各种原因离开了你。考虑到他们是志愿者，你能做什么?
盖茨:你唯一的防御就是拥有一个活跃的大型社区，这样即使有人离开，也不会破坏项目。你只需要假设一些人会因为完全合理的原因来来回回。
心:实际上，在一些较大的项目中，有相当一部分工程师实际上是由参与项目的组织全额支付报酬的，无论这些组织是公司还是非营利组织。这些组织通常很有能力填补任何离开的工程师。但是一个人在一个项目上的任期越长，就越难找到合适的人选。
麦金尼:既然我们谈到了一些挑战，我想指出一些经常消耗大量精力的事情——与问题分类和问题管理有关。所有的项目都跟踪和管理问题，当然，GitHub和Jira都提供了流行的解决方案。它们还可以用于许多其他任务。除了报告和跟踪bug之外，它们还被用于跟踪设计讨论和由此产生的决策。例如，如果一些工程师想要提出一份设计文档，他们可能会把它放在问题跟踪器中，以便进行讨论。
您也可以使用邮件列表来完成相同的事情，但是，很多时候，人们会提出问题，甚至提出功能。因此，当一个项目变得越来越受欢迎时，问题的数量和数量也随之增长——这意味着已经存在多年的成功项目在任何时候都有数万个问题需要处理，这是很正常的。事实上，如果一个项目的范围很大，开发人员和用户社区也很大，那么它几乎不可避免地会产生成千上万个需要跟踪和管理的有效问题。
维护人员，根据其角色的性质，需要帮助管理所有这些信息，并决定一旦报告了一个问题，它是否可能是先前报告的重复，或者可能与已经注意到的其他问题有关。真正积极的维护者最终有效地充当了问题追踪器的图书管理员。这样，从事项目工作的贡献者就可以开始考虑一些其他可能与他们此刻碰巧关心的问题有关的开放问题，这样，解决这些问题的工作可能会得到更好的协调。也就是说，如果您可以用一个拉请求来解决两个问题，那么尝试这样做可能是一个好主意。但是，保持所有这些信息的组织，特别是当您讨论超过1000个开放问题时，这是一个真正的挑战，可能会从整体开发工作中消耗大量的精力。
MCCUBBIN:作为一名用户，我严重依赖问题跟踪器中包含的信息，但我的经验是，这可能是一个真正的挑战找到我要找的数据你知道有什么解决办法吗?我很确定阿帕奇还没找到它。
盖茨:就算有解决办法，我也不知道。我同意Apache肯定没有找到它。就目前的情况而言，Stack Overflow、谷歌Search和Jira几乎会把您带到邮件列表，所以在大多数情况下，您最终会在那里查找。
心:这在一定程度上解释了为什么客户希望像Databricks这样的供应商支持Spark这样的项目。他们想知道，如果他们有一个特定的问题，他们可以要求支持供应商解决它，而不是必须仔细研究Jira、谷歌和Stack Overflow本身。这是我们作为一个支持供应商必须提供的最大价值之一。
麦金尼:项目负责人还可以做一些其他的事情来实现实际的软件开发过程。这与创建执行自动化测试的系统有关，从而使项目能够按照贡献的数量进行扩展。它的价值经常被低估，这就是为什么我相信许多项目倾向于在测试自动化和相关支持系统方面投资不足的原因。因此，当贡献者的数量按数量级增长时，贡献者通常会感到很困难，因为处于核心位置的开发工具根本无法跟上这种扩展。
我认为，这真的会让那些参与开源项目的大公司感到惊讶，因为他们倾向于把这些功能当作是给定的。他们看到所有这些拉请求和补丁进入项目，然后只是希望它们在短时间内生效。但他们没有看到的是，围绕这个过程的开发人员最终落在了核心的一小部分人的肩上。
MCCUBBIN:在项目的早期阶段，是否有什么事情是你希望自己能够更加关注的?
盖茨:对于Apache Hive，我们最终构建了自己的集成测试，因为我们当时认为没有一个很好的开源选择。我们中的许多人希望我们在这方面投入更多的时间，因为测试现在很难运行。你不能只在一台机器上运行它们;它们太复杂，除非您有一些可用的基础设施，否则无法使用。
所以，我希望我们能花更多的时间来考虑比例因子而不是急于尽快解决问题。当时的项目规模较小，所以运行速度相当快。但没有人坐下来认真思考这个项目完全实现后会是什么样子。我们后来付了钱。
心:我们有一些不同的经验，因为我们决定在项目的早期专注于一些后来证明非常有用的东西。事实上，我们最终将其开源为Spark的拉式请求查看器。这也不仅仅局限于Spark，因为我们也将其应用于其他项目。
基本上，它给你一个更好的GitHub拉请求视图。作为其中的一部分，它显示了提交者是谁，最新的状态是什么，以及哪些拉请求已经发表了很长时间的评论。这在分诊时被证明是非常有用的。如果GitHub能够提供更好的拉请求报告，我想很多人会看到它的巨大价值。因为它是在谷歌App Engine上构建的，所以它已经发布了，而且非常容易部署。
麦金尼:这里的一个挑战是，你经常在GitHub和开源网站上找到的工具通常都是针对开发人员数量有限的小型项目进行优化的。这实际上意味着，对于扩展10倍或100倍的项目，它们通常需要更多地依赖于自己开发的工具。像Apache Spark这样大型且活跃的项目发现有必要开发一些自己的工具来支持其进程并帮助其维护者提高效率，这一点都不奇怪。
WES MCKINNEY:随着一个项目越来越受欢迎，问题的数量和数量也随之增长——这意味着对于一个成功的项目来说，在任何时候都有数万个问题需要处理是很正常的。
从某种意义上说，这是一个很好的问题，但它也可能真正影响到项目。因此，您会发现，在一些项目中，仅仅运行一个全面的测试套件就可能花费多达5到10个小时的CPU时间。工具的限制也使计划项目如何及时地运行所有必要的构建变得困难，这最终将损害您在各种可伸缩性范围内向贡献者交付反馈的能力。项目在达到可伸缩性临界点时通常会遇到困难。
对于在传统的、自顶向下的结构化业务环境中工作的程序员来说，在开源世界中发现的许多编码挑战和惯例应该是熟悉的。但是，当涉及到执行这项工作的环境时，就有了一个鲜明的对比，因为开源开发人员不是在一个组织内运作，而是作为社区的一部分——这可能意味着所有的社会学维度。
特别是，这意味着采取不同的方法来招聘、培养和培养新的贡献者。是的，它还包括创建明确的争端解决机制，以及处理一系列潜在的破坏性人类行为的行为准则。
ALAN GATES:许多开源生态系统的现实情况是，提供基于开源软件的商业产品的供应商倾向于提供通常被称为下游构建的产品，这些产品本质上是将开源版本与任何适用的bug修复或安全补丁结合在一起。
MCCUBBIN:你认为开源项目未来面临的最大挑战是什么?
麦金尼:最大的挑战之一肯定是招募新的贡献者，并努力让这些人越来越多地参与进来——甚至到培养他们成为维护者的地步。当然，贡献者并不是总能成为维护者，因为通常情况下，您真正有效地担任该角色的唯一方法是，如果这项工作恰好是您日常工作的一部分或全部的话。
其中的一个后果是，您经常会在开源社区中看到一种分化，即那些全职或兼职为项目工作的人，和那些只能偶尔做出较小贡献的人。通常，参与社区并为项目做出贡献的体验往往会根据每天从事这项工作的人的需求进行优化。
一个特别高产的开源开发人员Pieter Hintjens(他已经去世了，但曾经非常参与ZeroMQ项目和其他一些开源项目)推荐了一种激进的方法:只要构建通过，就继续前进，合并贡献。这是基于这样的假设，即维护者会在之后跟进解决任何需要修复或改进的问题——整个动机只是为了减少新贡献者可能遇到的摩擦。
心:我曾经使用过这种模式，即我接受一个补丁，即使我知道它不是很好，然后我将立即重写它。这不是一种可扩展的方法，而且很难推动其他维护者做同样的事情。但我个人已经用这种方法重做了至少100个补丁。
我的部分理由是，这是对新贡献者的培训。实际上，我会复制贡献者的笔记，说:“嘿，这是你可以深入研究补丁的方法，这是一个更好的方法。”我的想法是，如果他们知道他们的补丁被加入，他们会有一些动力。然后他们还会学习如何改进，成为更好的贡献者。事实证明，其中一些人已经成为项目的核心维护者。
MCCUBBIN:有没有什么特别的方法可以改善作为项目维护者的体验?
麦金尼:就像一句老话说的:“如果你觉得这是一个无法解决的问题，那么它可能就是一个无法解决的问题。”我认为这是一种进退两难的局面，因为那些最有能力改善贡献者体验的人往往是那些需要关注项目其他许多领域的人。除此之外，他们本身也是最多产的贡献者之一。另外，如果您让许多最优秀的人员担任维护者，并且他们成功地使贡献者的工作变得更容易，那么您可能会收到两到三倍的贡献者。但是，您也会以两到三倍的代码来检查结束。
基本上，如果一个项目被证明是成功的，维护人员几乎不可避免地会负担过重。关于项目的许多知识和理解，这些因素将决定是否接受补丁，最终将集中在项目总体贡献者基础的一小部分。这是我们现在面临的核心问题之一:作为一个项目规模，您如何在评审和贡献过程之间保持某种平衡?
MCCUBBIN:什么是决定项目下一步应该将焦点转向何处的最佳机制?
心:我们有许多不同的政党都在推动他们自己的议程。这种紧张往往会产生很好的效果。然而，有时会出现公地悲剧，因为这部分基础设施似乎没有人在推动，但它对整个项目的健康发展很重要。在Databricks，我们有一些人的全职工作基本上就是做基础设施。他们所做的实际上对上游项目有贡献，因为这些工作最终会对我们自己的系统产生重大影响。
MCCUBBIN:在处理公地悲剧方面，也许其中一些工作可以用于其他项目，以改善整体生态系统。
心:我们用Spark以一种奇特的方式做到了这一点。Spark的构建系统运行良好的原因之一是，早在我们用完(加州大学伯克利分校)AMPLab数据中心的早期，我们所有的Jenkins产品(用于持续构建和测试产品)实际上并没有运行在Apache基础设施上，而是运行在AMPLab基础设施上。有一个人的工作是为AMPLab的各种项目维护重要的基础设施。即使现在Spark已经从AMPLab的保护伞转移到了Apache的保护伞上，这个家伙仍然在做同样的工作。任何时候我们出了什么问题，他都会恢复，他会为我们升级所有的Linux系统以确保我们不受安全漏洞的影响。
当然，这对项目的成功非常重要，但问题是:他这样做不仅仅是为了Spark，也为了其他四五个AMPLab感兴趣的项目。通过这种方式，为改进Spark所做的许多工作也使其他项目受益。
MCCUBBIN:还有那些开源用户。现在做了什么来改善他们的体验?
心:举个例子，Apache Spark最近的一个更改与数据源API有关，您可以使用它来指定Spark应该如何连接各种数据源。不久前我们的设计还很不一样，但现在已经完全改版了，很大程度上是受用户的推动。也就是说，这与Databricks的任何付费客户都没有任何关系，因为他们中的大多数人实际上并不关心这个底层的数据源API。
所以，这是真正的开源社区，会ping我们问，“嘿，你如何连接到蒙戈?我需要做什么来为Spark编写MongoDB连接器?”
开源的美妙之处在于你可以得到这种多渠道的反馈，我觉得这非常有用。不过，有一件事需要注意，那就是确保这不会变成声音最大的事情。你需要确保你听到的不是一个人和他所有的朋友的声音，这是推动一个特别方向的努力的一部分。实现这一目标的一种方法是识别高风险用户，并在提出任何此类更改时主动联系他们，以获得他们的反馈。
MCCUBBIN:每当人们在这类事情上意见不一致时，你用什么机制来维持社区的和平?一旦有必要对争议进行裁决，你会怎么做?
麦金尼:嗯，争端当然会发生。事实上，就在不久前，Scala社区的一些开发人员有效地阻止了一名开发人员为几个开源项目做出贡献。有些开发人员有时会被认为是有问题的，不管这是因为他们在项目环境中做了什么，还是因为他们在社区之外做了什么。在Richard Stallman从项目中辞职之后，GNU社区当然经历了一些动荡，他在麻省理工学院的职位也因为他对(已故金融家和被定罪的性犯罪者)Jeffrey Epstein的评论而辞职。
我认为这是不言而喻的，你宁愿避免中断和分心伴随这类戏剧。有一些方法以有序的方式解决争端是很重要的。当然，你不希望事情发展到项目最终分叉的地步，因为这是一个具有破坏性的行动，必然会产生长期的后果。也就是说，分叉的可能性始终存在。一旦你走上那条路，就会陷入黑暗和危险的境地。简单地说，如果开发者不能找到一种方式和平地解决他们的分歧，社区可能会因此而死亡。
真正重要的是要有一套行为准则，以及一种强调基于事实和基于逻辑的论点而不是诉诸情感的公民讨论的文化。否则，你经常会看到开发者之间的争执演变成人身攻击和谩骂，这永远不会带来积极的结果。
除了为解决争议提供更有效的方法外，行为准则也是在开源软件领域实现更大的多样性和包容性的一种手段，我很遗憾地说，这个领域仍然由男性主导。当人们看到一些开源社区中的有害动态时，他们可能会选择不参与。因此，建立规范行为的结构，并对开发商的良好行为产生期望——除此之外，还会创造一个更受欢迎的环境。
数字图书馆是由计算机协会出版的。版权所有©2022 ACM股份有限公司
没有发现记录