开源生态系统中项目与开发者推荐

赵海燕，李 娜，陈庆奎，曹 健

1(上海市现代光学系统重点实验室，光学仪器与系统教育部工程研究中心，上海理工大学光电信息与计算机工程学院，上海 200093)

2(上海交通大学 计算机科学与技术系，上海 200030)

1 引 言

在开源生态系统中，相互依赖的软件项目形成了协同发展的社区[1].开源社区的蓬勃发展吸引了数量众多的高水平开发人员.这些来自不同国家、不同文化与专业知识背景的开发者自愿加入社区，并与其他开发者建立合作关系[2]，共同推进项目的开发.

尽管开源社区发展迅速，但是由于开源社区公开、自愿、非盈利等原则，也出现了诸多问题：1)很多项目因未能及时找到合适的开发者而处于停滞状态；2)开发者也不能准确找到自己感兴趣并能够胜任的项目；3)95%以上的开发者只参与了不超过5个项目，大量的人力处于空闲状态.上述情况之所以存在，一方面是由于开发者无法通过现有的项目检索方法找到真正匹配自己技能的项目；另一方面是由于项目负责人没能掌握社区开发者的兴趣、专业特长以及开发者的合作偏好.

目前，可用于开发者及项目推荐的信息来源有用户(users)、项目(projects)、项目成员(project members)、追随者(followers)、提交(commit)、评论(comments)、问题(issues)、拉取请求(pull request)等.项目中的成员相互合作，并进行一系列操作对项目进行贡献.图1展示了开发者之间的合作关系以及进行推荐的几种可能性，其中成员之间直线连接表示曾有过合作关系.

图1 开源社区中项目与开发者的关系

由于开源社区存在众多的项目及开发者，且其兴趣是动态变化的，因此想要精准地为开发者推荐项目，或者为项目推荐合适的开发者是相当困难的[3].在此背景下，开源生态系统中的项目与开发者推荐具有非常重大的意义.

推荐算法是近年来的热门研究领域，将推荐算法应用于开源生态系统中，也引起了研究者的广泛兴趣.有些推荐系统的典型方法已经被用于项目及开发者推荐，如，基于内容的推荐、基于协同过滤与内容的混合推荐、基于社交网络的推荐等.许多研究者在通用的推荐系统模型基础上，加以针对性的改进，使得其推荐模型具有更好的性能.

为了对开源生态中的项目与开发者推荐进行更为合理的评估并分析其未来的研究方向，本论文首先总结了开源项目中项目、开发者的特性，在此基础上，分别对项目推荐、开发者推荐进行了介绍，最后，文章对未来的研究方向进行了讨论.

2 开源项目中的项目与成员特性

2.1 项目特征

在开源项目中，无论进行项目推荐或是开发者推荐，项目特征与开发者特征都是相互依赖的.项目(projects)中包含的信息有项目id、url、创建者id、项目名称、项目描述、语言、创建时间等.自述文件主要是开发者对一个项目的实现目标及实现过程进行描述.社区中的成员可以通过检索关键字搜索自己感兴趣的项目加入或者进行代码重用.此外，开源项目还有其他的属性，如stars、pull request、issues以及项目的已有成员的信息.其中：

1)stars指一个项目的的关注者个数，它代表了一个项目的流行程度.

2)Pull Request用于开发者之间的协作，比如，开发者想要为一个项目进行贡献，可以先fork这个仓库，相当于拷贝一份，再克隆到本地分支，然后对项目进行缺陷修复或增加一些功能，贡献完成后，则可以发起一个Pull Request，即请求另一个开发者(比如项目的维护者)进行代码审查，若代码合格，则拉取这份分支仓库.发起Pull Request时，需提供4个信息(源仓库、源分支、目的仓库、目的分支).

3)Issues中包含了在项目开发过程中产生的所有缺陷、缺陷提出者、缺陷指派者、缺陷状态.每个issues有独一无二的编号以便对这些缺陷状态进行跟踪.

2.2 开发者特征

开源社区用户众多，任何人都可能成为开源项目的贡献者.在分析开发者的特征时，需结合项目特征，挖掘出开发者的兴趣点和擅长的项目类型.

社区中的用户(users)均有个人id、姓名、所属公司、所属国家及地区.开发者在社区中的所有行为均会被记录，这些行为包括提交、评论、追随其他用户等.

提交(commit)包括bug提交、bug评论提交、pull request评论提交.每一个提交也会有特定id，提交者id、项目id以及提交时间也会被记录，这有利于挖掘开发者的个人兴趣.评论(comments)与提交相同，也分为问题评论、提交评论、pull request评论.评论id、评论者id、评论内容、评论时间等一系列细节被详细记录，这些信息在一定程度上能够衡量开发者所擅长的东西.

追随者(followers)这一特征中记录用户id及其追随者id，这一指标反映出开源社区中的领导力，那些活跃且技能突出的人会拥有更多追随者.

由于开发者会不断学习新的东西，其兴趣会随着时间而有所变化，因此开发者的特征比较难衡量.

2.3 开发者与项目的关系

