What Makes a Great Maintainer of Open Source Projects?

What Makes a Great Maintainer of Open Source Projects

是什么造就了一名优秀的开源项目维护者？

摘要

尽管开源软件的维护者大部分时间都花在编码工作上，但是一名优秀的维护者必须在编码之外的其他活动中也表现出色。

维护者应该关心社区建设，帮助新成员找到自己的位置，同时拒绝那些虽然编码良好，测试良好，但是对项目的目标没有帮助的代码补丁。

为了熟练地执行所有这些活动，维护者应该练习软件工程师（特指在闭源项目中工作）不总是需要掌握的技能。

本文的目的就是揭示、联系和区分优秀的开源软件维护者可能具有的独特属性。

为了达到这个目的，我们对经验丰富的维护者们进行了 33 次半结构化的采访，这些维护者们是诸如 Linux 内核， Debian 操作系统和 Gitlab 平台等著名项目的看门人。

在我们分析了这些采访并且整理了属性列表后，我们创建了一个概念框架来解释，这些属性是如何联系在一起的。随后我们对 90 名开源软件的贡献者进行了一次评级调查。我们注意到「技术卓越」和「沟通交流」是最常见的属性。

当对所有属性进行分组时，这些属性可以分为四大类：管理、社交、技术和个性。

虽然我们注意到 “保持项目的长期愿景” 和 “极其谨慎” 似乎构成了我们框架的基础，但是我们通过调查发现，「沟通交流」属性被视为最重要的属性。

关键词：开源软件、开源维护者、独特属性

一、介绍

是什么让一个人擅长他的职业? 数十年的研究致力于为这个问题提供答案。例如，优秀的导师能有效地帮助学生学习。优秀的管理者会发现员工的优特优势，并加以利用。

在软件工程的背景下，有些研究者进行了开创性的实证研究，试图了解优秀的软件工程师和优秀的软件工程师管理者都分别拥有哪些属性。这些研究工作揭示了数十个属性（有些是独特的属性，有些是共有的属性），这些属性对于优秀的软件工程师及其管理者来说是至关重要的。例如，对于软件工程师来说，「数据驱动」、「冒险精神」和「好奇心」是重要的属性，而对于管理者来说，「可用性」、「技术专长」和「构建关系」等属性似乎更为重要。这些研究结果对于帮助在这个要求越来越高的软件行业中培养更优秀的软件工程师和管理者而言是至关重要的。

然而，我们认为这些研究结果可能不容易直接应用到开源软件的背景下， 当从事开源软件工作时，软件工程师面临着一种新的挑战和障碍，而这些挑战是他们在为一家公司工作时并不经常遇到的。我们的一位受访者举了一个例子，说明了这种差异：

当你为一家公司工作时，你的经理会说：“创造一个产品”，然后每个人都会加入进来一起工作。我们也有专门的时间段来完成它，比如说，这个产品应该在几天或几周内完成。但是在开源软件领域内，一般没有截止日期。通常，当你发现一个你感兴趣的议题时，只要你有空，就会着手解决。这可能会需要几周或几个月的时间。在我有了如何完成某项任务的思路之前，这个议题悬而未决持续了一年。这就是基于志愿者的开源软件开发的现状。开源软件的开发需要花费时间，事情不会立即完成。至于在代码审查方面。如果是在公司工作，代码审查是每个人日常工作的一部分，在工作中，我可以在一天之内就得到 PR 代码审查。但是在开源软件工作中，通常是在维护者有空的时候才会进行代码审查，有时是在周末，有时你一周才能等到一次代码审查。

尽管我们的受访者提到了时间管理，但其他问题本质上都植根于开源软件开发。项目维护者应该做到以下三点：

• 确保项目的目标是显而易见并且透明公开的
• 花时间帮助社区新成员
• 思考项目的长期可持续性

在为一家公司工作时，软件工程师几乎不会费心考虑这些问题。

在本文中，我们的目标是揭示一组非常有价值的属性，这些属性能帮助开源软件维护者在他们的职业生涯中大放光彩。

我们借鉴了其他作者的工作。为了指导我们的研究，我们设计了三个研究问题：

三个研究问题

• RQ1：优秀的开源软件维护者拥有哪些特质/属性？
• RQ2：这些属性相互之间如何联系的？
• RQ3：贡献者如何看待这些属性的重要性？

为了回答这些问题，我们采用了一种混合方法。我们首先对备受瞩目的开源软件维护者们进行了 33 次半结构化访谈，然后就这些属性创建了一个概念性框架，最后对 90 名贡献者进行了调查。本文的贡献包括：

• 定义了 OSS 维护者的角色和职责的一个包含 22 种属性的综合清单
• 一个将优秀的 OSS 维护者的属性联系起来的概念性框架
• 关于贡献者对这些属性重要性的看法的定量证据

我们相信，通过更多地了解优秀维护者的角色和属性，就有可能改进项目的管理方式。在不放弃质量和技术优势的前提下，通过让维护者关心 OSS 社区的人际关系和社会方面，就有可能通过更具包容性和多样化的社区来改善 OSS 的面貌，从而更好地为社会服务。

二、研究方法

我们采用了混合方法的研究方法。为了回答 RQ1，我们分析了与经验丰富的 OSS 维护者的 33 次访谈中提到的 172 个属性。在回答 RQ2 时，我们创建了一个概念性的框架，在更高级别的抽象级别上理解这些属性之间的关系。最后，在 RQ3 中，我们对 90 名维护者和贡献者进行了评级调查，目的是了解他们如何对这些属性进行优先级排序。

A.Interviews

• 参与者

