开源社区中开发者的commit提交行为挖掘分析

陈丹，何鹏,2

(1.湖北大学计算机与信息工程学院,湖北 武汉 430062;2.湖北大学湖北省教育信息化工程技术研究中心,湖北 武汉 430062)

开源社区中开发者的commit提交行为挖掘分析

陈丹1，何鹏1,2

(1.湖北大学计算机与信息工程学院,湖北 武汉 430062;
2.湖北大学湖北省教育信息化工程技术研究中心,湖北 武汉 430062)

以Github开源社区为研究对象，分析社区中开发者在commit提交过程中的行为，探索开发者之间的交互关系.研究内容包括分析影响开发者提交行为的因素，探析commit的提交者与创作者关系,进一步分析commit的评论者的行为.研究结果发现：1)构建项目团队的成员组织数不宜超过10，但开发者规模可以适当扩大；2)项目commit的提交90%以上都以核心成员为主，未充分调动开源社区中广大爱好者参与的积极性；3)参与一个commit评论的开发者数大多在5人以内，且参与同一个commit评论的开发者多来自不同的项目或组织.

开源社区；提交行为；软件开发；开发者网络

0 引言

随着物联网、云计算等应用技术的日益普及和广泛使用，依托于社区化群体开发的各类虚拟社区开源软件生产组织模式也得到了快速发展，人与人之间的社会关系分析也成为研究热点.开源社区提供丰富的软件自由下载，支持大众参与到社区的开发中，也允许二次开发并按照相应的开源协议进行发布.随着开源软件的流行，人们愈发渴望理解开源社区中的诸多现象，如影响开源软件成功的决定因素[1-2],开发者自愿参与的动机[3-4]，开源社区中影响开源软件扩散的主要动力[5]，开源软件开发者合作机制与合作意识[6]等.开源社区(如Github)作为一类典型的群体软件开发社区，来自不同国家、有着不同背景的开发者通过加入社区与其他开发者互惠合作，强调源代码免费、开放以吸引更多的人成为社区的参与者，积累下来的软件数据与制品将成为社区的共享资源.

开源社区门槛低、源码开放、自由参与等特征，便于大量的软件开发者可以自由加入感兴趣的项目当中去.但同时问题也随之而来，很多开源社区上的开源软件开发效率低下，软件质量得不到保证.Github作为当今最为流行的软件项目托管平台，集版本控制、信息交流、代码分析、团队协作为一体.本文中以GHTorrent提供的Github社区数据(截止到2013年10月)为基础，分析开源社区中开发者的commit提交行为以及影响其提交行为的因素，从而获取开发者的典型提交行为模式.

以下内容的组织结构为：第1部分为相关研究工作的介绍；第2部分为相关理论基础介绍；第3部分是研究方法及实验数据分析；第4部分对于本文的研究结果及不足之处进行讨论；第5部分为全文的总结与工作展望.

1 相关工作

目前为止，开源社区中关于开发者的角色、开发者之间的合作关系产生的动机以及开源软件项目质量的影响因素等的分析已经引起广泛关注，很多文献都对此进行过分析与验证.He等人[7]通过对SourceForge.net社区中开源软件项目进行收集，在项目-管理者二分网络基础上构建管理者合作网络模型，对管理者的度分布进行分析发现网络呈现明显的核心/边缘结构.Robinson等人[8]利用序列挖掘方法对Github上124个项目进行挖掘，得到开发者活动的回归模型，发现行为的变化与情绪变化的相关性.

Wang等人[9]通过分析Tomcat 6各个版本下开发者合作网络中开发者的活跃度演化趋势，提取出典型的角色演化模式，并且对比了不同演化模式下开发者在特定工作类型的贡献程度.Choi等人[4]通过网上调查研究的方式获得的结果表明开发者参与开源软件项目开发的动机(如学习需求、兴趣、与工作经历相关等)的多样化.Huang等人[10]根据开发者提交的日志信息，构建开发者-模块网络来描述开发者之间的交互，并建立LPP边缘学习过程模型用于划分开发团队中成员的角色.Onoue[11]等人通过Github提供的APIs研究每个开发者产生的Github事件发现敏捷的软件项目往往拥有多样化的开发者，且这些开发者往往参与了不同类型的开发活动.