对开源社区中，开源项目和开发者的关系是非常复杂的[4].进行项目及开发者推荐首先需要理解针对一个开源项目什么样的成员能够符合要求.因此，以下对开发者与开源项目的关系进行了总结.

近年来，随着开源社区的发展，许多研究者从不同的角度探索开源社区开发者的参与动机和他们之间协调合作的机理等[5]，但是缺乏一个系统的总结.我们对相关的研究工作进行了梳理，见表1，它包括开发者加入/离开项目的原因、开发者合作关系对参与项目的影响、开发者在开源项目中的能力衡量.

表1 开发者与项目的关系

2.3.1 开发者加入/离开项目时考虑的因素

开发者的积极参与及长期贡献是一个项目成功的必要前提，了解开发者加入项目的动机、行为具有重要价值.文献[6，7]探究了社区中开发者的参与动机，这些动机均与项目相关，包括金钱、荣誉等等.项目有利于个人发展在所有动机中排名最高.

项目开发从来都不是单打独斗，因此开发者加入项目时还会考虑项目的团队成员.文献[8，9]研究了社会意识的提高和工作的透明度如何影响开发者参与开源项目这一问题，文献[10]探讨了开发者协作网络如何影响开发者对开源项目的选择.研究表明，若一个项目中有他之前合作过的人员，则该开发者更倾向于加入该项目.开发者在过去的工作中表现优秀会被优先推荐加入项目，同时，项目中成员的素质、声望会影响开发者是否加入项目.项目开发离不开沟通交流，开发者自身缺乏互动会影响项目的正常推进[11].

开发者加入项目除了考虑项目、团队成员两个因素外，还考虑个人的因素，开发者自身专业知识是否不足是开发者加入项目时必须考虑的因素[12].

众多文献研究了开发者加入项目的动机，相对而言，开发者离开项目的原因的研究还没有得到足够的重视.文献[13，14]使用反向滚雪球的方法，定义了开发者在开源项目中的生命周期，通过识别开发者的“休眠”状态(即暂时离开)、“死亡”状态(即永久离开)来探索开发人员退出项目的原因.开发者的个人私事[13]、职业的变动以及开发兴趣的改变[14]均会导致开发者中途退场，导致个人在项目中的不稳定参与.同时，项目开发过程中，开发者收到消极的反馈会使其丧失参与项目开发的信心及动力，很有可能会导致开发人员离开社区.与项目其他成员存在分歧，开发者之间意见不统一对于开发者参与项目的积极性起到负面影响[15].

2.3.2 开发者合作关系对开源项目的影响

沟通质量以及合作效果被认为是开源项目成功的决定因素之一.探究开发者之间的合作情况，也有利于为开源项目推荐较为合适的开发人员.

1)开源项目中的合作关系

开发者之间通过合作关系构成了一个社交网络.社交网络可以用许多指标进行度量，例如，其密度是网络中形成的连接数与网络中所有节点连接总数的比例[16].文献[17]通过研究GitHub上开源项目的协作模式pull request，开发了一种基于有向图的社交网络，并分析项目成员之间的等级制度、生产力、受欢迎程度、弹性和稳定性.研究表明，成员的社交网络特征与项目的成功之间存在相关性，例如，开源项目的参与者越多，则项目效果越好.这些分析为如何有效进行协作软件开发提供了见解.

在开源项目中，团队合作大多都是暂时性的.文献[18]在GitHub上挖掘能够跨项目的社交连接(CRSC)团队，研究了团队的合作是否能扩展到不同的项目.作者使用复杂网络分析法研究这些团队的结构，研究发现，拥有持久社会联系的开发团队，成员之间的合作更加稳定，且会在多个项目上相互合作.

文献[19]研究了开发者的加入率和退出率、任务分配率和任务完成率、现有开发者在不同项目间的活动以及新成员的加入率.

研究发现，成功的开源项目中的开发人员具有专注的特征，且少数核心开发人员贡献了大部分代码，这部分人对软件集成的质量起着重要的作用.

2)开源项目中合作关系的特点

开源社区社区成员和合作随时间不断地变化，分析网络中新加入开发者的合作偏好行为有利于了解社区开发者网络结构的动态变化与合作趋势的走向.

社会网络结构具有封闭性、中介性和中心性等特征，研究发现，有影响力的人会影响其他开发人员，开发者倾向于与有影响力的人相互合作.识别中心度高的开发者，挖掘、利用隐含于网络中的知识，并依靠中心位置开发者者的声望和权力的影响、支配作用，可以达到快速知识共享的目的.

github上的协作开发主要通过拉取请求来完成，拉取请求审核过程的效率取决于技术(如代码质量)和社会(如贡献者与项目维护者的关系)等因素.为了确定社会因素对项目开发效率的影响因子，文献[20]研究了基于拉取请求的开发人员组成的团队结构.核心贡献者和开发人员之间更紧密的交互与更快的响应对拉取请求的处理至关重要.研究发现，中小型项目开发的特点是少数核心贡献者保持反复的交互，并且能够更有效地处理传入的请求.文献[21]利用社会网络分析(SNA)探讨开源项目中开发者的协作行为，将SNA技术用于识别那些在其他社区成员中扮演中心者角色的成员，发现技术出色的开发者建立的合作会更稳固、更高效.也有研究表明，开发者拥有相同的兴趣、目标，会使开发过程更顺畅[22].