我们采用了一种方便的抽样方法，招募了一群我们人际网络可触达的维护者。我们还通过电子邮件和社交网络邀请了其他著名的维护者(例如，那些维护非常受欢迎的OSS项目的人)。我们采用「滚雪球」的方法，要求参与者帮我们联系其他符合条件的同事。我们在整个采访过程中都重复了这个过程。为了增加多样性，在邀请参与者时，我们优先考虑女性和非美国的维护者。我们做出这个决定是为了避免有太多的 “硅谷” 参与者，因为他们在 OSS 维护者中占了过多的比例。

我们采访了33名OSS维护者(36%是女性)，12名女性。由于这些被采访者中的一些人与少数维护者一起工作，为了保护他们的匿名性，并遵循道德访谈的指导方针，我们只在维护者的数量大于10的情况下提及项目的名称。这些维护者在一系列不同的项目上工作，包括：操作系统(例如，Debian和Linux内核)、桌面界面(例如，GNOME和KDE)、社交编程环境(例如，GitLab)、知名的编程语言(例如，Python)和教育项目。我们的受访者分布在不同的国家，如巴西、加拿大、捷克、美国、德国和葡萄牙。平均来说，他们有9年的OSS经验，尽管他们中只有11人是有偿的，全职的OSS贡献者。我们在提交的补充材料中提供了关于被采访者的额外信息。

• 访谈引导

我们进行了半结构化访谈，这是一种灵活的访谈类型，访谈者可以根据访谈时的实际情况灵活地做出必要的调整，例如添加或者删除一些问题。我们刚开始邀请了 59 名维护者来参加，只有 28 名维护者接受了邀请。我们从 2019 年 4 月到 2019 年 9 月进行了 28 次访谈。

在编码过程中，我们注意到一些属性经常出现。例如，在 28 次采访中有 16 次提到了与沟通相关的属性。我们还注意到，在第 24 次采访之后，提到的新属性较少，这给了我们一个关于属性饱和的信号。尽管如此，从 2020 年 6 月到 2020 年 8 月，我们还是邀请了另外 7 名女性维护者进行面试（接受了 5 名）。这些额外的采访有两个目标：

(1) 增加女性维护者的数量（约占我们样本的 25%）

(2) 验证我们是否已经达到饱和

这 5 次采访没有在我们的编码簿中引入任何新的代码，这是另一个饱和的迹象。因此，我们停止了招募，最终有 33 名参与者。

根据参与者的偏好，我们使用在线渠道（例如 Jitsi、Whereby）远程进行访谈。平均而言，访谈持续 44 分钟（最少 26 分钟，最多 60 分钟）。音频被记录下来，后来被转录。
五位作者进行了所有采访，第一作者转录了音频，由 otter.ai 提供技术支持。

访谈由五个部分组成。第一部分，我们询问了维护者的背景和人口统计数据。第二部分，我们询问了他们作为维护者的工作，例如他们做什么以及他们是如何做的，他们如何找到新功能，以及他们在 OSS 上投入了多少时间。第三部分，我们专门讨论了与「什么是优秀维护者」相关的话题。按照 Kalliamvakou 及其同事的指示，为了指导这部分采访，在我们的邀请电子邮件中，我们要求参与者向我们发送他们认为对优秀维护者最重要的五个属性。只关注五个属性将有如下优点：（1）避免参与者匆忙回答（2）要求他们提供有针对性的回答，丢弃不太相关的属性（3）减少回忆过去特定经历的认知负担。第四部分，我们询问参与者是否记得他们过去合作过的其他优秀的维护者，并描述为什么他们认为那个人很擅长维护 OSS 项目。最后部分，我们通过感谢参与者来结束采访，并询问他们是否可以推荐其他可以接受采访的维护者。

• 访谈分析

我们分析了 30 多个小时的采访（转录成 88,586 个字）。我们执行了两个编码程序，如下所示。

• Coding the attributes： 我们从维护者在访谈前发送给我们的 172 个原始属性开始。这个数字高于 165（5 个属性 × 33 个受访者），因为一些受访者提到了超过 5 个属性。为了将属性分组到高级类别中，两位作者采用了卡片分类方法。我们首先读取每个属性，并对明显表示相同代码的属性进行分组。然后，我们根据代码含义之间的相似性，将属性归类到更高级别的种类。这个过程需要五次（每次约 3 小时）。这个过程是在卡片分类和关于代码和类别的讨论中持续比较进行的，直到他们达成共识。**经过近 15 个小时的讨论，出现了 22 个属性，分为四个高级类别。这四个类别是：管理(Management)、社交(Social)、技术(Technical)和个性(Personality)。**每个类别都有 3 到 7 个属性。表 I 详细分解了这些类别。

• Coding the interviews： 我们使用开放编码来分析采访记录。我们首先阅读采访记录，识别关键点，并为它们分配一个代码（即，总结关键点的 2-3 个单词的陈述）。在这项工作的背景下，上一步中确定的 22 个属性被用作该分析的种子；但是，在整个编码过程中出现了其他代码。例如，我们有一个“维护者角色” 代码来综合表示「维护者如何描述他们的角色」，以及一个“性别偏见”代码来代表在 OSS 社区中经历过不同待遇的女性维护者。通过不断比较代码 ，我们将它们分组为更高级别表示的类别。该编码过程由一位研究人员进行，并不断与另一位研究人员讨论。

B.Conceptual Framework

我们设计开发了一个概念框架（CF）来描述属性之间的关系，从而帮助我们回答 RQ2。 概念框架的灵感来自 Leite 等人设计的框架。