commit提交是开源软件版本控制中的一个非常重要的操作.随着研究者们研究的不断深入，关于开发者commit行为的研究也逐渐涌现，Ma等人[12]调查了软件开发者集体和个人提交commit的时间间隔，发现项目无论在整个生命周期还是每个版本中的commit提交时间间隔均大致满足幂率分布，且大多数连续性commit提交到软件库的时间间隔很短，其中只有少数情况经过长时间等待.Yang[13]定义四个指标来衡量开发者提交行为和代码演化规律，即每次commit的变化、提交commit的时间间隔、每次变化的提交作者和源代码依赖，发现之前版本中对文件的更改可能会影响下一个版本，且修改“huge commit”所需的天数平均是普通commit的3倍.此外，一些研究者也尝试通过commit行为本身的属性去对软件项目进行定量分析.如Hofmann[14]指出在软件项目分析中提交的commit量是衡量对软件贡献度的一个重要指标，并设计算法计算commit的量.

此外，Cavrak[15]等人对分布式软件开发者合作行为模式、动机和角色进行了分析，以便更好地理解分布式项目的开发动态.Gharehyazie[16]等人针对Apache社区中开发者的技术贡献和社会交互行为分析其是否适合作为一个committer角色.Zhou[17]等人对新成员如何在项目问题解决过程中体现自己的贡献，从而提高他们在项目的影响力问题展开开发者行为分析.

综上所述，开源社区中分析开发者个人角色及行为方面的研究层出不穷，但与已有工作不同，本文中将重点关注开源社区中开发者的commit提交行为，探索开发者在项目开发过程中，尤其是commit提交行为过程中不同开发者之间的交互关系.

本研究的贡献主要为:

1) 与已有的文献不同，本文中以整个Github社区中的项目开发者commit行为为切入点，探析开发者commit提交行为的潜在交互规律.

2) 分析影响commit提交行为的一些因素，并进一步探索commit的评论人之间的交互关系.

2 理论基础

2.1 开源社区 开源社区又称开放源代码社区，是一个供广大热爱开源开发的开发者自由学习交流的虚拟平台.本文中选取Github开源社区为研究对象，作为当今最为流行的开源软件项目托管平台，据统计该平台已有超过1 200万用户和超过3 100万个开源项目.Github为每个部署的开源软件建立一个repository库，用于存储各种软件开发数据，如项目成员信息、项目描述信息、项目缺陷修复信息、commit提交信息，以及commit评论信息，等等.

GitHub社区的独特性在于从另外一个项目进行分支的简易性.为一个项目贡献代码非常简单：首先点击项目站点的“fork”的按钮，然后将代码导出并将修改加入到分出的代码库中，最后通过内建的“pull request”机制向项目负责人申请代码合并.因此，有人将GitHub称为代码玩家的MySpace.当文件修改到一定程度时，可以“保存一个代码快照”，在Git中被称为commit.一旦错改或误删了文件，还可从最近的一个commit恢复.

本文的主要目标是挖掘分析Github社区中开发者的commit提交行为，所用到的数据主要涉及数据库中的8张表，分别为users(用户表)、projects(项目表)、project_members(项目成员关系表)、issues(问题基本信息表)、organization_members(组织成员关系表)、commits(提交信息表)、commit_comments(提交-评论关系表)、project_commits(项目-提交关系表).这些表之间的关系如图1所示.

图1 数据表关系图

2.2 开发者提交行为 开源软件开发是一个群体协作的过程，每个爱好者都可自由参与对项目的修改，并提交各自的问题解决方案.提交具体修改内容的开发者即为commit的author，而对诸多author提交的commit进行决策形成最终采纳方案的开发者为committer.在项目的commit中，一些开发者既扮演author的角色又扮演committer的角色，且一个问题常需要多次甚至几十次的修改讨论后才能得到解决.

项目的开发者来自世界各地，他们彼此可能互不相识，一个开源项目的成员可由来自多个组织/团队的人构成.一个项目中来自同一个组织的开发者的公司分布位置也可能不同，因此，项目成员来源的多样性是否对开发者的commit行为具有影响，是一个值得探讨的问题.

2.3 开发者评论行为 社会网络主要研究在一定范围内个体与个体之间的关系，网络中的节点是个体，边则是按一定方式定义的两个人之间的交互关系.在软件开发过程中，常根据存在交互的两个开发者间建立合作连边，构成一个开发者合作网络.开发者对提交的commit内容会进行评论(comment)，利用开发者之间的相互评论关系，可构建一类开发者合作网络.合作网络中节点表示对commit做出评论的开发者，若开发者A对开发者B提交的内容进行了评论，则A与B之间被视为存在一条合作连边.