除了开发者自身的硬实力之外，其人际交往能力、沟通能力、性格等因素会对项目开发产生或多或少的影响.一个成熟的项目开发团队对开发流程更熟悉，平台更广，开发者通常会优先选择与其合作[23].

2.3.3 开发者在项目中的能力衡量

开源项目中，开发者在项目中的表现行为和担任的角色是不同的，他们的活动推动着项目的发展[24].通过对开发者的贡献方式以及个人能力进行衡量，能够帮助我们了解、挖掘不同开发者的技能专长，从而合理地进行开发者推荐.针对开发者在过去项目中的表现，可以将开发者能力的衡量分为技能评估和社区影响力评估.

1)技能评估

技能评估主要根据代码行或功能点来衡量开发者对软件项目开发的贡献.软件开发人员主要通过编写代码、提交源文件、发表评论以及执行缺陷修复来参与项目.除了源代码之外，技能评估还包含开发人员活动轨迹的分析，这对开发者推荐过程非常重要.

软件开发过程中仍然缺乏技术来评估开发人员在流行的库和框架中的专业技能.文献[25]收集了关于开发人员在GitHub项目上活动的13个特性，包括对源代码文件的提交.通过评估了无监督学习(基于聚类)和有监督学习(随机森林和SVM)分类器的性能，以识别3个流行的JavaScript库中的专家，最后提出了一种基于GitHub聚类特征数据的专家识别方法.文献[26]为了对GitHub的贡献进行评估，提出CoreDevRec模型用于推荐核心成员.CoreDevRec使用支持向量机分析不同事件类型的特征，包括修改代码的文件路径、贡献者与核心成员之间的关系以及核心成员的活动性.研究者评估了GitHub中5个流行项目的18651个pull请求，结果表明，CoreDevRec在前3名推荐中的准确率为72.9%-93.5%.

一般认为，在开源项目中，贡献者本身的技术价值是非常重要的.随着开发人员和代码操作之间的关系变得可见，我们可以从中推断出开发者重要但隐藏的特性.例如，在决定是否接受一名开发者贡献之前，项目经理可以查看新成员之前参与的所有项目，并将其作为开发人员技能的信号进行评估.对这些信息的分析为评估开发人员在开源软件项目中的潜在贡献提供了证据.

2)社区影响力评估

在开源社区中，一个开发人员的活动和兴趣很容易被其他开发人员注意到.研究表明，开发人员使用这些信息对其他开发人员和项目进行推断.

对Github用户社交互动的数据进行分析可以揭示许多有趣的特征.文献[27]通过分析基于follow、star的活动数据，从普遍性、中心性、代码价值、贡献和活动等方面来衡量用户在Github开发者社交网络中的影响力.研究表明，开发者的跟随者数量对其社交影响力有较为突出的权重.

文献[28]通过对GitHub中社交编码网络结构的进行研究，从GitHub收集了10万个项目和3万个开发人员，构建了开发人员-开发人员和项目-项目关系图，并计算了图的各种特性，然后使用PageRank来识别GitHub这个子网络上有影响力的开发人员和项目.研究表明，在图上距核心开发者的社交距离越近，做出贡献的可能性越大.而在文献[29]中指出，开发者在线活跃的时长也是其为开源社区做出贡献的指标.

3 开源生态中的项目与开发者推荐

推荐系统的主要目的是为用户推荐感兴趣的信息、产品或对象.开源平台为开发人员提供了学习和积累经验的巨大机会.为了促进开源项目的成功和开源软件的演化，项目与开发者之间的相互匹配是非常重要的.在开源社区中，我们能够获取到大量的开发者信息、项目信息以及开发者合作信息.利用这些信息能够为开源项目推荐合适的开发者，也能为开发者推荐自己感兴趣的项目.

为开发者推荐项目，其核心是开发者，需要在掌握开发者的偏好的基础上，帮他来筛选其可能感兴趣的项目.为项目推荐开发者，其出发点是项目的需求，一方面需要根据项目的需要找到那些能够为项目做贡献的开发者，另一方面，也需要这些开发者确实对该项目具有一定的兴趣.因此，两者的共同之处在于开发者需要对此项目感兴趣，愿意参加该项目，而不同之处在于，为项目推荐开发者需要更多的考虑项目中所欠缺的人员.

本节对现有的研究工作进行了分类、归纳，将开源社区推荐模型分为项目推荐、开发者推荐，并对目前深度学习在此问题上的应用进行单独的总结.

3.1 为开发者推荐项目

在开源社区中，超过50%的源代码文件被重用[30].开发人员会搜索感兴趣的项目，以便重用其功能或者为其做出贡献.加入不合适的项目不仅无助于个人的发展，也无助于开源项目本身的发展.因此，为开发者进行主动的项目推荐非常有必要.然而，由于项目数量极其庞大，而开发者的需求许多时候又是隐性的，因此，为开发者进行项目推荐具有一定的挑战性.