概念框架的设计涉及三个阶段：1) 概念识别，2) CF 设计，3) CF 细化。在这些阶段，我们再次查看我们的数据，特别是寻找代码之间的潜在关系。

• Concepts identification：

在采访中，我们要求受访者解释「为什么提到的属性对她很重要」。受访者对特定属性的理解就是我们所说的“概念”。为了找到这些概念，我们重新审视了维护者对特定属性的解释，特别注意从解释中提取主要思想。

• Conceptual Framework development：

确定概念后，我们使用在线工具来设计概念框架。在分析概念时，我们寻找它们之间的关系，我们在这一步中进一步探索。在图形表示中，属性用粗体大写文本表示，而概念用较小的大写文本表示。当一位受访者在描述一个属性时提到多个概念时，就会发生关系。例如，P29 （Person 29，即第 29 位受访者）提到维护者必须“愿意指导和帮助贡献者并具有同理心，有效的沟通将帮助他们成为更好的导师“。在本声明中，我们提取了与Community building 相关的概念，即指导和帮助贡献者，Empathy，即具有同理心，Communication，即有效的沟通，以及Leadership，即成为更好的导师。我们使用箭头来说明关系，并使用粗体蓝色文本来描述提到这些概念的参与者。图 1 举例说明了我们的概念框架。

• CF refinement ：

我们为每个类别创建了一个概念框架（总共四个）。一位作者创建了每个概念框架的第一个版本。在审查框架时，我们试图达到一个粒度级别，即不太粗粒度以致读者无法获得任何新见解，也不太细粒度以致读者可能对类似概念感到困惑。例如，在 Social 概念框架的第一个版本中，我们将“鼓励贡献者”和“激励贡献者”合并为一个概念。三位作者合作修改了每个框架。每个细化过程需要 2 个小时。

C.Survery with Contributors

1)Survey Design（问卷设计）:

我们通过征得参与者的同意开始了我们的调查，解释了研究的目标、参与的团队及其志愿者性质。我们问了一些群体特征问题（标准的问题有，性别、年龄、种族、地址、教育、婚姻状态）。下一部分是要求参与者对访谈中确定的属性的子集的重要性进行评级。我们认为，让参与者对所有 22 个属性进行排名会给他们带来沉重的负担，这可能会导致访谈者在调查问卷的时候中途退出。相反，我们把重点放在了对每个类别最常见的三个属性进行排名。

每个参与者都根据不对称的比例对12个属性进行了评级，其中包括以下选项：1)必要的，2)值得的，3)不重要的，4)不明智的，5)我不知道的。Begel 和 Zimmermann 的工作中也采用了这个比例，它是基于Kano等人定义的比例。这种不对称的比例在客户满意度的背景下区分了必须的(基本的)、有吸引力的(有价值的)和不希望的(不明智的)质量。

除了群体特征问题外，所有其他问题都是必答题。一个简短的描述介绍了与属性相关的问题。这一描述提供了该属性的定义和代表性引用(来自采访)。通过对所有属性都遵循这一点，受访者将很快理解并回答它们。该问卷可作为补充材料获得。为了说明，图 2 展示了一个关于 Vision 属性的问题示例。

2) Survey Conduction（问卷执行）：

在正式开始调查之前，我们进行了一次试点，以确定问卷的最终问题并简化对问题的理解。我们邀请了八人（三名软件工程博士生和五名软件工程博士）回答问卷并提供反馈（五人回答了试点调查）。他们的回答和反馈帮助我们使一些问题更加清晰。例如，一位研究人员建议在性别问题中加入“不想说”选项。我们对答案进行了时间限制，发现它们平均需要五分钟。我们在邀请参与者填写问卷时建议这次。
我们在分析中没有考虑试点答案。我们在分析中没有考虑试点的答案。

我们的调查问卷不仅限于 OSS 维护者；欢迎任何过去为 OSS 做出过贡献的人参与。我们的理由是，由于 OSS 贡献者必须与维护者交互以评估他们的补丁，这些交互可能会影响贡献者对如何成为优秀维护者的看法。 例如，在其他地方指出，当贡献者没有收到建设性的反馈时，他们变得不太可能再次贡献。我们没有向 GitHub 用户发送未经请求的电子邮件，这种做法被认为是“比垃圾邮件更糟糕”，而是采用了多步骤的招募方法。首先，我们邀请了参与采访的 33 位维护者来回答我们的问卷。我们写了一篇博客文章，请他们在自己的私人网络上分享。其次，我们在Twitter、Facebook和LinkedIn等社交网络上发布了博文(在一个拥有26,000名成员的群组中)。我们还在r/opensource(一个拥有 121k 会员的Reddit群组)上进行了付费广告宣传。在7天的时间里，我们收到了21次点击，并支付了19.56美元。我们检查了点击的时间戳和答案，估计没有Reddit用户填写问卷，所以我们在一周内关闭了活动。最后，我们与我们的网络联系人(约40名OSS开发者)分享了调查结果，并请他们将调查结果转发给其他同事。

我们应用了一些原则，试图增加调查的参与率。我们采用了社会公益原则，通过捐赠100美元给一个OSS项目(如果我们收到超过100个答案)，被调查者可以投票选择捐给哪一个 OSS 项目。我们运用了权威性和可信度原则，介绍自己为名牌大学的教授和研究员。简洁性原则是通过尽可能多地提出封闭和直接的问题来实现的。四周后，我们以90个答案结束了调查。这些答案来自除澳大利亚以外的所有大陆。我们收到了17名女性、3名非二元性别和70名男性的回答。就 OSS 开发经验而言，20人有0到2年的经验，21人在3到5年之间，17人在6到8年之间，10人在9到10年之间，22人报告了10年以上的经验。受访者为许多备受瞩目的开源软件项目做出了贡献，包括Linux内核、Debian、TensorFlow、GCC、GNOME、OpenStack和Kubernetes。