对于一个项目的commit，对其进行评论的开发者是否主要为该项目的成员，即表现出项目内部相互讨论的局面；还是更多评论来自非本项目的其他开发者，表现为外部群体贡献.另外，从问题解决时间上，一个commit提交后，项目管理员可能还关心大致要多久或者经历几轮讨论方能解决当前问题.研究开发者对commit的评论频率、次数及相邻两次评论的时间间隔，有助于提高社区问题的解决效率.

3 实验分析

3.1 数据 本文的实验数据借助公开的GHTorrent API，获取Github上开源项目开发数据.图1为我们

表1 实验数据统计信息

在数据收集过程中涉及的8张表的关联关系.由于数据量的庞大，为了使研究结果更具有一般性，我们随机选取其中的1 800个项目作为实验对象，其中涉及的总开发者数是1 682个，一个项目成员最多为313个，最少1个，平均具有24.42个开发者；commit数据共 254 774条，对应的comment数据386 754条，详细信息见表1.

3.2 开发者提交行为分析

3.2.1 影响开发者提交行为因素分析 首先，考虑到一个项目的开发成员可能由来自多个组织的开发者所组成，而一个项目中来自不同组织的两个开发者之间交互效果可能比来自同一组织开发者的更差，从而影响开发者commit提交行为.为分析项目开发者的commit提交行为是否受该项目成员的组成关系影响，图2给出了两者之间的关系图，结果显示一个项目的开发者来自的组织越多，所需提交的commit数也越多.结果证实了不同组织的开发者之间交流不如相同组织成员之间高效，致使commit数变多.甚至，当组成项目团队的开发者来自的组织数超过10时，有些项目的commit相比组织数更小的项目的commit数增加了一倍.

另外，我们也进一步分析了项目开发者的commit数与项目issue(issue主要指question、bug、enhancement)数之间的关系.根据图3中给出的项目开发者提交的commit数与项目问题issue数之间的正相关关系，说明开发者的整体commit提交行为越频繁，项目中issue数会越多.换句话说，开发者之间交流不畅在一定程度上会阻碍开发过程中开发者意见达成一致，从而影响项目开发质量.

图2 开发者提交行为与organizations关系

图3 开发者提交行为与issues数关系

图4 开发者提交行为与团队members关系

前面是从项目团队的组织来源进行分析，我们也对社区中开发者的commit提交行为与项目参与成员规模之间的关系进行了分析.图4显示当项目团队规模在26人以内时，项目开发者提交的commit数随项目团队规模增大而增多；然而，当项目团队规模再增大时，开发者提交的commit明显减少.该实验结果表明：开源项目中并不是成员越多，他们之间的交互就越频繁.小规模团队之间交互频繁，大团队可能采取任务分工，因而局部成员之间的交互行为更紧密，这也是为什么规模大的项目开发者平均commit数变小的一个可能原因.

因此，开源软件开发者的commit提交行为与成员的组织来源数和规模大小相关，整体上表现为项目成员的组织来源不宜过于分散，成员的规模可以适当扩大(超过26人).项目管理者可通过吸引更多与已有开发者来自同一个组织的其他开发者参与项目的开发，来提高项目的开发效率与质量.

3.2.2 commit的提交者与创作者关系以及他们在项目中的角色分析 开发过程中，先是开发者生成commit (这类开发者为commit的创作者author)，再提交给具有更高权限的核心开发者或管理员(这类开发者负责把收到的commit提交到软件库中，即为committer).因此，本节我们将重点研究分析commit的author和committer为同一个人和不是同一个人时，他们之间的关系情况.

我们分析了所有收集的commit数据，通过整理分析，发现项目commit的committer和author在大多数情况下是同一个人，其中author和committer是同一个人的commit数占90.2%的比例，而不是同一个人的commit数有54 211条.这说明大多数情况下，从事项目commit提交行为的开发者都是项目的核心开发者，仅有少量具有较低权限的边缘开发者参与其中，这也间接反映了社区中在可供利用的人力资源基础上调动的还不够充分，还未能充分对群体智慧加以利用.

针对54 211条author和committer不是同一人的commit数据，我们按照以上两类角色的开发者是否来自同一个项目和同一个组织进行分类.图5显示这些commit中author和committer来自不同项目的比例占84.5%，author和committer来自不同组织的比例占87.3%，而两人来自于同一项目和同一组织的比例均不超过20%.另外，我们还发现即使两个开发者来自同一个项目或同一个组织，但他们之间有共同参与commit提交的合作者比例也分别仅占0.03%和6.56%(见图6).说明项目commit的author和committer之间往往没有太多交集，但是却能自觉地建立合作.

图5 author与committer来自同项目或同组织的比例

图6 author与committer有共同合作者的比例