3.1.1 直接推荐相似项目的方法

为开发者推荐项目的直接想法就是为他推荐与他参与过的项目相似的项目.因此，这成为了不少方法的出发点.

为了克服一些研究只使用了有限的信息，或者使用了项目中不可用的信息的问题，文献[31]分析了两个未在以前的工作中考虑到的数据源(即项目stars和自述文件)，基于3种启发式规则提出了一种能够有效地检测GitHub上相似项目的方法.这3种规则是：在短时间内由相同用户开始的项目可能彼此相似，由相似用户参与的项目可能彼此相似，自述文件包含类似内容的项目可能彼此相似.作者分别计算其相关性得分并进行整合，构建了一个名为RepoPal的推荐系统来检测相似的项目.与文献[31]的方法相近的是文献[32]中提出的方法.文献[32]创建了一种新的自动检测相关项目的方法，使用java api帮助用户检测给定Java项目的相似项目.他们在8000多个Java应用程序上进行了评估，发现他们的方法比以前提出的技术具有更高的精度.

文献[33]提出一种基于协同过滤的推荐技术来为GitHub用户生成个性化的存储库推荐.用户可将其作为新项目的灵感、特定项目的代替方案或自我学习.文章首先依据是否给存储库评分，将用户划分为两个群体，然后针对不同群体进行算法测试.测试结果表明，给存储库评分的用户做推荐是准确率更高.

文献[34]使用朴素贝叶斯模型，根据项目的描述信息利用文本分类来预测开发人员可能加入的项目：首先，将候选开发者过去参与的项目打上标签作为训练集，放入朴素贝叶斯分类器进行训练，然后通过该分类器将待参与的项目进行分类，分类结果为正例的即为开发者推荐的项目，该方法在实验数据集上的推荐准确率约为30%.文献[35]在文献[34]的基础之上，提出了一种半监督文本分类方法，这种方法将开发人员与他们过去参与项目的对应关系看作是训练集，并将朴素贝叶斯与期望最大化相结合，提高了推荐的性能.研究者利用Bugzilla数据集在Eclipse环境下进行了评估，结果表明，使用监督的朴素贝叶斯分类器的分类精度为11%-43%，与之相比，使用半监督方法的分类精度提高了6%.

3.1.2 基于开发者行为获取开发者对项目的兴趣的方法

为了能够给开发者推荐其感兴趣的项目，需要获取开发者的兴趣.然而，开发者的兴趣往往并不进行显式表达.而用户行为数据可以反映开发人员对软件开发活动的偏好和兴趣.开源社区提供了各种功能来促进开源项目的发展，如stars、fork和pull请求.当使用这些功能时，会记录大量的用户行为数据.

文献[36]设计了一种基于用户行为数据的方法，向开发人员推荐相关的开源项目.还有众多文献以开发者行为作为切入点[37-39]，它们不仅考虑用户行为，还考虑项目特性，从而挖掘开发人员的兴趣和经验，从每个项目的描述文档和源代码中提取开发人员行为和特征，为GitHub的开发者自动推荐前N个个性化的软件项目.不同之处在于，文献[37]集成了用户反馈，并使用SA算法自动优化参数配置，以提高推荐的准确性.最后通过对GitHub抓取的数据进行实证研究，结果表明，该方法能够以较高的精度向开发人员推荐相关的软件项目.文献[38，39]提出的REPERST模型是用MapReduce并行处理框架Apache Spark实现的，它可以扩展到大量的用户和项目中进行实际使用.

文献[40]通过构建开发者协作图的方式进行网络分析，并提出了一个使用链接预测的推荐系统.其数据来源于GHTorrent网站上公开的GitHub事件.作者选择前1000个提交数最多的原始项目(即未从另一个项目仓库派生出来，且仍处于活动状态)和所有为这些顶级项目仓库做出贡献的用户.贡献包括提交和合并请求.文献[41]指出，将开发者的各种特征和项目语义关系灵活地结合，对于OSS生态系统中的相似性计算是非常有益的.作者提出CROSSSIM模型，使用图表示法将开发人员社区与OSS项目、库和各种构件以及它们之间的交互作为一个整体来考虑，从而计算开源项目的相似性.

以上文献均通过对Github中选定的数据集进行实验来探索这种方法的可能性.从用户行为数据中挖掘项目相关性是一个很有前途的方向.

3.1.3 考虑开发者之间的关系

对于一个开发者，如果一个项目中存在具有一定联系的其他开发者，则该项目也具有一定的吸引性[42].因此，一些方法中把开发者关系也进行了利用.如文献[43]提出一种预测开发人员的兴趣向他们推荐项目的新方法RepoLike：一方面，探索开发人员的历史开发活动和与其他开发者的社会联系，另一方面，挖掘项目的技术特性和它们之间的依赖关系，然后将这两个方面结合起来向开发人员推荐项目.

3.2 为项目推荐开发者

开源项目有赖于开发者的积极参与，因此需要为项目确定潜在的开发者.