3) Survey Analysis（问卷分析）：

基于用于对属性进行评级的量表，我们使用了三个指标来分析调查结果。这些指标以前用于 Begel 和 Zimmermann 的研究。通过在指标的定义中进行二分类，我们避免将调查结果中的有序数据转换为数值数据。

第一个指标旨在捕获(大多数)调查受访者认为最重要的属性。它是给定属性的所有响应中认为”必要“的百分比：

$\%Essential=100\times \frac{Essential}{Essential+Worthwhile+Unimportant+Unwise}$

第二个指标反映了受访者对这些属性的总体良好倾向。它计算认为每个属性都是重要或有价值的受访者的百分比：

$\%Good=100\times \frac{Essential+Worthwhile}{Essential+Worthwhile+Unimportant+Unwise}$

第三个指标考察了受访者认为不太重要甚至是负面的最低等级属性。它计算认为每个属性不重要或不明智的受访者的百分比：

$\%Nogood=100\times \frac{Unimportant+Unwisw}{Essential+Worthwhile+Unimportant+Unwise}$

我们根据指标的值对属性进行排名。我们还试图辨别受访者在OSS开发方面的经验是否与他们认为某个属性是必要的有关。我们根据经验(9年以上的开放源码软件经验)和没有经验(0-5年)将受访者分为两类。我们的理由是，经验可能会给贡献者带来不同的感知，从而影响他们对属性的看法。我们也考虑过分析性别是否与将属性评级为必要属性有关，但没有这样做，因为女性和非二元性别受访者的数量很少。

为了了解「受访者的经历」和「一个属性被评为基本属性」之间的关联强度，我们计算了优势比（注：优势比是指某种推测为真的概率与某种推测为假的概率的比值。比如下雨的概率为0.25，不下雨的概率为0.75。0.25与0.75的比值可以约分为1比3。因此，我们可以说今天将会下雨的优势比为1:3(或者今天不会下雨的概率比为3:1)—参考链接）。优势比确定在特定暴露条件下(本文指「被调查者的经验水平」)结果发生的几率(本文指「一个属性被认为是基本属性」)。在报告优势比时，我们还报告95%置信水平的置信区间。我们只报告置信区间小于2的结果。

三、优秀的开源维护者拥有哪些属性

我们的定性编码程序允许我们将172个属性归纳为四类，如表二所示。对于每个属性，我们提供其定义和代表性引用。我们的参与者被称为P1–P33。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UyEly9n0-1648885219716)(https://raw.githubusercontent.com/zhicheng-ning/Pic-Go/main/md/image-20220331192525727.png)]

A.Management

这一类别指的是有助于管理OSS项目的属性，从理解项目愿景、建立和传达项目目标、提出时间表、管理文档质量等方面来说。 在下文中，我们将重点介绍三个管理属性：

• Availability（可用性/有空）

此属性指的是回答问题或向补丁建议提供反馈的响应时间。这是该类别中最常被提及的属性（33个人中有15个人引用）。P9 提到“当一个人可以帮助另一个人，支持那些新手，避免他们走错方向和浪费时间时，Avaibility 是有用的”。维护者可能希望更快地提供反馈，避免过长的等待时间，这可能会阻碍贡献，如 P20 所述：“长时间的响应会产生不满”。

• Discipline（规章纪律）

训练有素的维护者确保流程和指导方针得到遵守。我们发现有 6 个人提到了这个属性。P23 报告称，维护者可能“有一个明确的时间表，知道该做什么以避免任务处于打开状态”，然而 P25 指出，“为贡献者定义任务是建立他们对项目承担义务的一种策略。”

• Vision（愿景）

对项目未来要实现的目标有一个全局的看法，这可能有助于维护者定义优先级。四名参与者提到了这一属性，比如 P1，他们认为：“需要与利益相关者密切合作，制定长期愿景”。

B.Social

在这个类别中，我们将把维护者如何与其他贡献者打交道相关的属性进行分组，这些贡献者可能说不同的语言或这可能不知道如何开始贡献。

• Communication（交流）

33 位受访者中有 18 位提到了「Communication」是一种以明智的方式交换信息的能力。社区拥有良好的沟通渠道在几个方面都很重要。例如，P9 说“在项目发生任何重大变化后，寻求外部反馈是很重要的”。此外，P3还强调“与其他维护者进行良好的沟通非常重要”。

• Empathy（共情）

通过分享他人的问题，维护者可以更好地与具有不同背景的贡献者相处。在报告此事的16名受访者中，P2 报告称，重要的是“非常小心地对待你的写作和说话方式，这样你就不会看起来咄咄逼人或不礼貌”。P15 补充说，我们应该讨论想法，而不是判断是谁提出的。

• Community building（社区建设）

9 位受访者提到，建立协作文化很重要。这包括帮助新手加入社区，并激励现有的贡献者完成他们的任务。正如P7所说：“没有什么问题比创造一个欢迎新成员的环境对该项目的未来更重要了。“ P25 提到，“一些维护者忘记了许多贡献者都是志愿者，如果一个人已经对代码的某个部分做出了贡献，为什么不让这个人在其他部分做出贡献呢？这激励了贡献者。“

C.Technical

这是关于用于运行OSS项目的技术能力(例如，修复错误或添加新功能)。这一类别只有三个属性，我们接下来将讨论这三个属性。

• Technical excellence（技术卓越）

在33名受访者中，有24人提到了这一点，这是提到最多的属性。P19用挑衅的口吻总结了这一属性：“如果你没有很高的技术知识，你该如何要求贡献者做有质量的事情？”。然而，技术上的卓越超越了编码活动；P2报告说，维护者还应该执行代码审查，以发现错误并提供反馈。P32报告说，技术卓越是维护员“应该定期寻找的东西；技术知识越多，就越容易做出决定”。

• Quality assurance（质量保证）

成为「质量把关人」—— 当潜在缺陷出现时提高门槛，并在缺陷不会从代码库中消失时保持关闭——这也是优秀维护者的重要属性。P3将此属性总结为:“维护者负责确保一切工作正常，也就是说，确保1)pull request 遵循贡献准则，2)测试通过，3)他们没有‘破坏’任何东西，所以他们不会发布一个不合格的版本。维护人员应确保这一过程被正确地执行。”此属性不仅与测试和代码审查有关。P31强调，良好的文档也是一个强有力的质量指标。