由于committer一般为项目的核心开发者，author为外围或边缘开发者.因此，上述结果表明，绝大部分项目依旧还是其主要开发者在进行开发与维护，还没有充分调动开源社区中广大爱好者参与开源项目开发的积极性.

3.3 开发者评论行为 每个项目提交的commit数通常至少上百个不等，而每个commit的评论人数也各不相同，本节我们重点探讨关于项目commit的评论行为.

首先，我们将commit的评论人划分为3类：来自同一个项目(组织)、来自不同的项目(组织)、其他.根据图7发现大部分commits的评论人是来自不同的项目(组织)、极少部分是来自相同项目(组织)的开发者之间交互，只占0.45%(8.26%)；而一个commit中参与评论的开发者既有一部分来自同一个项目(组织)，又有一部分来自不同项目(组织)的情况大约占四分之一.说明目前参与commit评论的人多是彼此之间素不谋面或者相互合作过的开发者.然而，通过对相邻两个评论人之间发表评论的时间间隔分析，图8中我们可以看出大部分commit的评论在一个月内完成，超过一个月的比例仅占19.8%.并且我们对所有commits的评论人数进行统计分析发现大部分的commits的评论人在5个以内，只有少部分的项目commits的评论人超过24个.

图7 commit的评论人同项目或同组织分配比例

图8 commit的评论产生频率

图9 commit评论人构建的开发者网络模型

其次，我们选取commit数为3 411的项目(proj_id=22980)作进一步分析，选取原因是该项目的开发者数适中且其commit数接近所抓取的项目commit数分布的中位数，具有一定的代表性.我们利用网络可视化软件Gephi对该项目下的一个commit(commit_id=124 678)的全部评论人(共123人)建立合作网络模型(见图9).其中节点代表对commit进行评论的评论人，节点之间的边则说明两个开发者之前有过共同评价.由图9可见123个评论人中，合作紧密程度并不大，主要以两个评论人为主，存在大量只是参与此次commit的评论但跟其他评论人没有交互经验的开发者.

实验结果表明：整体上commit的评论人在5个以内，且参与同一个commit评论的评论人大多来自不同的项目或组织，这些人之间有关联的占少数，表现出群体交互还不够紧密.

4 讨论

本文中对开源软件项目开发者的commit提交行为进行了挖掘分析，得出了一些结论，如开发者的commit提交行为受成员的组织来源和规模大小的影响，commit的author和committer通常都是同一个人，评论人之间的联系不够紧密，等等.然而，本文也存在着以下不足之处.

首先，我们选用作实验的数据为2013年10月以前抽取的数据，目前GHTorent项目中数据已更新到2016年，提供的数据表中还包括其他信息，如项目的编程语言、里程碑(milestone)、用户的关注者(watcher)，以及issue的评论等.这些信息目前我们都没有考虑，主要是出于数据量的处理问题，毫无疑问在后期的工作中我们将对这部分信息进行进一步分析利用.

其次，在3.2.1节中分析项目开发者的commits数与成员的组织数之间关系时，图2中横坐标设置为20以内，根据对数据的统计发现，平均每个项目的开发者数不超过25个，且只有少数的项目开发者数比较多，所以我们仅考虑那些开发者来源组织数不超过20的项目是具有一定的代表性的.

目前较为流行的开源社区除Github之外，还有Sourceforge、Rubyforge、Google code等.本文中以Github社区为研究对象，除了因为该社区提供了大量的数据集，其知名度更广也是一个原因.我们选用该社区进行分析，相信我们的结论在其他社区中大体一致.

5 总结与展望

本文中主要围绕开源社区中项目开发者的commit提交行为进行了挖掘分析，分析了影响开发者commit提交的因素、commit的提交者与创作者关系分析，以及commit的评论者之间的交互关系.研究发现：1)开源项目在招募开发者时因考虑成员的组织来源不宜太分散，但规模可以适当扩大；2)大多数项目的commit提交主要来源于少数核心成员的贡献，对社区中广大爱好者的参与积极性调动不够；3)整体上参与commit评论的开发者并不多，且参与同一个commit评论的评论人多来自不同的项目或组织.

我们的工作为开源社区中项目成员的招募与推荐提供了一定的指导依据，但正如前面讨论部分所提到，Github社区中还提供了更多丰富的数据，所以还有很多有价值的工作等待我们去挖掘.在下一步工作中，我们将根据得到的分析结果对开发者提交的commit及时推荐评论者，帮助软件高效开发，提高软件开发质量.

[1] Lee S, Kim H，Gupta S. Measuring open source software success[J].Omega, 2009, 37(2): 426-438.