进行开发者推荐需要深入研究开发者的兴趣、社交关系等.为项目推荐开发者的特殊之处在于我们不仅需要考虑他们是否有兴趣，而且需要考虑他们能否胜任这个项目的要求，甚至需要针对项目的不同任务的要求进行更有针对性的推荐.

3.2.1 从相似项目中获取开发者的推荐方法

为了推荐开发者，一个直观的想法就是去寻找类似的项目，那些项目中的开发者应该对本项目具有兴趣，也具有相应的能力.

每一个开源项目都有其特征，例如项目语言、项目背景等.对这些项目的特征进行分类、建模，可以帮助开发者更快的选择自己感兴趣的项目.

文献[44]提出了一种基于特征匹配的跨域开发者推荐算法.首先，研究者寻找与当前目标项目主题最相似的历史项目.然后检索了这些项目的开发人员.最后，我们将目标项目的主题与检索的开发人员进行匹配，筛选出最相似的开发人员，以组成当前任务的推荐开发人员集.为了验证所提算法的有效性，作者将该模型与各种先进的开发人员推荐算法进行比较.实验结果表明，该算法在不同的评价指标上具有优于以往算法的优势.

文献[45]提出了一种新的方法DevRec来自动推荐开发人员.该方法基于两种分析：基于项目的分析和基于开发人员的分析.基于项目的分析通过k近邻搜索与新项目相似的老项目，为新项目推荐参与过老项目的开发者；在基于开发者的分析中，对开发人员以及之前参与过的项目进行建模，计算开发者与新项目之间的术语、主题、组件和产品关联度.将基于项目和基于开发者分析的分数线性组合，得到最终的DevRec模型分数.

文献[46]提出了一种基于主题模型的开发者推荐算法DRETOM(Developer Recommendation based on Topic Models).该方法选择了潜在主题分布(LDA)从历史项目中提取主题.它可以帮助我们分析开源社区中的新项目属于哪些主题.如果开发人员参与的历史项目与新项目属于同一主题，我们可以认定开发人员对此项目主题感兴趣.基于从历史项目中构建的主题模型来模拟开发人员对错误解决活动的兴趣和专业知识.在Eclipse JDT和Mozilla Firefox项目上的实验结果表明，DRETOM在推荐的前5名和前7名开发者中的召回率分别达到82%和50%.

从相似项目中去寻找开发者的方法虽然比较直观，但是一个开发者留在某一个项目中不仅是因为该项目的技术特性，还受到了社交关系等的影响.因此需要考虑开发者的关系.另一方面，开发者在参与项目中的行为、关系等体现了其积极度和能力的差异，在开发者推荐时我们需要尽量推荐那些态度积极、能力高的开发者.

3.2.2 基于合作关系进行开发者推荐

在开源软件社区中，项目是通过开发者之间的动态协作来完成的.利用开发者的社交关系进行推荐有两个意义，一方面人们愿意和协作过的开发者继续协作；另一方面，通过合作关系也可以判断哪些开发者在社区中具有重要的地位.

研究者利用开发者协作图上的随机游走模型探究了开发者之间的协作关系，该模型又被称为开发者协作网络[47-49].开发者协作网络是使用以下规则构造的：若两名开发者都参与了同一项目，则在协作网络中他们之间有一个链接，在同一个项目中工作的两个开发人员被认为具有共同的兴趣和技能.

文献[47]指出对于同一种数据资源中蕴含的协作关系，具有不同的建立图模型的方式，应当结合具体问题探讨协作图的边的方向性、权重的赋值方式等问题.文献[48]提出了一种基于k近邻搜索的开发人员推荐方法DREX.DREX首先搜索k个与新项目类似的历史项目文档，并检索出为这些历史项目做出贡献的开发人员；其次，DREX在这些开发者的协作图上定义了中心度指标来对开发者节点进行度量；然后根据历史项目中的参与记录，采用度中心度、中间中心度和接近中心度3个指标对开发人员的技能进行排名.实验结果表明，当为250个测试项目分别推荐10名开发人员时，DREX比传统的多标签文本分类方法具有更好的性能.

文献[49]通过构建开发者协作图，然后将带有重启动的随机游走模型建立在协作图之上，完成开发者的全局性排名，实验结果表明利用该方法能够识别社区中高贡献度的开发者.在协作图中，顶点的入度越大，说明该开发者接收到其他开发者传递给他的任务越多，意味着该开发者解决问题的能力越强，越有知名度.

基于协作网络进行推荐利用了开发人员、项目之间的复杂的关系.但是，该方法中缺乏对开发人员的技能的显式 建模，可能造成重复推荐同一类人员.

3.2.3 基于专业知识的开发者推荐

在开源软件项目开发中，越来越需要找到具有相关专业知识的开发人员.现有的开发者推荐系统大多依据更改代码数量多少来衡量开发人员的能力.虽然该方法已经取得成功，但想要更精准的进行开发者推荐需要分析开源项目的大量开发历史记录.