• Domain experience（领域经验）

具有领域经验可能有助于维护者理解代码库中的特性。P12 报告说“了解问题领域让我更投入到项目中”，这在某种程度上与“自己抓痒痒”的原理是一致的。

D. Personality

当维护者在与社区的互动中表达他们的想法、感受和行为时，他们指的是个性方面。人格特征如下：

• Motivation（积极性）

这与鼓励维护者热情地做事情的因素有关，正如P17所提到的，“热情在于相信项目的人，也相信有能力改变事情，让事情运转起来，有一种感觉，他们可以用微小的变化改变世界“。正如P19所解释的那样，积极进取是一切事情的基础：“如果你参与得很好，你也会感染社区中的其他人，并创造一种感觉，即我们在一个社区里，我们正在一起做一些事情。”

• Open minded（思想开放）

这是关于对新想法持开放态度。P1指出，“维护者需要在社区中具有创新性。创新者有一个开放的心态，必须放下自我，重新成为学徒……。敞开心扉，讨论你认为是‘真理’的事情，听取与你不同的意见“。P17提到，维护人员可能希望接受各种各样的想法、论点和信息：“这主要是关于某人提出了一些你以前没有考虑过的建议时，与其进行防御和试图批评，不如认为这个人正在试图帮助你“。

• Patience（耐心）

接受延迟而不生气。根据 P20 的说法，“耐心使 [维护者] 能够评估情况，了解需要什么，并等待他们建立采取适当和有效行动的能力”。P27 补充说：“耐心使项目的未来变得清晰；它可以让维护者更清楚地看到问题的根源。”

四、这些属性如何相互关联

图3 列出了所有类别的概念框架（一共四种类别，也就是说有四个概念框架）。每个概念框架都有一个核心概念，用黄色突出显示。核心概念是与至少三个不同属性相关的概念。我们还用粗体加下划线突出显示出现在多个类别中的概念。（概念和属性之间多对多的关系）

A. Management

图3(a)说明了 「Management」 类别的概念框架及其属性：纪律、项目管理、可用性、文档、透明度、可持续性和愿景。我们确定了18个概念以及它们与我们的属性的关系（注：每一个概念就是「一段几个单词的描述」）。

「Sustain a long term vision of the project」 被确定为核心概念，七名参与者在描述四个属性时提到了这一概念：纪律、项目管理、愿景和可持续性。这个概念帮助维护者找到并建立项目目标，这也可能是未来行动的动机。在谈到纪律时，P11 说“有时有人接手项目，他们说‘我看到这各功能没有，所以我花了整整一周时间来开发它’；大多数时候，这不在项目范围内。这是 OSS 项目中需要强调的一点。我们很容易做出不相关的贡献；这是一个社区而不是客户端，这个人认为他们可以做他们想做的事。这样会很容易失去注意力”。另一方面，在项目管理的背景下，根据 P6 的说法，“预先设定期望很重要。例如，该项目对 10 年后的期望是什么？范围会变吗？会不会有很大的变化？”

接下来介绍另一个反复出现的概念：「Define a roadmap」。三位参与者在描述纪律和项目管理时提到了这一点。定义路线图被认为对管理期望和组织目标非常重要，这样项目才能在范围内发展。在这个意义上，P23 报告说，“有一个明确的时间表，知道做什么不让任务保持打开状态”。后来，同一位参与者提到，维护者需要“确定路线图，确定哪些事是可以做的，哪些事是可以逐步做的，哪些事是可以演进的”。

在另一个概念 「Delegate tasks」 中，两位参与者在描述纪律和项目管理时提到了这一概念。P23和P25报告说，维护者不应该集中任务，而应该将它们委派出去。这提高了团队的生产力，并且计划的任务更有可能完成。从规章纪律的角度来看，授权委派与贡献者对项目的承诺有关。P25 解释说：“维护者不应该做贡献者的工作。这在社区健康方面非常糟糕。位贡献者定义任务是建立在他们对项目的承诺的一种策略“。

六位参与者在介绍透明度和文档这个两个属性时提到了 「Take care of the docs 」。关于促进项目透明度的文件，P6 提到，“如果你想让人们为你的项目工作，你需要非常透明地了解项目是什么，…如果项目是为一家公司服务的，那么该公司是什么，如果该公司支持该项目。这些事情必须被适当地记录下来“。在更一般的意义上，P28 说“维护者要求贡献者保持项目文档的更新非常重要；这有助于传播项目”。

要管理所有这些需求，重要的是 「balance work and life 」，这是一个与项目管理和可用性相关的概念。在可用性方面，P21提到“你应该知道如何利用你的闲暇时间，用你的奉献精神来保持你希望看到的东西仍然有效，并根据你的生活计划来计划它，这样你就不会把项目抛在后面”。在将个人生活与项目活动协调一致的同时，P2 表示维护者需要确定优先事项，与贡献者组织议程，灵活地安排项目的日期和时间。