[2] Crowston K, Annabi H, Howison J. Defining open source software project success[C]//Proceedings of the 24th International Conference on Information System，New York,USA,2003:327-340.

[3] Roberts J, Hann I, Slaughter S.Understanding the motivations, participation, and performance of open source software developers: a longitudinal study of the apache projects[J].Management Science，2006,52(7):984-999.

[4] Choi N, Pruett J.The characteristics and motivations of library open source software developers: an empirical study[J].Library & Information Science Research,2015,37(2):109-117.

[5] Whitmore A, Choi N, Arzrumtsyan A. Open source software: The role of marketing in the diffusion of innovation[J].Information Technology and Control,2015,38(2):91-100.

[6] He P, Li B, Yang X，et al.Research on developer preferential collaboration in open-source software community[J].Computer Science，2015,42(2):161-166.

[7] He P, Li B, Pan W，et al.Centrality analysis of the manager collaboration network in open source community[J].Journal of Chinese Computer Systems,2013,34(1):161-166.

[8] Robinson W,Deng T,Qi Z.Developer behavior and sentiment from data mining open source repositories[C]//49th Hawaii International Conference on System Sciences，Koloa, HI, 2016:3729-3738.

[9] Wang W, Li B, He P. An analysis of the evolution of developers’ role in open-source software community[J].Complex Systems and Complexity Science,2015,12(1):161-166.

[10] Huang S,Liu K. Mining version histories to verify the learning process of legitimate peripheral participants[J].ACM SIGSOFT Software Engineering Notes, 2005,30(4):1-5.

[11] Onoue S, Hata H, Matsumoto K. A study of the characteristics of developers’ activities in github[C]//Software Engineering Conference,2013 20th Asia-Pacific，Bangkok,2013:7-12.

[12] Ma Y, Wu Y, Xu Y.Dynamics of open-source software developer′s commit behavior: an empirical investigation of subversion[C]//Proceedings of the 29th Annual ACM Symposium on Applied Computing，New York, USA, 2014: 1171-1173.

[13] Yang W,Shen B,Xu B.Mining GitHub: why commit stops-exploring the relationship between developer’s commit pattern and file version evolution[C]//Software Engineering Conference (APSEC), 2013 20th Asia-Pacific，Bangkok,2013:165-169.

[14] Hofmann P, Riehle D. Estimating commit sizes efficiently[M].Open source ecosystems: diverse communities interacting，Berlin：Springer Berlin Heidelberg,2009:105-115.

[15] Cavrak I, Orlic M, Crnkovic I. Collaboration patterns in distributed software development projects[C]//Software Engineering (ICSE), 2012 34th International Conference on，Zurich,Switzerland,2012: 1235-1244.

[16] Gharehyazie M, Posnett D, Vasilescu B, et al. Developer initiation and social interactions in OSS: A case study of the Apache Software Foundation[J].Empirical Software Engineering, 2015, 20(5): 1318-1353.

[17] Zhou M, Mockus A. Who will stay in the floss community? modeling participant’s initial behavior[J].Software Engineering, IEEE Transactions on, 2015, 41(1): 82-99.

(责任编辑 江津)

Analysis of developers’commit behaviors in open-source software community

CHEN Dan1, HE Peng1,2

(1.Faculty of Computer Science & Information Engineering,Hubei University,Wuhan 430062,China;
2. Hubei Province Engineering Technology Research Center for Education Informatization(Hubei University),
Wuhan 430062, China)

We takes Github community as the subject, and mainly focuses on developers’ commit behaviors and their interactions during this process. The contents are comprised of analyzing the factors that may affect developers’ behaviors, studying the relationship between commits’ committers and authors, and exploring developers’ comment behaviors. The results show that 1) for an open-source project, the number of organizations its developers belong to should not be more than 10, but the scale of developers can be appropriate to expand. 2) More than 90% contribution to the commits is from mostly central developers, the participation degree of the majority of developers in the community is still not fully motivated. 3) The number of developers involved in the commits’ comment is not more than 5, and they are often from different projects or organizations among the developers.

open-source community; commit behavior; software development; developer network

2016-11-17

国家973重点基础研究发展规划项目(2014CB340401),国家自然科学基金(61273216),湖北省重大科技创新计划(2013AAA020),武汉市青年科技晨光计划(2014070404010232)和湖北大学青年自科基金资助

陈丹(1992-)，女，硕士生；何鹏，通信作者，讲师， E-mail:penghe@hubu.edu.cn

1000-2375(2017)02-0176-07

TP301

A

10.3969/j.issn.1000-2375.2017.02.014