作者：舟舟 tovarishch.eth @c_hongzhou, 0xWeiCai @0xWeiCai
**作者按：**本文 A Comparative Analysis of Centralized and Decentralized Developer Autonomous Organizations Managing Conflicts in Discussing External Crises （https://doi.org/10.1109/TCSS.2023.3247464）成文于2022年5月，于2023年5月发表于IEEE Transactions on Computational Social Systems （该期刊于2014年由IEEE SMC Society和IEEE Computer Society共同创刊，上一任主编为王飞跃教授，现任主编为胡斌教授。该期刊内容涵盖社会计算、社会系统建模与仿真、社会网络动力学、社会智能与认知、社会系统设计与架构、社会文化建模与表现、计算行为建模及其应用等。目前该期刊为SCI Q1，IF 4.747）。
本文成文得到SeeDAO大力支持和SeeDAO Insight & Research公会研究者们的鼓励和启发。此外，本文要感谢Zikai Alex Wen博士的悉心支持和指导。
不可否认，在过去一年中，随着Web3和DAO的发展，本文一些观点需要加以修正。但在去全球化和地缘政治冲突加剧的当下，去中心化治理模式消弭矛盾的能力，会越发具有研究意义。
理解在线开发者社区如何解决讨论中产生的冲突至关重要。但很少有研究关注由外部危机，如地缘政治冲突（本文中指2022年俄乌危机）引起的冲突。我们对比研究了一个去中心化自治组织（DAO）Aave项目社区，和一个中心化自治组织（CAO）GitHub项目社区，如何管理由外部危机引起的社区冲突。我们的混合方法分析表明，DAO可能比CAO更好地缓解冲突。并且区块链技术（投票和加密货币）发挥了重要的作用。为了解决投票参与率低的问题，我们建议增加一定代币激励，以吸引更多的DAO成员参与到共同目标的形成中。
关键词：区块链、冲突管理、群际接触理论、DAO、在线开发者社区
开发者们自发地组成在线社区，与其他开发者和用户共同创建并交流软件创新成果[1]。关于整个社区应如何进行讨论是协作的重要部分[2]。之前的研究表明，讨论可能反映个体的利益[3]，促进社区发展，激励创新[4]。然而，讨论也可能引发社区冲突。如果人们不能管理讨论中的冲突，这些冲突可能导致合作破裂[5]。因此，理解在线开发者社区是否以及如何解决讨论中的冲突至关重要。开发者社区中存在四种冲突[6]：1)任务冲突；2)情感冲突；3)流程冲突；以及4)规范冲突。之前的研究主要关注内部问题引发的冲突，忽略了由外部因素引发的冲突[7]。2022年的俄乌危机使人们分裂成不同的群体[8]。这场危机也影响到在线开发者社区。社区成员呼吁限制“敌方”，向特定政府捐款等等[9]。激烈的讨论和提案在许多在线开发者社区引发了冲突[10]。
在研究在线开发者社区如何讨论危机和管理冲突的过程中，我们关注到了一种新型社区：去中心化自治组织（DAO）。Aave项目是一个典型的DAO，其任务是开发和运营一个Web3贷款系统。Aave项目社区使开发者和用户能够共同参与项目的发展，并通过基于区块链的投票来决定如何治理Aave。相比之下，GitHub项目是世界最大开源开发者自治组织GitHub[11]的基础。其任务是开发和运营一个平台系统，允许众多开发者部署他们的软件项目。GitHub项目社区使全球开发者作为用户能够使用GitHub的软件服务，提供反馈，并对项目开发做出贡献。GitHub项目有自己的员工来治理社区。因此，它可以被描述为中心化自治组织（CAO）。危机爆发后，Aave和GitHub的成员在社区中自发地呼吁行动。我们好奇的研究问题是：RQ1 DAO（即Aave）和CAO（即GitHub）在危机讨论中是否以及如何解决了冲突。我们把这个问题分解成两个子问题：RQ1.1 DAO和CAO做了什么来解决冲突？RQ1.2 冲突是如何被DAO和CAO解决的？
为了回答这些子问题，我们分析了从Aave的治理平台和GitHub的讨论论坛收集的讨论和提案数据。这些数据涵盖了2021年10月到2022年3月的时间段。通过绘制Aave和GitHub的帖子及时间戳的共现网络，我们发现两个社区在2月份都立即就危机进行了讨论，然后在3月份冷却下来。我们观察了用户的活动，发现GitHub的工作人员发表了官方回应危机相关讨论并关闭了所有这些主题。同时，Aave否决了一个支持乌克兰政府财政的提案。结果公布后，讨论冷却下来。然而，情感分析揭示，GitHub中原始的冲突转化为了情感冲突。这些结果表明，简单的禁止讨论并没有完全解决冲突，而是转化了原来的冲突。换句话说，DAO可以比CAO更好地缓解外部因素引发的冲突，这导致我们研究第二个问题：RQ2 为什么在缓解危机相关讨论引发的冲突方面，DAO比CAO更好？
为了回答RQ2，我们将群体接触理论（Contact hypothesis）[12]应用于我们的上下文。该理论定义了四种人群之间的互动条件（即，平等地位，共同目标，群体间合作，和中立权威的支持），这四个条件应当得以满足以减少冲突。我们的研究发现，DAO（即，Aave）比CAO（即，GitHub）更容易满足这四个条件。在上述分析中，基于区块链的投票和加密货币发挥了重要的作用。因此，我们想要回答最后的研究问题：**RQ3 区块链技术如何让DAO比CAO更好地管理冲突？**我们找到了两条证据来回答这个问题。首先，Aave的加密货币比GitHub的成就系统更能激励开发者达成理性的冲突解决方法。其次，Aave允许开发者在区块链上匿名交互，但GitHub做不到，这在危机讨论中导致了许多人身攻击。
尽管DAO在解决冲突方面表现出了巨大的潜力，但我们发现，Aave基于区块链的投票的投票率很低。投票率从未超过6.23%。因此，我们提议通过增加货币激励来改进当前机制，鼓励人们参与投票。任何投票的人都将收到小额的代币，而胜出的人群将获得另一小部分。在未来，我们将与一个DAO合作，并进行一个实验，检验这种基于货币激励的改进可以提高多少投票率。
我们的贡献涉及社区创新治理：1)我们对DAO和CAO在管理外部危机引发的冲突方面进行了比较研究；2)我们的混合方法分析显示，DAO在缓解冲突方面表现得更好，区块链技术发挥了关键作用；3)我们提议增加货币激励，以便更多的成员可以参与形成共同的目标。
在线开发者社区是关注自由和开源软件的自治组织，开发者在这里动态地与其他人进行合作[13]。此外，获取用户互动和反馈是在线开发者社区进行软件开发的另一个关键角色[14]，[15]。在这些社区中，讨论他们的不同观点和在开发者与用户之间建立共识对合作至关重要。有时这些讨论可能会非常激烈，如Schneider等人[16]发现成员们可能会就Linux的开发进行长达一年的激烈讨论。
在在线开发者社区的讨论中会出现四种类型的冲突[17]：1) 任务冲突涉及对需要完成的任务的不同意见，比如GitHub的Pull requests变更[18]；2) 情感冲突涉及团队情感或关系的不和，比如对求助评论的不友好回复[19]；3) 流程冲突涉及对工作完成方式的不同意见，比如在开源社区创建PNG格式过程中的冲突[20]；4) 规范冲突涉及社区政策或意识形态与实际行为之间的矛盾，比如在Gnu's Not Unix（GNU）社区使用非免费开源软件所引发的冲突[21]。此外，如果不及时解决，任务冲突最有可能转变为其他类型的冲突，从而放大负面影响[7]，[22]。
鉴于社区管理者的重要角色，他们可以通过执行不同的任务来解决冲突[23]。此外，冲突也可能通过管理者理性分配资源[24]，设定支持性规则[25]，以及积极回应请求[26]来解决。然而，大多数研究关注的是由内部问题引发的冲突，而很少关注由突然和巨大的外部影响（如2022年俄乌危机）引发的冲突。
Web 3强调大规模使用区块链，如智能合约和加密货币[27]。早期的互联网，大多数用户只能阅读内容，被称为Web 1[28]。然后，允许用户创建和分享内容的互联网被称为Web 2。虽然Web 2的用户可以创建，但是平台公司集中拥有信息[29]。
DAO是Web 3的代表性社会-技术应用[30]。Buterin等人[31]将DAO描述为一个用区块链上的智能合约来管理人类行为的组织。像以太坊这样的开源区块链平台使人们能够在智能合约中编写规则，从而实现分布式的、自动化的、自治的治理，无需第三方干预[32]。一旦DAO的治理规则被写入智能合约，除非投票，否则无法更改[31]。成员的投票权力是基于他们持有的与相应智能合约相关的加密货币（代币）的数量[33]。
社群接触理论[12]试图减少二战后广泛出现的种族和文化冲突。这个理论提供了四个实现积极接触的条件：平等的地位，参与者必须有平等的地位。共同的目标，他们必须在一个共同的问题上工作并分享一个共同的目标。社群间的合作，在实现他们的目标时，处于合作而非竞争的状态。最后，中立权威的支持，接触必须得到如道德、法律或社会习俗的支持，且这种支持必须是中立的。接触理论已经应用于社区实践并证明了有效性，例如在跨文化背景的教育中建立合作[34]，以及消除跨党派在线讨论中的冲突[35]。
GitHub和Aave项目的社区将其开发者和用户连接起来，以开发、获取服务和提供反馈。他们的主要区别在于中心化或去中心化的治理结构。GitHub（CAO）有员工进行管理，可以调整任何内容。相反，Aave（DAO）由基于区块链的投票进行治理。
它是GitHub组织的基础系统。GitHub项目帮助超过8000万的开发者在GitHub上部署他们的软件。数百万的开发者为GitHub项目的开发贡献了4357个代码库，超过100万的问题和65万的Pull请求。项目社区由GitHub员工进行管理，他们有权限修改系统中的任何内容，如调整访问权限，锁定讨论，以及删除任何用户生成的内容。由于先前的机制（如"Issue"和"Pull"）在软件项目变得复杂之后无法有效地进行协作，GitHub项目在2021年初发布了"Discussion"，并且也在其自身的治理中使用了[36]。在这个官方论坛中，开发者和用户在使用GitHub系统开发和使用过程中面临冲突时，可以提出改进。通过讨论和投票，他们可能达成共识，并制定解决冲突的计划。然后，他们可以自行关闭请求。如果不能自发的社区改进不能解决矛盾，用户和开发者可以等待工作人员回应并改进社区功能或内容。因此，GitHub项目社区有两层治理结构。开发者和用户构成下层，他们协同开发GitHub项目社区。拥有中心化特权的GitHub员工构成上层。GitHub可以被描述为CAO。图1显示了GitHub中的治理结构和冲突解决过程。
Aave是一个DAO，其成员开发和管理一个Web 3借贷系统[37]。自2017年11月启动以来，Aave已经发展成为前10的Defi项目和所有Web 3项目的前50。目前，超过100k的开发者和用户参与到社区中。Aave的开发和治理模型是由四个平台和基于区块链的代币，“AAVE”构建的。首先，DAO有一个Discord服务器，这是生成提案的第一个地方。例如，任何有解决社区冲突或改进项目的想法的人都可以在服务器上发布，并与其他人讨论。之后，Aave提供了一个治理论坛，以形成他们的想法成为提案，并详细给社区阐述他们的想法。这个步骤中的提案被称为“Aave请求评论”（ARC）。然后，ARC的发起人可以在快照平台上为ARC创建一个基于区块链数据的链下投票。这种链上/链下混合方法是效率（链下投票花费较少）和公平（链上投票数据透明，无法篡改）之间的一种妥协。如果ARC通过，发起人准备将“Aave改进提案”（AIP）提交到治理应用中，包括提案的详细描述和相关代码。任何人都可以在上述所有过程中加入发起人，为改进做出贡献。最后，如果AIP通过最终投票（基于实时代币持有量），它将被嵌入到Aave的智能合约中并执行。由于区块链的透明性，防篡改性，以及智能合约的自动化，Aave中的治理结构是平坦的。除了通过上述过程，没有人可以修改社区的共识或用户生成的内容。因此，Aave是一个DAO。图2显示了Aave中的治理结构和冲突解决过程。
作为我们的研究对象，GitHub项目社区（CAO）和Aave项目社区（DAO）在一点上是相似的，因为他们都是开发者和用户在一个软件开发中协作场域。考虑到他们的治理，GitHub的官方“Discussion”论坛和Aave的四个平台都被用来达成共识和解决冲突，反映出自治性。然而，他们的差异是显而易见的。GitHub有一个比开发者和用户更高权限的员工层。相比之下，Aave社区是由区块链和智能合约支持和保证的，而且在治理上更少的中心化。
我们使用了混合方法来研究DAOs和CAOs如何处理危机相关的讨论以及他们是否解决了冲突。我们进行了关于成员行为的定性观察，对话语的NLP分析，以及链上数据分析来比较这些社区。我们应用了群际接触理论来定性分析社区解决冲突的能力。
为了分析GitHub和Aave开发者社区是否以及如何解决由于危机讨论引起的冲突（RQ1），我们从三个地方收集了讨论信息：1）GitHub Discussion论坛；2）Aave Discord频道；和3）Aave治理论坛。我们从2021年10月至2022年3月获取了数据。我们从GitHub Discussion论坛收集了5889个主题和17189条消息的标题，时间戳，消息，和用户信息。我们还收集了从Aave Discord频道的42998条消息的时间戳，消息，和用户信息；以及来自Aave治理论坛的533个提案和1200条消息的标题，消息，时间戳，和用户信息。此外，为了研究区块链，尤其是投票机制在解决冲突中的作用（RQ3），我们从同一时期抓取了ARC和AIP投票的选民人数和结果。
为了回答RQ1，我们使用了出现多少种冲突以及冲突类型是否发生转换作为维度，来比较两个社区在危机期间的冲突解决表现。对于可以被量化或视觉比较的冲突类型，我们进行了定量比较。其他内容，我们进行定性观察和讨论。为了研究RQ1.1，我们描述了在危机期间GitHub和Aave发生了什么。为了进行深入比较，我们使用NTLK套件对获取的话语进行预处理。为了探索RQ1.2，我们使用TextBlob来比较预处理数据中的情绪变化。然后，我们进行了由KH Coder [38]提供的语义网络分析。这种方法避免了人为编码者的主观影响，并广泛用于在线话语主题研究[39]。我们使用了在两个社区中最常见的200个关键词来获取月份话题框架并保留整个跨越树。关键词的位置基于Fruchterman和Reingold算法。每个框架中的词揭示了一个主题。关键词之间的关联通过Jaccard系数计算，并通过边和线连接。
为了回答RQ2，我们使用一个社区满足接触理论的多少条件作为维度，进行定性比较分析（QCA）。QCA方法允许进行跨案例分析，通常用于比较由多个元素引起的社会问题[40]。我们比较了这两个社区是否实现了这个理论，以分析他们反应背后的因素。为了探索RQ3，我们使用了上述问题的发现和广泛收集的数据来进行比较研究。
我们使用观察和收集的数据来回答上述研究问题。 每个问题的结果在后续小节中讨论。
通过观察讨论，我们可以了解是否发生了任务冲突。然后，通过聚类分析，可以揭示新提案与之前任务的关系。我们首先分析了共现网络的结果。然后，我们手动总结了主导框架的主要内容，并比较了这两个社区的月度变化。如果主题框架在子图中有相似的关键词，那么它们就会以相同的颜色表示。关键词圈的大小表明该词在特定月份讨论中的频率。为了比较外部危机的影响，我们用同样的黄色高亮表示在这两个社区的危机讨论。
在GitHub上，危机讨论从2月25日持续到3月2日。第一条信息在军事行动后大约半天出现，呼吁社区“由于大规模入侵乌克兰，应该切断俄罗斯对GitHub访问权”（图3的第一部分）。我们观察到人们对社区应如何响应表达了不同的观点。有些人支持初始帖子，如“...GITHUB必须表明其支持！俄罗斯把它当作武器！”然而，有人怀疑限制俄罗斯人的访问能否有效地阻止地缘政治冲突，例如，“封锁GitHub只会给我带来麻烦，对我们的总统没有任何影响。”这些讨论涉及社区接下来应该做什么，因此它们表明在GitHub上发生了任务冲突。2月28日，原作者选择了一条关于禁止在军事应用中使用开源代码的用户信息作为最佳答案。GitHub的一位高级经理（michellemerrill）在同一天取消了最佳答案。然后，3月2日，GitHub员工发表了官方声明，并将其设为所有相关讨论的最终答案。团队还锁定了所有这些讨论（图3的第2-4部分）。这标志着GitHub上直接讨论危机的结束。
图4显示了GitHub话语的话题月度共现网络分析。图4(a)2021年10月子图识别出了2021年10月的八个主要框架，展示了GitHub的主要任务。其中五个通过“filter-star”，“create-list-add”，“file-code-search”，“github-editor-web”，“request-review”和“account-status”的关键词相连。另外三个集群，“developer”，“link”和“good idea”，完全没有与其他集群连接，存在感较弱。框架01主要与GitHub上开发人员的编码工作相关。框架02主要与Repo问题相关。它连接了其他四个主要内容，并在GitHub社区工作流程中起到了组合器的作用。框架03是关于项目和问题的。框架04主要与应用审查和提交相关。框架05讨论了调试和处置。然后，虽然存在一些微小的变化，但我们可以在图4(b) 2021年11月，图4(c) 2021年12月和图4(d) 2022年1月的子图中观察到大致相同的任务安排。任务冲突发生在图4(e) 2022年2月。黄色高亮的框架26指示了危机讨论。这个框架与框架01、03和15相连。所有这些框架都是GitHub的关键任务。因此，在危机爆发后，GitHub上的相关讨论引起了人们的关注，引发了任务冲突。然后，图4(f) 2022年3月显示了2022年3月社区的14个框架。我们注意到危机讨论减少了（框架26）。这表明直接禁止讨论可以缓解GitHub上的任务冲突。
在危机爆发之前，Aave的Discord服务器上出现了一些讨论，“战争即将来临。”（图5的第一部分）。在2月24日，一些DAO成员表达了他们的担忧，“...每个人都因为俄罗斯的行为而恐慌。”也有人发现他们的链上操作失败：“...网络错误。可能是由于入侵造成的？”然而，我们并未观察到很多相关的讨论。一个Aave成员在2月27日创建了一个ARC“从Aave国库中捐款支持乌克兰人民”。该提案要求社区从其国库中捐出200万美元（图5的第二部分）。它需要调整智能合约。有些用户表示赞同，“任何帮助都是受欢迎的...”，而有些人认为Aave应该保持中立，“Aave应该保持政治中立...”。此外，人们还讨论了捐款对象应该是谁。因此，任务冲突也发生了。Aave使用了基于区块链的投票，这是一种去中心化的方法，来解决任务冲突。一些Aave成员建议DAO可以创建投票来解决争论。“...DAO的神奇之处在于，这可以通过投票轻松解决。”
因此，发起者在2月27日创建了一个Snapshot投票。大约98.18%的选民选择了“否”，1.82%的选民选择了“是”。投票结束后，发起者在2月28日宣布了结果，并放弃了提案。发起者说，“社区已经决定保持中立...那就这样吧。”然后，由于这个ARC上再也没有回复，所以它在3月7日被关闭（图5的第3和4部分）。
图6显示了Aave的月度共现网络。图6(a) 2021年10月显示了13个框架。最大的框架01与Discord和欺诈风险相关。这也反映在软件开发中，如框架06“参数风险”和框架13“安全因素”。此外，与GitHub的任务主要集中在软件上不同，治理框架是Aave的另一个主要部分。框架31强调了用户的提案和想法。它间接地连接到了框架05，即基于Snapshot的投票。这些连接符合Aave的治理过程：人们基于自己的想法提出提案后，社区在Snapshot上进行投票。框架09，26，27，32，33涉及到协议的开发和使用。框架12，17，18关于市场营销和社区活动。这些基本任务在图6(b) 2021年11月，图6(c) 2021年12月和图6(d) 2022年1月的结果中几乎是相同的。在图6(e) 2022年2月中，危机讨论只出现在小框架07中（与GitHub的黄色高亮色相同）。社区任务的主体与前几个月基本相同。值得注意的是，危机与“在snapshot上投票”（框架05）链接，最后附加到主要的社区主题（框架01和16）。除此之外，危机框架26并未链接到社区工作流程或开发问题。在图6(f) 2022年3月中，框架26并未出现。
我们在这部分的分析发现：
危机讨论在这两个社区中发生，成员们提出了新的任务。因此，这两个社区的任务冲突都是由外部影响（俄乌危机）触发的。
在GitHub上，新任务与之前的任务相链接，并占据了大量空间。相比之下，新任务通过投票过程从Aave的主要工作中被隔离开来，只占据了小部分空间。
GitHub员工对讨论发布了官方回应，并关闭了所有这些线程。与此同时，Aave开发人员发起了一个基于区块链的投票，来决定是否应该改变DAO的任务。
这些结果揭示了中心化和去中心化平台在应对任务冲突时的区别。社区管理员可以直接干预中心化平台上的讨论。相比之下，在去中心化平台上，管理员的权限受到限制，他们不能单方面做出决定。
在确定了中心化自治组织(CAO)直接禁止讨论，而去中心化自治组织(DAO)使用投票来解决任务冲突之后，我们通过观察和情感分析来研究这两个社区的冲突是否转变。
在GitHub上，我们观察到随着争论的加剧，任务冲突转化为情感冲突。许多人指出，俄罗斯的行为并不能代表其人民，社区应该分开对待他们，“大多数俄罗斯人反对战争！”然而，相反的观点是“只有俄罗斯人可以阻止它。”和“也许如果你失去了访问GitHub的权限，你会足够在乎去试图改变它。”此外，支持俄罗斯的用户辩护军事行动的合理性，“这不是俄罗斯入侵乌克兰，而是阻止北约入侵俄罗斯”和“那里的人们和俄罗斯曾是同一个国家的一部分……”。随后，更加激进的言论出现，“现代的俄罗斯是一个纳粹国家”，“为什么整个俄罗斯人要因为别人的行为而被封禁，这简直是种族主义？”等。相比之下，我们在Aave上并没有观察到类似的情况。
我们对两个社区的讨论进行了情感分析。为了便于比较，我们定义情感百分比SP = (Num.S/Num.T)%。在这个等式中，Num.S表示具有一种极性（正面/中性/负面）或主观性（主观/中性/客观）属性的讨论数量。Num.T表示同一时期的讨论总数。我们可以通过比较极性和客观性百分比的月度变化来判断人们的情绪变化（见图7）。
在极性方面：1) CAO和DAO在危机之前保持稳定；2) 在2月份危机爆发后，GitHub上负面评论的百分比比Aave增加得更多；3) 由于GitHub的工作人员关闭了讨论，GitHub上负面评论的百分比略有下降，但仍高于Aave；4) 在这六个月中，GitHub始终比Aave有更高的正面评论百分比。同时，Aave主要是中立讨论。在主观性方面：1) CAO和DAO的评论主要是客观的，这对开发者社区是合理的；2) Aave的讨论始终比GitHub有更高的客观性百分比；3) 自2021年10月以来，GitHub上客观评论的百分比已经下降，而主观评论的百分比已经上升。这种趋势在GitHub关闭危机讨论后改变。相比之下，Aave的主观性并没有明显的变化。
因此，通过观察和情感分析，我们发现简单地禁止危机讨论并不能完全解决冲突，而是将GitHub上的原始冲突转化为情感冲突。但在Aave上，这种转化并不明显。换句话说，DAO在解决情感冲突方面表现得比CAO更好。
对于GitHub是否应该应对危机相关任务的问题，有些人表示反对，“切断俄罗斯人会对自由软件社区造成伤害”和“Github被用作为那些能够开发软件工具的人的自由平台……”考虑到“开源”[41]的价值，GitHub最终没有限制俄罗斯用户。然而，由于GitHub关闭了这些讨论，可能会产生紧张关系。相比之下，投票后，Aave的成员对解决过程表达了积极的观点，认为这符合其价值观，例如“虽然快照没有通过，但它是鼓舞人心的……”投票过程符合DAO的规则。因此，至少在我们的研究中，我们没有在GitHub和Aave上观察到过程冲突和规范冲突。
总的来说，我们的比较分析揭示了以下内容。
由于其中心化冲突管理方式，GitHub上的任务冲突转化为情感冲突，直接禁止讨论。成员在讨论中显示出明显的负面和主观情绪。在Aave中，这一点并不明显。
作为一个CAO，GitHub对冲突的反应符合其社区规则，没有过程和规范冲突。Aave的DAO模型也避免了转化为这些冲突。因此，对于RQ1，DAO模型可以比CAO更好地缓解由外部影响的讨论引起的冲突。表1显示了五个维度的比较结果。
Aave比GitHub更好地缓解了由外部危机引发的讨论冲突，并更好地支持了协作。因此，我们引入了接触理论（见3-C节），该理论研究团体中的冲突和协作，以研究CAO和DAO模型之间的冲突缓解差异的原因。我们发现，DAO模型比CAO模型更好地满足了该理论提出的消除冲突和促进协作的四个条件。
员工与用户之间：如上所述，GitHub社区呈现出更加等级化的结构。它的员工被GitHub雇佣，他们管理CAO上的用户行为。他们在讨论中比普通开发者和用户有更多的特权，如修改和锁定讨论的权利。相比之下，虽然Aave也有管理员，但由于DAO模型，他们在社区中并没有特权。在图8的第1部分，Aave的一个管理员参与了ARC讨论。他陈述了自己对讨论的看法，并参与了投票。
用户与用户之间：DAO在用户之间有更好的平等地位。如图8的第2部分所示，投票页面只显示了参与者的区块链地址，没有他们的背景信息，如地理位置。这可以减少身份信息的干扰，帮助用户集中注意力在讨论上。然而，GitHub的用户可以很容易地发现其他人的背景，形成不同的团体。如图8的第3部分，其他人认为一个用户在讨论中没有资格参与，因为“...你在加利福尼亚……”。讨论变成了基于身份政治的攻击。
显然，CAO和DAO都有共同的目标。但是，通过分析GitHub员工关闭讨论时发布的消息（图3的第4部分），我们可以发现，作为一个为全球最大的开源软件社区服务的公司，GitHub在面对外部危机时必须调开发者（“GitHub的愿景是成为所有开发者的家……”）、政府（“我们非常重视政府要求的责任……”）和平台自身的利益。因此，社区的共同目标是混合和复杂的。Twitter和Facebook等平台公司也出现了类似的情况。面对多部分的目标和利益的冲突，一个CAO很难确保所有的利益相关者和谐共存[42]。Aave则简单得多。大多数成员都是Aave代币持有者。因此，将DAO国库资金捐给乌克兰直接影响到所有持有者的利益，包括提案发起人、管理员和所有投票参与者。社区和用户之间的目标更加重叠。因此，在讨论中，我们观察到了以下声明：“我已经自己捐款，并鼓励其他人在个人层面上这样做。(但使用国库,)我投反对票，”“...让公共国库置身事外，”等等。
GitHub和Aave的不同组织模型决定了它们进行群间合作的不同方式。由于GitHub的员工是最终的决策者和社区行动执行者，一般的合作方式可以概括为用户提出请求，等待反馈或执行。另一方面，Aave通过成员共同投票来决定社区行动。我们获得的数据显示，在外部战争讨论中，GitHub的方法并不够有效。我们发现有359个来自社区用户对GitHub平台的已确认请求。这些请求占所有相关回答和回复的21.20%。然而，GitHub忽视了所有这些请求。除了删除原作者设置的最佳答案，GitHub最后只回复了官方声明，并锁定了讨论。相比相关讨论的数量，GitHub的回复只占0.06%。
当我们扩大研究范围，看看外部战争对这些社区的后续影响时，我们发现Aave比GitHub提供了更中立的权威支持。在3月7日ARC关闭后，社区并没有做出任何限制特定地理区域用户访问的公告。我们通过VPN多次调整了IP地址的地理位置，试图访问Aave的平台和协议。我们没有发现任何隐藏的限制。因此，我们推断Aave根据投票结果保持中立。然而，GitHub显示了可能的治理倾向，尽管其员工承诺考虑政府和开发者用户的利益。一个负面的案例是，一个用户在4月7日发现“乌克兰的号码（+38）不在两步验证的列表中”，导致其无法正常使用GitHub服务。随后，GitHub的员工回复说，乌克兰和俄罗斯目前不在支持的国家列表中。通过网络存档服务我们发现，至少在2021年10月之前，俄罗斯和乌克兰仍在列表中。考虑到一些平台公司在地缘政治冲突中采用骑墙策略（straddle strategy）来保护自己的利益[43]，也许GitHub采用了类似的策略。
我们通过接触理论的四个条件对GitHub和Aave进行了QCA，表2显示了结果。我们发现，在面对外部危机时，Aave依赖其DAO模型，很好地适应了这四个条件。而GitHub并未满足“平等地位”和“社群间合作”。另外，在较难实现“共同目标”的同时，GitHub对“中立权威的支持”的履行也存疑。因此，根据接触理论，遵循DAO模型更有可能缓解由巨大的外部影响引起的社区冲突。
可能有一种错觉，认为如果Web 2的CAO增加了投票、将治理行为与用户的利益联系起来以及更好的隐私保护等功能，这些中心化的社区也能符合接触理论，并在解决冲突方面有更好的表现。但我们发现，如果没有Web 3技术的支持，这些功能，如投票，在Web 2背景下不能有效地发挥作用。
一个假设是，如果用户的治理行为和他们的个人利益之间已经有了联系，也许Web 2社区平台和用户的利益可以协调起来，形成一个更统一的共同目标。我们发现GitHub在2021年4月发布了 "成就 "功能。该功能意在给开发者一个展示自己对社区贡献的方法，这也是考察开发者能力的一种方式，有助于未来雇主更好地了解他们。该系统包含六个徽章，开发者可以在档案中显示他们的成就。
我们记录了所有成就在GitHub社区的讨论，并按内容进行了分类。我们发现，社区成员普遍赞赏成就的功能，因为它显示了用户的贡献，并可能在未来带来更多的个人利益。然而，它的运作似乎并不十分理想。大约14.3%的反馈明确表达了用户对这一功能的喜爱。然而，21.9%的讨论表达了反对意见，如 "yolo徽章没有传递正确的信息，特别是对招聘人员"，"我不想要徽章，......我想要一个存储我的代码的地方"。此外，32.8%的开发者对如何获得成就徽章表示困惑，"Github的新成就多久更新一次？" 另外，30.8%的人对各种bug进行了反馈，比如 "我的2x Pull Shark成就不知为何不见了"。显然，评估成员在一个组织内的贡献一直是很困难的。集中式的评估并不总是能够合理地评估成员的贡献并带来个人利益[44]。
在基于区块链的DAO中，直接的财务激励方式解决了这个问题。Aave中的提案发起人、治理议题的讨论者、投票的参与者以及社区管理者都是Aave代币的持有者。在Web 3中，一个项目的代币经济不仅可以让所有这些人在经济上形成一个具有共同利益的社区，而且还可以作为一个媒介，轻松地将用户在社区中的治理行为与个人奖励结合起来。我们从其2021年10月至2022年3月的链上数据中获得了AAVE的代币价格P（美元计价）。我们还记录了同期AAVE社区的AIP提案编号，Num（每个成功执行的AIP记录为1，失败的记录为-1）。结果显示在图9中。
如表3所示，Num和P的ADF检验分别为-4.69和-1.29。因此，我们可以使用VAR模型来研究提案如何影响代币价格。我们选择了最佳滞后阶数为1，并从Num获得了P的脉冲响应（见图10）。它显示，提案对代币价格的脉冲在第二天达到峰值，为35.65美元（-46.36，118.36，95%CI置信区间），20天后影响趋于零。对于代币持有人来说，价格与他们的利益直接相关。而他们对治理的参与会给他们带来积极的回报。因此，与Web 2 CAO不同，Web 3基于代币的经济和治理允许DAO成员为其治理行为直接获得经济利益。
由于Web 3技术在治理方面引起的变化包括DAO中的匿名机制。在讨论中，我们观察到GitHub成员是如何通过审视其他用户的地理信息来判断用户的意见。事实上，通过检索GitHub上所有这些危机讨论，我们发现在总共474名讨论参与者中，共有26名来自波兰（5.48%）、42名来自俄罗斯（8.86%）和37名来自乌克兰（7.81%）的用户不得不自我披露其地理信息，并反复重申自己观点的中立性。即便如此，他们仍受到不少其他用户的质疑。在网络社区中，自我披露或披露他人的背景信息非常普遍。人们往往通过这种行为获得社会资源，导致偏见的产生[45]。然而，Web 3可以通过提供匿名性来改变这种困境。例如，将零知识证明技术应用于区块链可以进一步减少披露用户账户信息的需要。因此，它可以促进治理参与者对治理细节的关注，而不受用户信息的影响[46]。
虽然在2022年俄乌危机期间，DAO比CAO更能解决冲突。但是，我们发现它的投票治理过程仍有局限性。在所有代币持有者中，投票参与者的比例相对较低。如上所述，我们观察到只有0.17%的Aave代币持有者参与了关于战争的投票，这明显低于其社区中常规投票的比例6.23%。这意味着大多数人在处理潜在冲突时往往保持沉默。投票意愿低并不是Aave独有的情况。在其他DAO案例中，提案不能达到法定人数也是一个问题[47]。投票参与度低限制了DAO解决冲突的能力。基于Aave的研究，我们总结了这种困境的原因：
1）对参与投票没有直接奖励。Aave的治理可以通过提高货币价格给其代币持有者带来经济激励。然而，这种机制缺乏对治理行为的直接奖励。这个问题与传统的投票不能规避搭便车（free rider）问题一样[48]。换句话说，不参与投票的代币持有者也可以从其他人的投票行为中获益。因此，需要改进投票系统，使投票参与者除了获得加密货币价格上涨的经济激励外，还能从其投票行为中获得直接奖励。
2）参与投票的过程需要跨平台操作。4-B节中Aave的投票过程相当复杂。因此，无法在DAO成员日常交流的地方直接投票也制约了投票的参与。
因此，我们基于Aave的投票系统为DAO提出了一个改进的原型。我们将其命名为竞价-激励投票（bidding-incentive voting）。我们的原型的灵感来自于 "赋予投票以博彩性质，奖励那些投票给正确选项的人，同时惩罚那些投票给错误选项的人" [49]。我们的研究表明，投票行为应该得到社区的奖励。DAO国库的25%将被留作奖励资金。投票参与者将收到智能合约发送的代币作为奖励。每张投票的奖励总额与本次投票的参与者总数占DAO总代币持有者的比例呈正相关。投票选项与投票结果相匹配的参与者将获得比不匹配的参与者多10%的奖励。对于不参与投票的代币持有者，在他们使用DAO的服务时，可以比参与投票的成员多加一定百分比的手续费。这种 "惩罚 "应该平衡国库用于奖励投票参与者的费用。另外，还需要设计一个操作门户或系统，允许DAO成员直接在讨论第一发生地进行投票。图11显示了我们的原型。
首先，我们的研究样本存在着局限性。我们的研究选择了GitHub和Aave来分别代表CAO和DAO。但还有其他类型的开发者社区（如Stack Overflow论坛），可能以不同的方式运行。此外，我们研究中的冲突原因是2022年的俄乌危机。但如果是其他重大的外部危机，冲突可能会发生变化。因此，未来的工作需要分析其他DAO和CAO如何管理由各种外部危机讨论引起的冲突。其次，虽然集中式和分散式的治理模式是GitHub和Aave的主要区别，但它们不同的冲突管理可能也源于其他因素。因此，未来的工作应该考虑更全面的因素。第三，虽然我们引入了接触理论作为衡量标准来分析DAO保持较好的社区氛围和生产力的机制，但我们只采用了比较分析的方法，并主要进行了定性的讨论。未来的研究可能会使用建模方法来获得更多的量化证据和更深入的见解。最后，我们没有验证我们改进DAO投票机制的建议的有效性。在未来，我们将与DAO合作，并进行实验，以弄清楚这种基于货币激励的改进能有多少投票率的提高。我们还将探索其他的投票改进方法，包括设计代表 "I Vote！"的NFT，设计一个投票活动的公告板等。
在这项工作中，我们对GitHub（CAO）和Aave（DAO），在管理因讨论如何处理2022年俄乌危机而引起的冲突方面的差异进行了比较分析。我们研究的动机包括： 1）讨论和伴随的冲突对合作至关重要，但很少有研究关注地缘政治事件等突如其来的巨大外部危机引起的冲突；2）2022年俄乌危机是冷战后影响最大的地缘政治事件之一，其影响仍在持续；3）对基于区块链技术的创新组织DAO在解决冲突中的表现研究很少。
因此，我们选择了GitHub和Aave这两个开源开发者社区作为研究对象，不仅是因为它们都受到了危机的影响，还因为中心化/非中心化的治理模式是它们的显著区别。我们考虑它们是否出现了具体的冲突或转变，作为比较它们在俄乌危机期间表现的维度。我们主要发现： 1）虽然它们都因为危机讨论而引发了任务冲突，但GitHub的集中式治理引起了冲突类型转换，发生了情感冲突；2）Aave的DAO模式避免了冲突转型为其他冲突。因此，我们假设DAO可能比CAO更好地缓解由外部危机引起的冲突。
我们的研究使用接触理论来解释这一现象。我们发现，DAO比CAO更符合该理论提出的消除冲突和促进协作的四个条件，这从跨学科领域为我们的假设提供了证据。然后，我们推断，区块链技术、投票机制和加密货币在DAO管理和解决冲突中发挥了关键的作用。我们还发现DAO的选民投票率可能较低。因此，我们建议增加货币激励，以改善DAO基于区块链的投票机制，使DAO能够让更多的社区成员参与进来，形成共同目标。
[1] E. V. Hippel and G. V. Krogh, “Open source software and the ‘privatecollective’ innovation model: Issues for organization science,” Org. Sci., vol. 14, no. 2, pp. 209–223, Apr. 2003.
[2] S. Easterbrook, CSCW: Cooperation or Conflict? New York, NY, USA: Springer, 2012.
[3] D. Graziotin, X. Wang, and P. Abrahamsson, “Happy software developers solve problems better: Psychological measurements in empirical software engineering,” PeerJ, vol. 2, p. e289, Mar. 2014.
[4] J. Gamalielsson, B. Lundell, and B. Lings, “Responsiveness as a measure for assessing the health of OSS ecosystems,” in Proc. 2nd Int. Workshop Building Sustain. Open Source Communities (OSCOMM). Tampere, Finland: Tampere Univ. of Technology, 2010, pp. 1–8.
[5] K. Crowston and J. Howison, “Assessing the health of open source communities,” Computer, vol. 39, no. 5, pp. 89–91, 2006.
[6] A. Filippova and H. Cho, “Mudslinging and manners: Unpacking conflict in free and open source software,” in Proc. 18th ACM Conf. Comput. Supported Cooperat. Work Social Comput., Feb. 2015, pp. 1393–1403.
[7] M. A. Rahim, Managing Conflict in Organizations. Evanston, IL, USA: Routledge, 2017.
[8] M. Tuncer, “Ukraine crisis; an old-and the new conflict between democracies and autocracies and footsteps of Russian imperialism,” Int. J. Sci. Res., vol. 11, no. 3, pp. 346–348, 2022.
[9] M. Melanson. (2022). Where Does Open Source Fit Into Russia’s War With Ukraine? [Online]. Available: https://thenewstack.io/where-doesopen-source-fit-into-russias-war-with-ukraine/
[10] M. L. R. Chan. (2022). Open-Source Developers are in the Shadow of Russia’s War on Ukraine. [Online]. Available: https://www.businessinsider.com/open-source-developers-ukraine-russia-war-2022-5
[11] N. Zöller, J. H. Morgan, and T. Schröder, “A topology of groups: What GitHub can tell us about online collaboration,” Technol. Forecasting Social Change, vol. 161, Dec. 2020, Art. no. 120291.
[12] G. W. Allport, K. Clark, and T. Pettigrew, The Nature of Prejudice. New York, NY, USA: Basic Books, 1954.
[13] H. Mäenpää, M. Munezero, F. Fagerholm, and T. Mikkonen, “The many hats and the broken binoculars: State of the practice in developer community management,” in Proc. 13th Int. Symp. Open Collaboration, Aug. 2017, pp. 1–9.
[14] T. Lima, R. P. D. Santos, J. Oliveira, and C. Werner, “The importance of socio-technical resources for software ecosystems management,” J. Innov. Digit. Ecosyst., vol. 3, no. 2, pp. 98–113, Dec. 2016.
[15] Y. Wu, J. Kropczynski, P. C. Shih, and J. M. Carroll, “Exploring the ecosystem of software developers on GitHub and other platforms,” in Proc. Companion Publication 17th ACM Conf. Comput. Supported Cooperat. Work Social Comput., Feb. 2014, pp. 265–268.
[16] D. Schneider, S. Spurlock, and M. Squire, “Differentiating communication styles of leaders on the Linux kernel mailing list,” in Proc. 12th Int. Symp. Open Collaboration, Aug. 2016, pp. 1–10.
[17] A. Filippova and H. Cho, “The effects and antecedents of conflict in free and open source software development,” in Proc. 19th ACM Conf. Computer-Supported Cooperat. Work Social Comput., Feb. 2016, pp. 705–716.
[18] J. Tsay, L. Dabbish, and J. Herbsleb, “Let’s talk about it: Evaluating contributions through discussion in GitHub,” in Proc. 22nd ACM SIGSOFT Int. Symp. Found. Softw. Eng., Nov. 2014, pp. 144–154.
[19] B. Cleary, C. Gómez, M.-A. Storey, L. Singer, and C. Treude, “Analyzing the friendliness of exchanges in an online software developer community,” in Proc. 6th Int. Workshop Cooperat. Hum. Aspects Softw. Eng. (CHASE), May 2013, pp. 159–160.
[20] C. Jensen and W. Scacchi, “Process modeling across the web information infrastructure,” Softw. Process: Improvement Pract., vol. 10, no. 3, pp. 255–272, 2005.
[21] M. Elliott and W. Scacchi, “Communicating and mitigating conflict in open source software development projects,” Projects Profits, vol. 4, no. 10, pp. 25–41, Oct. 2002.
[22] A. Filipova and H. Cho, “Below boiling point: Negotiating conflict thresholds in distributed work,” AoIR Sel. Papers Internet Res., vol. 4, Oct. 2014.
[23] A. S. Barcomb, “Retaining and managing episodic contributors in free/libre/open source software communities,” Univ. Limerick, Limerick, Ireland, Tech. Rep., 2019.
[24] R. S. Geiger, D. Howard, and L. Irani, “The labor of maintaining and scaling free and open-source software projects,” Proc. ACM Hum.Comput. Interact., vol. 5, pp. 1–28, Apr. 2021.
[25] D. Sholler, I. Steinmacher, D. Ford, M. Averick, M. Hoye, and
G. Wilson, “Ten simple rules for helping newcomers become contributors to open projects,” PLOS Comput. Biol., vol. 15, no. 9, Sep. 2019, Art. no. e1007296.
[26] Z. Iskoujina and J. Roberts, “Knowledge sharing in open source software communities: Motivations and management,” J. Knowl. Manage., vol. 19, no. 4, pp. 791–813, Jul. 2015.
[27] F. A. Alabdulwahhab, “Web 3.0: The decentralized web blockchain networks and protocol innovation,” in Proc. 1st Int. Conf. Comput. Appl. Inf. Secur. (ICCAIS), Apr. 2018, pp. 1–4.
[28] K. Nath, S. Dhar, and S. Basishtha, “Web 1.0 to web 3.0—Evolution of the web and its various challenges,” in Proc. Int. Conf. Rel. Optim. Inf. Technol. (ICROIT), Feb. 2014, pp. 86–89.
[29] Z. Zheng, S. Xie, H.-N. Dai, X. Chen, and H. Wang, “Blockchain challenges and opportunities: A survey,” Int. J. Web Grid Services, vol. 14, no. 4, pp. 352–375, 2018.
[30] J. Brassey, R. Burns, and L. Knight, “What the Dao?” Trusts Trustees, vol. 28, no. 6, pp. 517–521, 2022.
[31] V. Buterin et al., “A next-generation smart contract and decentralized application platform,” White Paper, vol. 3, no. 37, pp. 1–2, 2014.
[32] H. Diedrich, Ethereum: Blockchains, Digital Assets, Smart Contracts, Decentralized Autonomous Organizations. Sydney, NSW, Australia: Wildfire Publishing, 2016.
[33] C. Jentzsch, “Decentralized autonomous organization to automate governance,” Blockchains, Sparks, NV, USA, White Paper 1, Nov. 2016.
[34] I. Arawjo, A. Mogos, S. J. Jackson, T. Parikh, and K. Toyama, “Computing education for intercultural learning: Lessons from the Nairobi play project,” Proc. ACM Hum.-Comput. Interact., vol. 3, pp. 1–24, Nov. 2019.
[35] A. Rajadesingan, C. Duran, P. Resnick, and C. Budak, “’Walking into a fire hoping you don’t catch’: Strategies and designs to facilitate crosspartisan online discussions,” Proc. ACM Hum.-Comput. Interact., vol. 5, pp. 1–30, Oct. 2021.
[36] H. Hata, N. Novielli, S. Baltes, R. G. Kula, and C. Treude, “GitHub discussions: An exploratory study of early adoption,” Empirical Softw. Eng., vol. 27, no. 1, pp. 1–32, Jan. 2022.
[37] J. Xu and N. Vadgama, “From banks to DeFi: The evolution of the lending market,” in Enabling the Internet of Value. New York, NY, USA: Springer, 2022, pp. 53–66.
[38] K. Higuchi, “A two-step approach to quantitative content analysis: KH coder tutorial using Anne of green gables,” Ritsumeikan Soc. Sci. Rev., vol. 52, no. 3, pp. 77–91, 2016.
[39] S. J. Baele, L. Brace, and T. G. Coan, “Variations on a theme? Comparing 4chan, 8kun, and other chans’ far-right/‘pol’ boards,” Perspect. Terrorism, vol. 15, no. 1, pp. 65–80, 2021.
[40] D. Berg-Schlosser, G. De Meur, B. Rihoux, and C. C. Ragin, “Qualitative comparative analysis (QCA) as an approach,” inConfigurational Comparative Methods: Qualitative Comparative Analysis (QCA) and Related Techniques, vol. 1. Newbury Park, CA, USA: SAGE, 2009, p. 18. IEEE TRANSACTIONS ON COMPUTATIONAL SOCIAL SYSTEMS
[41] Open Source Initiative. (2007). The Open Source Definition. [Online]. Available: https://opensource.org/osd
[42] M. Bastos and D. Mercea, “The public accountability of social platforms: Lessons from a study on bots and trolls in the brexit campaign,” Phil. Trans. Roy. Soc. A, Math., Phys. Eng. Sci., vol. 376, no. 2128, Sep. 2018, Art. no. 20180003.
[43] B. Lee. (2016) The Impact of Cyber Capabilities in the Syrian Civil War. Accessed: Jun. 20, 2022. [Online]. Available: https://smallwarsjournal. com/jrnl/art/the-impact-of-cyber-capabilities-in-the-syrian-civil-war
[44] J. Tsay, L. Dabbish, and J. Herbsleb, “Influence of social and technical factors for evaluating contribution in GitHub,” in Proc. 36th Int. Conf. Softw. Eng., May 2014, pp. 356–366.
[45] N. N. Bazarova and Y. H. Choi, “Self-disclosure in social media: Extending the functional approach to disclosure motivations and characteristics on social network sites,” J. Commun., vol. 64, no. 4, pp. 635–657, Aug. 2014.
[46] X. Sun, F. R. Yu, P. Zhang, Z. Sun, W. Xie, and X. Peng, “A survey on zero-knowledge proof in blockchain,” IEEE Netw., vol. 35, no. 4, pp. 198–205, Jul. 2021.
[47] O. Rikken, M. Janssen, and Z. Kwee, “Governance challenges of blockchain and decentralized autonomous organizations,” Inf. Polity, vol. 24, no. 4, pp. 397–417, Dec. 2019.
[48] D. Cvijanovic, M. Groen-Xu, and K. E. Zachariadis, “Free-riders and underdogs: Participation in corporate voting,” ECGI, Brussels, Belgium, Finance Working Paper 649/2020, 2020.
[49] R. Hanson et al., “Shall we vote on values, but bet on beliefs?” J. Political Philosophy, vol. 21, no. 2, pp. 151–178, 2003.