Relationalship 1

关系1：为了维持项目的长期愿景，维护者最终应该定义路线图，委派任务，并处理文档。在以志愿者为基础的工作中，必须仔细考虑这些活动，以免影响工作和生活的平衡。

B. Social

图3(b)说明了 「Social」 类别的概念框架及其属性、同理心、领导力、沟通、教育学、社区建设和人际关系。根据我们的分析，我们发现了 17 个概念。在这些概念中，我们观察到了这一类别中的三个核心概念。

「Extremely careful/polite」 是七位参与者在描述同理心、沟通、领导力、教育学和社区建设时提到的最常见的核心概念。在同理心方面，P13 认为“你发表技术性的评论是非常必要的，但你可以用一种更友好的方式来发表评论，始终友善并使用适当的语言，而不是使用任何咄咄逼人的交流方式”。P25 建议，要成为优秀的维护者，“我总是非常小心的；我应该先感谢他们的贡献，然后再做出考虑”。P3 提出，礼貌也有助于建立一个社区，因为“有人发送代码，有人想要贡献，所以 [维护者] 需要注意修改代码，以教导传授最佳方法。该项目可以从这些贡献中变得更好。”

「Encourage contributors」 和 「Mentor new contributors 」 也是核心概念。虽然它们听起来很相似，但也有不同之处。鼓励贡献者是指授权贡献者完成任务并参与其他活动。作为一种社区建设策略，P15 建议给予积极贡献者 commit 权利，因为这将进一步激励他们，培养合作文化。在教育学的背景下，P24 表示一些维护者仔细解释了如何改进补丁，而不是直接拒绝这个补丁：“他们仔细解释，以鼓励未来的改进”。一个等级层次更少、权力更分散的社区增加了每个人的参与度，激励贡献者参与到项目中来。P15 表示 “更多的协作，更多的创造，更少的等级制度。鼓励贡献者，你会看到他们更投入。这会产生对项目的情感承诺“。不同于 「Encourage contributors」， 「Mentor new contributors」 引导和帮助参与项目的新人。在指导新的贡献者时，P23 报告说，将合适的任务委派给新贡献者作为社区建设战略是很重要的。

其他反复出现的概念包括：「Think from their point of view 」，「Build confidence 」和「Willingness to listen/talk 」。根据 P1 的说法，重要的是“当你有同理心时，你就有能力从他们的角度思考，理解和体验他们所经历的痛苦”。在领导力方面，P21分享说她“对这种‘评论’有点创伤，这种评论是「自认为是对的，并且不愿意理解别人的意见」。对我来说，知道自己犯了一个错误并理解不同的观点是非常重要的。这是我能为我的生活带来的东西”。在“建立信心”的背景下，P4 提到，要建立良好的关系，必须承认“如果一个人已经在软件社区工作过，他们具有一定的信誉，但我们只有在建立信任时才能确定” 。因此，有必要想方设法加强团队成员之间的联系，建立信任。最后，“愿意倾听/交谈”是指找时间和某人坐在一起聊天。P16说：“直接沟通有助于社区环境人性化。”

Relationalship 2

关系2：极其细心/礼貌似乎是鼓励和指导新贡献者的基石。为了建立信心，维护者应该愿意倾听和交谈，这反过来又会让他们从另一个人的角度思考。

C. Technical

图3(c)说明了 「Technical」 类别的概念框架及其属性：技术卓越、质量保证和领域经验。「High technical knowledge to support decision-making 」 被确定为核心概念，六名参与者在介绍质量保证、领域经验和卓越技术这些属性时提到了这一概念。在技术卓越的背景下，P18说：“重要的是，维护者在技术上很好地了解这个主题，以帮助开发人员。技术能力必须比掌握计算机科学学科的能力全面得多“。此外，P31还提到“测试和文档是质量的标志，开源软件必须为社区的质量提供这一点”。

五位参与者提到了 「Follow projects quality standards」 ，描述了 质量保证和技术卓越。维护者需要遵循这些标准来为配置和项目管理制定路线图。在描述技术卓越时，P19 说：“…如果你没有技术质量，就很难保持项目的质量。如果你对项目技术没有很高的知识水平，你怎么能要求贡献者做高质量的事情呢？”。在描述质量保证时，P3提到“[维护者]必须确保贡献者遵循标准。自动化测试能够通过，其贡献并不是在‘破坏’代码“。

这个类别的第三个概念是 「Know the application domain 」。它描述了理解应用程序的领域也很重要。P18 说“维护者不仅要在技术上发展，而且要在项目领域发展，他们必须越来越多地主导软件业务。”

Relationalship 3

关系3：为了拥有支持决策的高技术知识，维护员应该了解应用领域，了解项目的技术，并具有实施质量过程的经验，以执行代码审查并遵循项目质量标准

D. Personality

图3(d)说明了 「Personality」 类别的概念框架，以及它的属性：耐心、动力、责任心、思想开放、勤奋和自信。在描述耐心、动力和思想开放这三种不同的属性时，六位与会者提到了 「Foster open innovation」 这一核心概念。在动力的背景下，P19 描述了维护者“必须参与进来，它激励了社区中的其他人，并创造了一种我们在一个社区里，我们正在一起做一些事情的感觉…而这个项目的增长取决于不同的想法“。在同样的意义上，但谈到思想开放时，P27说，“维护者必须有更开放和创新的思想……。维护者的思维方式不应该是片面的‘绝对真理’。”