在文献[50]中，引入了开发者专业知识的概念，它通过开发人员的特定行为对其专业知识进行建模，如功能函数的使用及使用次数、代码提交的频率等.研究结果证明，利用专业知识作为开发者推荐的主要依据能有效提高推荐准确度.文献[51]同样对开发人员的专业知识进行了建模，提出了基于模糊集的自动推荐技术.该自动推荐技术将不同的专业知识与其对应的模糊集合结合起来，以找到最有能力的开发者.研究结果表明，利用模糊集表示专业知识进行推荐比现有的方法具有更高的精度和时间效率.

文献[52]提出了专业技能指标和机能衰退指标来评估开发者交互数据中的专业技能，指出开发者的专业技能水平是在时间上定义的，专业技能强的开发者与完成任务所需的时间应该呈负相关，任务完成时间越久，开发者的专业技能会随之衰退.作者首先计算开发者在代码源文件上的原始专业技能度量，然后将专业技能值标准化为开发者在专业知识总和上的专业知识比率，从而使专业技能值介于0和1之间.在计算了开发人员在单个代码源文件的专业知识后，需要对开发人员的综合技能水平进行计算：用开发者的专业技能指标减去机能衰退指标后，再除以代码源文件的数量，最后对每项技能进行加权平均，其中权重是某项技能在项目中出现的次数，这样就得到了开发者的综合技能评估指标得分.研究显示，开发者的综合技能指标得分越高，说明该开发人员专业技能越强，能够胜任项目开发的可能性越大.

3.2.4 针对特定任务的推荐

进一步，一些研究考虑了针对项目中的特定任务进行开发者推荐，例如，对bug报告修复者进行推荐[53，54]、对Pull请求的评审者进行推荐[55，56]、为项目推荐测试人员[57，58].

为了帮助开发人员解决bug报告，已经提出了各种自动化技术来识别和推荐开发人员处理新bug.目前有两类bug指派人推荐技术，且都是单独研究的，包括基于开发者先前活动的推荐，以及根据bug的位置推荐合适的开发人员.文献[53]提出了一个统一的模型，它将来自开发人员先前活动的信息和可疑程序位置的信息以相似特征的形式组合在一起.对来自eclipsejdt、eclipseswt和ArgoUML项目的11000多个bug报告进行了评估，实验表明该模型优于先前的研究.文献[54]中将主题模型和开发人员关系(如bug报告者和指派者)结合起来，捕捉开发人员对特定bug报告的兴趣和经验，从而推荐最合适的开发人员来修复bug.研究者使用3个大型开源项目(Eclipse、mozillafirefox和Netbeans)来评估该方法的性能.实验结果表明，该方法推荐的准确性优于其他推荐方法.

Pull Request(PR)是开源项目外部开发人员的主要贡献方式.PR评审是开源软件开发中保证项目质量的重要环节.推荐合适的PR评审员，可以提高PR评审的效率.然而，GitHub没有一个自动推荐PR的机制.文献[55]提出了一种自动推荐核心评审员的方法，它将PR主题模型与社交网络中的开发者相结合.通过潜在Dirichlet分配从PR中提取PR主题，然后利用协作者和PR之间的连接构建协作者-PR网络，并计算每个协作者的影响.最后依据PR评审的历史行为建立PR主题与协作者之间的关系.当一个新的PR出现时，根据协作者的影响力以及新PR与合作者之间的关系，选择一个合作者作为核心评审者.实验结果表明，该方法推荐精度优于70%.为了支持评审员推荐，文献[56]提出了一种自适应的评审员排名模型来对一个请求中的所有评审员候选人进行排序.排名模型利用多种特性来衡量拉取请求和评审者候选人之间的关系.利用学习排序技术，根据先前解决的拉取请求，自动训练排序模型的权重参数.其特征选择实验表明，最重要的特征是统计请求者发送并由开发人员审阅的先前pull请求的数量.另一个重要特性是度量在拉取请求中，更改的文件与开发人员先前修改的文件之间的文件路径相似性.

在项目开发过程中，由于缺乏有效的众包测试员推荐方法，任务发布者往往直接从大量的申请者中选择测试者.以此方式选择的测试人员往往不能完成预期任务，因此为测试用例自动化推荐测试人员很有必要.目前，将推荐系统应用于软件测试阶段的人并不多.为了使推荐的测试人员与任务相匹配，文献[57]提出了一种基于Top-K的测试员推荐算法.为了降低Top-K算法的时间复杂度，引入了类别.通过对测试任务进行分类并计算各类别与测试员的匹配得分得到最适合该类别的测试员.在计算测试人员和特定类别的任务之间的相似性后，从选定的类别中推荐前K名最适合该任务的测试人员.实验表明，提出的Top-K-Worker算法可以大大提高测试人员与推荐任务的匹配度.文献[58]开发了一个推荐系统，将测试用例分配给测试人员.该系统是使用Eclipse集成开发环境在Python中开发的.它提供了两个好处，首先，它可以帮助测试经理更快地分配测试用例.其次，它可以向新的测试经理提供关于测试用例和测试人员详细信息(包括以前分配的历史记录).测试任务与测试人员的匹配度决定了测试的效率和质量，针对测试人员的推荐是软件工程中重要的一步.