最后，P7 提到，维护者可以创造一个友好的环境，表明产品可以在社交环境中提供帮助。这些行为可能会产生一些观点，包括让人们成为某事的一部分。于是， 「Promote social inclusion」 这一概念应运而生。从 P17 的引述中可以看出这一点，“…热情存在于相信项目的人身上，他们也相信有能力改变事物，让事物发挥作用，感觉自己可以通过微小的变化来改变世界”。

Relationalship 4

关系4：为了促进开放式创新，保持对项目目标的关注，并在社区中建立真理，维护人员应该突出奉献精神，具有长期合作的坚持性，并确保一个没有敌意的环境。。

E. Intra- (and inter-) relationships

这里发现的概念和关系是(我们所说的)类别内的，因为它们连接相同类别内的属性。然而，我们也发现了类别间的关系：当概念连接不同类别之间的属性时。我们观察到具有此特征的三个概念，在图3中以灰色突出显示。**「Perform good code review」的概念是最全面的一个：它是所有四个类别的一部分：「Social」、「Management」、「Technical」和「Personality」。横跨两个类别的另外两个概念是「Find consensus」和「mentor new contributors 」，这两个概念出现在「Management」和「Social」**类别中。由于我们不能在本文中提出所有概念框架，我们将这些关系的整体观察留到未来的工作中。

五、贡献者如何看待这些属性的重要性

表III列出了我们根据调查答复计算出的三个指标的值（问卷分析部分的三个指标）。我们首先检查每个属性的 %Essential 指标，该指标突出显示高于其他属性的属性，即使我们的受访者提到了所有这些属性。对于这个指标，我们有一个明显的赢家：「Communication」 。76.67%的受访者认为这一属性至关重要，认为“不重要”或“不明智”的没有一票。得票率第二高的属性是 「Quality Assurance」 (57.78%)，其次是 「Community Building」 (50.00%)。

所有属性的 %Good指标 均显示出较高的值。我们观察到的此指标的最低百分比为 82.95%，属于 「Domain Experience」 属性。Worthwhile 评级作为基准，因为所有属性不仅在采访中被提及，而且是最常被引用的 12 个属性。%Good的高值的必然结果是， %NoGood 指标的百分比始终很低。%NoGood值最高的属性是 「Domain Experience」 (17.05%),「Motivation」(14.44%), 「Availability」（11.24%），「Discipline」 (11.24%) 和「Vision」 (10.23%) 。「Availability」属性是%Essential的最低值。这个是 %Essential 和 %NoGood 之间差异最小的属性；前者比后者高2.2倍。

我们计算优势比，以量化「受访者经验」和「某个属性被评为必要属性」之间的关联的强度。对于 「Patience」 来说，优势比是0.232，例如，没有经验的受访者认为此属性是必要的可能性是有经验的受访者的4.3倍。95% 置信水平的置信区间为 (0.083,0.645) 的，p 值为 0.005。该置信区间表明，在 95% 的置信度下，没有经验的受访者认为此属性是必要的可能性是有经验的受访者的 1.55 到 12.05 倍之间(1/1.55=0.645，1/12.05=0.0829)。应用 邦费罗尼校正（注：如果在同一数据集上同时检验n个独立的假设，那么用于每一假设的统计显著水平，应为仅检验一个假设时的显著水平的1/n），即将目标显著性水平 0.05 除以 12（我们执行的统计检验次数），我们得到显著性水平 0.004167。由于 p 值等于 0.005126且大于 0.004167，因此我们无法确定统计显著性。对于 「Communication」 来说，优势比是0.533，也就是说，一个没有经验的受访者认为它很重要的可能性几乎是前者的两倍。在 95% 的置信水平下，置信区间为 (0.182, 1.562)，尽管 p 值不表示统计显著性。这两个属性的优势比表明，经验不足的开发人员认为其他项目贡献者更需要沟通和耐心。这通过定量数据强化了 Relationalship 2（第 IV-B 节）。

另一方面，对于 「Motivation」和「Domain Experience」 属性，优势比分别为 2.154 和 1.75。根据我们收到的回复，该证据意味着有经验的受访者认为「Motivation」必不可少的可能性是没有经验的受访者的两倍多，而认为「Domain Experience」必不可少的可能性大约是 1.75 倍。置信区间为 (0.828, 5.599) 和 (0.660, 4.639)，强化了这一结果，尽管无法确定统计显著性。

我们采用 弗里德曼检验 来确定 12 种属性中的任何一种是否一直被受访者评为高于其他属性。Friedman检验有用性的经典例子是品酒。N 个葡萄酒评委每人评价 K 种不同的葡萄酒。在这 K 种葡萄酒中，是否有哪一种的排名始终高于或低于其他葡萄酒？”。这项测试得到的p值为 0.000475，这表明有一些属性的评级始终高于其他属性。为了进一步研究这一问题，我们采用了Pothoc Friedman-Nemenyi检验。对于每一对可能的属性，这项测试验证是否可能拒绝「受访者对这两个属性进行类似评级」的零假设。此测试显示，在应用Bonferroni 修正后，「Communication」的评级高于其他11个属性中的7个。如表四所示（由于将每个属性与其他11个属性进行比较，因此目标显著水平为0.004545）。此外， 「Quality Assurance」 是第二大值为%Essential的属性，其评级始终高于「Availability」(p值=0.001602)。

（注：表四是「Communication」属性的Post-HOC FRIEDMAN-NEMENYO 检验结果。p 值低于 0.004545 的属性表明它拒绝 零假设 , 这个假设指「Communication」与其他属性的评级相似）

六、局限性

在定性工作中对「结果有效性」的威胁与「数据分类的主观性」有关。为了缓解这种威胁，我们使用了多种方法。每个定性分析步骤都有不止一名研究人员进行；当有疑问时，其他研究人员也会加入讨论。在这一过程中进行的这些讨论旨在通过相互商定来验证这些解释。在对采访记录进行编码时，我们也使用了持续比较技术，将我们的发现与数据分析得出的以前的结果进行比较。

定性工作的另一个潜在威胁是结果的饱和度或全面性。为了确保我们获取到代表优秀维护者的一组全面的属性，我们采访了33位经验丰富的OSS维护者，他们在位置、性别、年限经验和领域方面都是不同的。我们一直在采访参与者，直到连续五次采访都找不到任何新属性。尽管如此，参与者的数量似乎足以理解任何文化领域或生活经验研究的核心属性。

最后，我们的大多数受访者都在基础设施 OSS (例如，操作系统、浏览器、编程语言)上工作。我们的发现可能不适用于在非关键环境(例如，琐碎的JavaScript库[1])上工作的维护者。为了减少这种威胁，我们确保采访了较小项目的维护者。然而，在进行采访时，我们可以确定几个负责多个项目的维护者，包括较小/不太显眼的项目。在我们的采访中，我们要求他们报告他们参与的任何项目的经验。

七、相关工作

软件工程研究人员调查了能够成为优秀软件开发人员、维护人员和软件项目经理的属性。1995 年，Turley 和 Bieman [33] 报告了 38 种能力，这些能力表征了软件开发人员所需的技能。他们表明，除了技术技能之外，优秀的软件开发人员还具有人际关系和个性特征，这会使他们获得更好的表现。Li等人[17]揭示了一组伟大工程师的54个特质。他们发现，软件工程师的卓越与“编写好的代码”有关，但也与寻找未来的价值和成本、实践明智的决策和持续学习有关。

Kalliamvakou等人特别关注微软的经理们。[13]他们发现，尽管技术技能是相关的，但对于工程经理来说，这并不是优秀的标志。主要特点是保持一个积极的环境、促进人才成长和软件工程自主权。人际属性再次成为基本特征。然而，我们可能会注意到，OSS维护者的属性在社区建设和可持续性方面存在垃圾信息，这超出了公司的要求。同样地，我们的结果表明，优秀的维护者需要拥有一组超越技术技能(如软件工程师)的属性。我们通过展示维护者需要有一把特殊的“瑞士军刀”来处理OSS的具体要点来扩展这一点，包括社区建设和项目的可持续性。

更广泛地说，关于OSS垃圾邮件的研究来自于什么激励贡献者[34]，什么吸引和阻碍新来者[27，2]，如何成为核心贡献者[38，19]，导师面临的挑战[2]，以及职业道路[32]。这些努力有助于了解开源软件贡献者的活动。然而，它们几乎不涉及维护人员的工作，正如我们所展示的，维护人员不仅负责管理人员和项目，就像在传统的软件项目中那样，而且还负责确保社区得到良好维护，并且项目是可持续的

与这项工作密切相关的是，Wang等人。[35]调查了精英开发人员执行的活动–那些“在项目中拥有明确定义的项目管理特权”的人。通过分析存储库数据，他们发现这些开发人员管理社区任务，并行协调工作，并与多个利益相关者讨论这些任务。尽管作者发现了这些精英开发人员执行的一组任务，但不清楚他们是否是维护者，以及使这些开发人员出色地执行工作的属性。因此，我们理解，我们的工作带来了对Wang等人[35]的补充观点。

尽管如此，Gousious和他的同事之前的工作侧重于理解贡献者[10]和集成者[11]对基于 pull 的开发模型的看法[9]。Gousios et al.[11]发现，当评审贡献时，集成人员关注于质量保证，贡献的优先级包括紧迫感和贡献的大小。社交方面被认为是处理pull request的挑战。
我们的工作是对Gousios工作的补充，我们不仅关注集成商，还展示了优秀维护者应该具备的特征。我们可以看到，虽然质量保证和社交方面是一个共同的主题，但我们展示了一个优秀的维护者的集合特征是更广泛的，并包括不仅仅与代码集成相关的属性。最后，Nadia Eghbal[8]分析了OSS维护，并提出了维护OSS项目的一些“隐藏成本”(例如，物理基础设施、用户支持和社区管理)。她提到，维护者有责任“注意他们如何分配自己的注意力”，因为他们的努力是有限的资源。Eghbal的讨论围绕着这里揭示的Management和Social类别展开，这两个类别表明，维护人员需要管理项目的多个方面，以保持贡献者、社区和项目以相同的频率工作。

八、结论

维护者无疑是社区成功和长期可持续发展的核心工作人员。 这些贡献者的职责包括一系列不同的职责，这些职责需要不同的能力。虽然可以将维护者视为负责保持高质量代码的唯一技术开发人员，但我们的结果表明，优秀的维护者必须掌握多种技能。

事实上，我们发现「沟通」被认为是优秀维护者最重要的属性，根据 %Essential 指标，「质量保证」排在第二位。统计分析已经证实了这一点，该统计分析涉及属性收到的评级之间的成对比较。组成前五名中的三个属性与技术能力(「社区建设」、「同理心」和「远见」)无关。因此，很明显，尽管维护者通常是技术水平很高的贡献者，但社交和管理技能是在这一职位上脱颖而出的关键。

鸣谢

我们感谢审稿人提供的有用意见，以及我们研究的参与者提供的意见。这项工作得到了CNPq , National Science Foundation, FACEPE/Brazil, and INES 2.0 的部分支持。