由于不同的任务具有不同的特性，挖掘开发者在特定任务背景下的特征并对其能力进行衡量是比较困难的.因此，针对特定任务进行开发者推荐是一个值得研究的方向.

3.3 基于深度学习的项目与开发者推荐

在项目推荐与开发者推荐的过程中，需要将项目信息及开发者信息映射到另一个维度，即将现实世界中的信息转换成计算机和数学公式能够处理的形式.深度学习神经网络表示法能够很好的抽取词与词之间的关系，应用最广泛的就是卷积神经网络提取和神经网络提取.随着深度学习应用的推广，近年来，一些学者尝试了基于深度学习模型的项目与开发者推荐方法.

基于卷积神经网络的推荐算法可缓解传统推荐算法中面临的冷启动问题和数据稀疏性问题，并提升推荐系统的性能.卷积神经网络在开发者推荐系统中有着广泛的应用[59-61].

文献[59]提出了一个从开发者的评论中学习项目属性和用户行为的深度模型.该模型由两个并行神经网络组成，称为深度合作神经网络(DeepCoNN).其中一个网络利用用户编写的评论来学习用户偏好行为，另一个网络则从该项目的评论中学习项目属性，并在顶部引入一个共享层，将这两个网络连接在一起.实验结果表明，该模型具有较好的推荐性能.

当数据集稀疏时，难以有效挖掘历史项目中蕴含的信息，因此，文献[60]提出了推荐模型ConvMF，该模型将卷积神经网络(CNN)集成到概率矩阵分解(PMF)中，能够精准捕捉项目文档的上下文信息，进一步提高预测的准确性，因此，即使数据极其稀少，ConvMF也能较好地预测和推荐.

文献[61]提出了一个学习排序模型NNLRank(用于列表排序的神经网络)来推荐开发人员可能贡献的项目.NNLRank利用项目特性和开发人员的经验来推荐项目，并利用了一个列表式损失函数，该函数旨在最小化预测项目列表和开发人员首选的基本真实列表之间的差异.实验结果表明，NNLRank能够为开发者提供有效、高效的入职推荐，大大优于以往的模型.

循环神经网络也被用于开发者推荐中以捕获开发者的兴趣变化.文献[62]提出了一个统一的句子表示和文本分类模型C-LSTM，该模型结合了CNN和RNN两种架构的优点.利用CNN提取项目文档中的关键词，并贴上标签，然后将其输入到LSTM中，得到开发者的技能专长特征.实验结果表明，C-LSTM的性能优于普通的CNN和LSTM，在开发者推荐的任务中取得了较好的性能.

深度学习模型在其他推荐领域的应用已经成为一个技术热点，然而，该类模型在项目和开发者推荐中的应用还不普遍，因此，还具有很大的发展空间.

4 数据集和评价指标

4.1 数据集

目前，GitHub是最流行的源代码存储和共享平台，它组织来自世界各地的开发者进行代码贡献.这一平台提供一个 官方REST API，允许通过HTTP请求访问存储在该平台的项目信息，这有助于Github在软件工程研究中的广泛应用.由于近年来研究者对Github产生了广泛的研究兴趣，一些从该平台收集数据的其他平台被建立，如Github archive和GHTorrent.这些平台从Github收集数据，可对其进行更深入的分析.

Github Rest API(1)https://developer.github.com/v3/可以对托管项目的数据进行访问，是研究者获取Github数据最流行的方式.这个API提供了有关存储库、用户、问题、拉取请求、评论信息等数据，并以JSON格式返回结果.

Github archive(2)https://www.gharchive.org/是为收集GitHub数据而创建的一个平台，因此用户可以轻松地检索和使用这些数据.该系统每小时收集一次Github事件，并可由HTTP客户端下载.尽管GitHub Archive不提供关于存储库和用户的直接数据，但它们可以通过Git事件获得.

GHTorrent(3)https://ghtorrent.org/平台提供GitHub数据的脱机镜像，通过收集事件来检索该镜像.数据以结构化和非结构化格式存储，结构化数据存储在MySQL中，原始事件数据存储在MongoDB中.

除了以Github(4)https://github.com/社区为研究对象获取数据之外，研究者还以其他开源社区为研究对象获取数据，如Sourceforge(5)https://sourceforge.net/、Rubyforge(6)https://rubygems.org/等获取项目及开发者信息.

4.2 评价指标

为了衡量开源软件社区推荐算法的有效性，研究者们使用了流行的评估指标，包括Top-N准确率(Top-N Accuracy)、平均精度均值(MAP)、平均倒排序值(MRR)等.

1)Top-N准确率(Top-N Accuracy)

推荐的准确率是指推荐给结果中符合要求的结果所占的比例.一般来说，推荐结果前若干项的准确性比较重要，因此，需要Top-N准确率这一指标来度量前几个结果的推荐精度.Top-N准确率表示其对应的真实项目(开发者)处于推荐列表前N名的概率，如果真实项目(开发者)在前N名，说明推荐效果好，反之推荐效果差.计算Top-N准确率如公式(1)所示：

(1)

上式中Nq为推荐项目(开发者)的总数，|Instancesuccess|为推荐成功的项目(开发者)个数.

2)平均精度均值(MAP)

MAP评价指标主要用于衡量推荐结果排序的好坏程度，它考虑了推荐结果中所有真实项目(开发者)的具体排名，排名越靠前，MAP值越高.假设需要向N个开发者推荐项目(N个待开发项目推荐开发者)，在计算MAP之前，需要先计算每个开发者(开发项目)的平均精度(AP)，AP值计算如公式(2)所示：

AP=predictioni×(change in recall)i

(2)

predictioni表示前i个推荐结果的正确率；(changeinrecall)i为二值项：当第i个推荐结果正确时，值为1/N；否则为0.

MAP是所有开发者(开发项目)的AP的平均值，其计算如公式(3)所示：

(3)

3)平均倒排序值(MRR)

MRR是指将准确推荐项在推荐系统给出结果的排序位置的倒数作为它的准确度，再对所有的问题求平均.MRR是对推荐结果进行评价的常用指标之一，它的定义如公式(4)所示：

(4)

上式中，Nq表示数据集中开发者(项目)的个数，Ri表示第i个开发者(项目)得到正确的推荐结果中第一次出现的排名位置，如果开发者(项目)的推荐结果中没有出现正确答案则取0.根据上式的定义，可以看出MRR的值越大说明推荐效果越好.

5 研究展望

5.1 挑战

当前软件开发活动分工高度细化，不同的项目需要不同的开发者，而开发者又需要加入适合自己的项目，因此对开发者更细致的特点进行评价和度量很有必要.研究人员需要从软件资源中提取能够反映开发者细粒度技能的证据，并在此基础上进行建模.然而，目前还缺乏对开发者技能进行详细建模的框架和方法.

现有的研究中，研究者们大多只针对单一的开源社区中数据进行项目及开发者推荐.目前流行的开源社区还有很多.一方面，这些社区的数据格式、类型定义、数据规模具有不一致性，另一方面，不同社区的信息是不同步的，因此整合信息时可能出现冲突.此外，开发者活动记录散布在多个社区之中，要想从多社区中全面挖掘开发者的活动规律及个人专长具有极大的挑战.

现有的开源生态相关推荐算法，特别是机器学习算法通过拟合开发者过去参与项目中的数据获得其兴趣.然而，开发中过去参加的项目并不一定就是他最感兴趣的，由于开发者的注意力有限，有可能有些项目被他所忽略，所以他参加的项目只是在他有限的范围内的一个选择，过度拟合过去的项目可能难以反映开发者的真正偏好.

另外，开源社区中可能会出现新型项目，例如新的编程语言，新的应用类型等，由于这些项目中缺乏历史数据，这将对开发者推荐带来更大的挑战.

5.2 未来研究方向

从上面的讨论可以看到，目前对于开源生态的相关推荐仍存在着诸多挑战.在未来必将会有更多、更广泛的尝试，可能的研究方向包括但不限于：

1)基于开发者全面画像的推荐：正如我们在第2节中所分析，开发者参与项目的意愿以及其在项目中的表现和贡献涉及到众多的因素，现有的推荐算法考虑得不够全面.在未来研究中，可以进一步扩展考虑的因素，对开发者进行全面的刻画，从而能够进行更有针对性的推荐.另一方面，开发者的兴趣爱好是发生变化的.在开源社区中，不同的开发者参与开源社区的动机是不同的，因此，需要从不同开发者的动机出发，对其当前的兴趣爱好进行预测，从而能够推荐其感兴趣的项目.

2)由于有过合作经验的开发者彼此更加熟悉，在开发过程中的开发效率更高.目前的开发者推荐都是考虑个体开发的推荐问题.我们可以在开源社区中挖掘已经经过配合的开发团队，从而能够为一个项目推荐配合默契的团队.

3)面向特定任务的推荐：现有的开发者推荐面向的是整个项目，然而项目中需要不同角色的配合.我们在某些场景下可能需要针对项目中的某一模块，甚至某一Pull请求的评审来寻找特定的开发者.面向特定任务的推荐涉及到对任务的详细描述和对开发者技能的进一步刻画.

4)进一步应用深度学习的最新成果.通过利用深度学习模型融合广泛的多源异构数据，能够学习到更加抽象、更加稠密的用户和项目的深层次表示，同时采用深层神经网络结构构建预测模型也能够更好地抓住用户和项目之间交互的非线性结构特征.目前深度学习领域发展非常迅速，各种新的方法、新的模型也不断出现，新的Word嵌入网络、注意力机制，可解释深度学习等都值得应用到该问题中去.

6 总 结

互联网的快速发展使得开源软件社区进入了蓬勃发展的阶段.经过较长时间的发展，开源社区中积累了丰富的数据，这为软件工程领域的研究者认识相关现象与规律、优化软件开发过程奠定了基础.开发者是软件开发中最基本的要素之一.本文先对开发者行为的相关研究进行总结，包括其加入/离开项目时考虑的因素、合作情况、贡献方式以及能力的衡量.然后对开源生态中的项目推荐与开发者推荐方法分别进行总结.最后，本文对研究中面临的挑战和未来的研究方向进行了展望.