開源社區(qū)中開發(fā)者的commit提交行為挖掘分析

陳丹，何鵬,2

(1.湖北大學(xué)計(jì)算機(jī)與信息工程學(xué)院,湖北 武漢 430062;2.湖北大學(xué)湖北省教育信息化工程技術(shù)研究中心,湖北 武漢 430062)

開源社區(qū)中開發(fā)者的commit提交行為挖掘分析

陳丹1，何鵬1,2

(1.湖北大學(xué)計(jì)算機(jī)與信息工程學(xué)院,湖北 武漢 430062;
2.湖北大學(xué)湖北省教育信息化工程技術(shù)研究中心,湖北 武漢 430062)

以Github開源社區(qū)為研究對象，分析社區(qū)中開發(fā)者在commit提交過程中的行為，探索開發(fā)者之間的交互關(guān)系.研究內(nèi)容包括分析影響開發(fā)者提交行為的因素，探析commit的提交者與創(chuàng)作者關(guān)系,進(jìn)一步分析commit的評論者的行為.研究結(jié)果發(fā)現(xiàn)：1)構(gòu)建項(xiàng)目團(tuán)隊(duì)的成員組織數(shù)不宜超過10，但開發(fā)者規(guī)模可以適當(dāng)擴(kuò)大；2)項(xiàng)目commit的提交90%以上都以核心成員為主，未充分調(diào)動(dòng)開源社區(qū)中廣大愛好者參與的積極性；3)參與一個(gè)commit評論的開發(fā)者數(shù)大多在5人以內(nèi)，且參與同一個(gè)commit評論的開發(fā)者多來自不同的項(xiàng)目或組織.

開源社區(qū)；提交行為；軟件開發(fā)；開發(fā)者網(wǎng)絡(luò)

0 引言

隨著物聯(lián)網(wǎng)、云計(jì)算等應(yīng)用技術(shù)的日益普及和廣泛使用，依托于社區(qū)化群體開發(fā)的各類虛擬社區(qū)開源軟件生產(chǎn)組織模式也得到了快速發(fā)展，人與人之間的社會(huì)關(guān)系分析也成為研究熱點(diǎn).開源社區(qū)提供豐富的軟件自由下載，支持大眾參與到社區(qū)的開發(fā)中，也允許二次開發(fā)并按照相應(yīng)的開源協(xié)議進(jìn)行發(fā)布.隨著開源軟件的流行，人們愈發(fā)渴望理解開源社區(qū)中的諸多現(xiàn)象，如影響開源軟件成功的決定因素[1-2],開發(fā)者自愿參與的動(dòng)機(jī)[3-4]，開源社區(qū)中影響開源軟件擴(kuò)散的主要?jiǎng)恿5]，開源軟件開發(fā)者合作機(jī)制與合作意識(shí)[6]等.開源社區(qū)(如Github)作為一類典型的群體軟件開發(fā)社區(qū)，來自不同國家、有著不同背景的開發(fā)者通過加入社區(qū)與其他開發(fā)者互惠合作，強(qiáng)調(diào)源代碼免費(fèi)、開放以吸引更多的人成為社區(qū)的參與者，積累下來的軟件數(shù)據(jù)與制品將成為社區(qū)的共享資源.

開源社區(qū)門檻低、源碼開放、自由參與等特征，便于大量的軟件開發(fā)者可以自由加入感興趣的項(xiàng)目當(dāng)中去.但同時(shí)問題也隨之而來，很多開源社區(qū)上的開源軟件開發(fā)效率低下，軟件質(zhì)量得不到保證.Github作為當(dāng)今最為流行的軟件項(xiàng)目托管平臺(tái)，集版本控制、信息交流、代碼分析、團(tuán)隊(duì)協(xié)作為一體.本文中以GHTorrent提供的Github社區(qū)數(shù)據(jù)(截止到2013年10月)為基礎(chǔ)，分析開源社區(qū)中開發(fā)者的commit提交行為以及影響其提交行為的因素，從而獲取開發(fā)者的典型提交行為模式.

以下內(nèi)容的組織結(jié)構(gòu)為：第1部分為相關(guān)研究工作的介紹；第2部分為相關(guān)理論基礎(chǔ)介紹；第3部分是研究方法及實(shí)驗(yàn)數(shù)據(jù)分析；第4部分對于本文的研究結(jié)果及不足之處進(jìn)行討論；第5部分為全文的總結(jié)與工作展望.

1 相關(guān)工作

目前為止，開源社區(qū)中關(guān)于開發(fā)者的角色、開發(fā)者之間的合作關(guān)系產(chǎn)生的動(dòng)機(jī)以及開源軟件項(xiàng)目質(zhì)量的影響因素等的分析已經(jīng)引起廣泛關(guān)注，很多文獻(xiàn)都對此進(jìn)行過分析與驗(yàn)證.He等人[7]通過對SourceForge.net社區(qū)中開源軟件項(xiàng)目進(jìn)行收集，在項(xiàng)目-管理者二分網(wǎng)絡(luò)基礎(chǔ)上構(gòu)建管理者合作網(wǎng)絡(luò)模型，對管理者的度分布進(jìn)行分析發(fā)現(xiàn)網(wǎng)絡(luò)呈現(xiàn)明顯的核心/邊緣結(jié)構(gòu).Robinson等人[8]利用序列挖掘方法對Github上124個(gè)項(xiàng)目進(jìn)行挖掘，得到開發(fā)者活動(dòng)的回歸模型，發(fā)現(xiàn)行為的變化與情緒變化的相關(guān)性.

Wang等人[9]通過分析Tomcat 6各個(gè)版本下開發(fā)者合作網(wǎng)絡(luò)中開發(fā)者的活躍度演化趨勢，提取出典型的角色演化模式，并且對比了不同演化模式下開發(fā)者在特定工作類型的貢獻(xiàn)程度.Choi等人[4]通過網(wǎng)上調(diào)查研究的方式獲得的結(jié)果表明開發(fā)者參與開源軟件項(xiàng)目開發(fā)的動(dòng)機(jī)(如學(xué)習(xí)需求、興趣、與工作經(jīng)歷相關(guān)等)的多樣化.Huang等人[10]根據(jù)開發(fā)者提交的日志信息，構(gòu)建開發(fā)者-模塊網(wǎng)絡(luò)來描述開發(fā)者之間的交互，并建立LPP邊緣學(xué)習(xí)過程模型用于劃分開發(fā)團(tuán)隊(duì)中成員的角色.Onoue[11]等人通過Github提供的APIs研究每個(gè)開發(fā)者產(chǎn)生的Github事件發(fā)現(xiàn)敏捷的軟件項(xiàng)目往往擁有多樣化的開發(fā)者，且這些開發(fā)者往往參與了不同類型的開發(fā)活動(dòng).

commit提交是開源軟件版本控制中的一個(gè)非常重要的操作.隨著研究者們研究的不斷深入，關(guān)于開發(fā)者commit行為的研究也逐漸涌現(xiàn)，Ma等人[12]調(diào)查了軟件開發(fā)者集體和個(gè)人提交commit的時(shí)間間隔，發(fā)現(xiàn)項(xiàng)目無論在整個(gè)生命周期還是每個(gè)版本中的commit提交時(shí)間間隔均大致滿足冪率分布，且大多數(shù)連續(xù)性commit提交到軟件庫的時(shí)間間隔很短，其中只有少數(shù)情況經(jīng)過長時(shí)間等待.Yang[13]定義四個(gè)指標(biāo)來衡量開發(fā)者提交行為和代碼演化規(guī)律，即每次commit的變化、提交commit的時(shí)間間隔、每次變化的提交作者和源代碼依賴，發(fā)現(xiàn)之前版本中對文件的更改可能會(huì)影響下一個(gè)版本，且修改“huge commit”所需的天數(shù)平均是普通commit的3倍.此外，一些研究者也嘗試通過commit行為本身的屬性去對軟件項(xiàng)目進(jìn)行定量分析.如Hofmann[14]指出在軟件項(xiàng)目分析中提交的commit量是衡量對軟件貢獻(xiàn)度的一個(gè)重要指標(biāo)，并設(shè)計(jì)算法計(jì)算commit的量.

此外，Cavrak[15]等人對分布式軟件開發(fā)者合作行為模式、動(dòng)機(jī)和角色進(jìn)行了分析，以便更好地理解分布式項(xiàng)目的開發(fā)動(dòng)態(tài).Gharehyazie[16]等人針對Apache社區(qū)中開發(fā)者的技術(shù)貢獻(xiàn)和社會(huì)交互行為分析其是否適合作為一個(gè)committer角色.Zhou[17]等人對新成員如何在項(xiàng)目問題解決過程中體現(xiàn)自己的貢獻(xiàn)，從而提高他們在項(xiàng)目的影響力問題展開開發(fā)者行為分析.

綜上所述，開源社區(qū)中分析開發(fā)者個(gè)人角色及行為方面的研究層出不窮，但與已有工作不同，本文中將重點(diǎn)關(guān)注開源社區(qū)中開發(fā)者的commit提交行為，探索開發(fā)者在項(xiàng)目開發(fā)過程中，尤其是commit提交行為過程中不同開發(fā)者之間的交互關(guān)系.

本研究的貢獻(xiàn)主要為:

1) 與已有的文獻(xiàn)不同，本文中以整個(gè)Github社區(qū)中的項(xiàng)目開發(fā)者commit行為為切入點(diǎn)，探析開發(fā)者commit提交行為的潛在交互規(guī)律.

2) 分析影響commit提交行為的一些因素，并進(jìn)一步探索commit的評論人之間的交互關(guān)系.

2 理論基礎(chǔ)

2.1 開源社區(qū) 開源社區(qū)又稱開放源代碼社區(qū)，是一個(gè)供廣大熱愛開源開發(fā)的開發(fā)者自由學(xué)習(xí)交流的虛擬平臺(tái).本文中選取Github開源社區(qū)為研究對象，作為當(dāng)今最為流行的開源軟件項(xiàng)目托管平臺(tái)，據(jù)統(tǒng)計(jì)該平臺(tái)已有超過1 200萬用戶和超過3 100萬個(gè)開源項(xiàng)目.Github為每個(gè)部署的開源軟件建立一個(gè)repository庫，用于存儲(chǔ)各種軟件開發(fā)數(shù)據(jù)，如項(xiàng)目成員信息、項(xiàng)目描述信息、項(xiàng)目缺陷修復(fù)信息、commit提交信息，以及commit評論信息，等等.

GitHub社區(qū)的獨(dú)特性在于從另外一個(gè)項(xiàng)目進(jìn)行分支的簡易性.為一個(gè)項(xiàng)目貢獻(xiàn)代碼非常簡單：首先點(diǎn)擊項(xiàng)目站點(diǎn)的“fork”的按鈕，然后將代碼導(dǎo)出并將修改加入到分出的代碼庫中，最后通過內(nèi)建的“pull request”機(jī)制向項(xiàng)目負(fù)責(zé)人申請代碼合并.因此，有人將GitHub稱為代碼玩家的MySpace.當(dāng)文件修改到一定程度時(shí)，可以“保存一個(gè)代碼快照”，在Git中被稱為commit.一旦錯(cuò)改或誤刪了文件，還可從最近的一個(gè)commit恢復(fù).

本文的主要目標(biāo)是挖掘分析Github社區(qū)中開發(fā)者的commit提交行為，所用到的數(shù)據(jù)主要涉及數(shù)據(jù)庫中的8張表，分別為users(用戶表)、projects(項(xiàng)目表)、project_members(項(xiàng)目成員關(guān)系表)、issues(問題基本信息表)、organization_members(組織成員關(guān)系表)、commits(提交信息表)、commit_comments(提交-評論關(guān)系表)、project_commits(項(xiàng)目-提交關(guān)系表).這些表之間的關(guān)系如圖1所示.

圖1 數(shù)據(jù)表關(guān)系圖

2.2 開發(fā)者提交行為 開源軟件開發(fā)是一個(gè)群體協(xié)作的過程，每個(gè)愛好者都可自由參與對項(xiàng)目的修改，并提交各自的問題解決方案.提交具體修改內(nèi)容的開發(fā)者即為commit的author，而對諸多author提交的commit進(jìn)行決策形成最終采納方案的開發(fā)者為committer.在項(xiàng)目的commit中，一些開發(fā)者既扮演author的角色又扮演committer的角色，且一個(gè)問題常需要多次甚至幾十次的修改討論后才能得到解決.

項(xiàng)目的開發(fā)者來自世界各地，他們彼此可能互不相識(shí)，一個(gè)開源項(xiàng)目的成員可由來自多個(gè)組織/團(tuán)隊(duì)的人構(gòu)成.一個(gè)項(xiàng)目中來自同一個(gè)組織的開發(fā)者的公司分布位置也可能不同，因此，項(xiàng)目成員來源的多樣性是否對開發(fā)者的commit行為具有影響，是一個(gè)值得探討的問題.

2.3 開發(fā)者評論行為 社會(huì)網(wǎng)絡(luò)主要研究在一定范圍內(nèi)個(gè)體與個(gè)體之間的關(guān)系，網(wǎng)絡(luò)中的節(jié)點(diǎn)是個(gè)體，邊則是按一定方式定義的兩個(gè)人之間的交互關(guān)系.在軟件開發(fā)過程中，常根據(jù)存在交互的兩個(gè)開發(fā)者間建立合作連邊，構(gòu)成一個(gè)開發(fā)者合作網(wǎng)絡(luò).開發(fā)者對提交的commit內(nèi)容會(huì)進(jìn)行評論(comment)，利用開發(fā)者之間的相互評論關(guān)系，可構(gòu)建一類開發(fā)者合作網(wǎng)絡(luò).合作網(wǎng)絡(luò)中節(jié)點(diǎn)表示對commit做出評論的開發(fā)者，若開發(fā)者A對開發(fā)者B提交的內(nèi)容進(jìn)行了評論，則A與B之間被視為存在一條合作連邊.

對于一個(gè)項(xiàng)目的commit，對其進(jìn)行評論的開發(fā)者是否主要為該項(xiàng)目的成員，即表現(xiàn)出項(xiàng)目內(nèi)部相互討論的局面；還是更多評論來自非本項(xiàng)目的其他開發(fā)者，表現(xiàn)為外部群體貢獻(xiàn).另外，從問題解決時(shí)間上，一個(gè)commit提交后，項(xiàng)目管理員可能還關(guān)心大致要多久或者經(jīng)歷幾輪討論方能解決當(dāng)前問題.研究開發(fā)者對commit的評論頻率、次數(shù)及相鄰兩次評論的時(shí)間間隔，有助于提高社區(qū)問題的解決效率.

3 實(shí)驗(yàn)分析

3.1 數(shù)據(jù) 本文的實(shí)驗(yàn)數(shù)據(jù)借助公開的GHTorrent API，獲取Github上開源項(xiàng)目開發(fā)數(shù)據(jù).圖1為我們

表1 實(shí)驗(yàn)數(shù)據(jù)統(tǒng)計(jì)信息

在數(shù)據(jù)收集過程中涉及的8張表的關(guān)聯(lián)關(guān)系.由于數(shù)據(jù)量的龐大，為了使研究結(jié)果更具有一般性，我們隨機(jī)選取其中的1 800個(gè)項(xiàng)目作為實(shí)驗(yàn)對象，其中涉及的總開發(fā)者數(shù)是1 682個(gè)，一個(gè)項(xiàng)目成員最多為313個(gè)，最少1個(gè)，平均具有24.42個(gè)開發(fā)者；commit數(shù)據(jù)共 254 774條，對應(yīng)的comment數(shù)據(jù)386 754條，詳細(xì)信息見表1.

3.2 開發(fā)者提交行為分析

3.2.1 影響開發(fā)者提交行為因素分析 首先，考慮到一個(gè)項(xiàng)目的開發(fā)成員可能由來自多個(gè)組織的開發(fā)者所組成，而一個(gè)項(xiàng)目中來自不同組織的兩個(gè)開發(fā)者之間交互效果可能比來自同一組織開發(fā)者的更差，從而影響開發(fā)者commit提交行為.為分析項(xiàng)目開發(fā)者的commit提交行為是否受該項(xiàng)目成員的組成關(guān)系影響，圖2給出了兩者之間的關(guān)系圖，結(jié)果顯示一個(gè)項(xiàng)目的開發(fā)者來自的組織越多，所需提交的commit數(shù)也越多.結(jié)果證實(shí)了不同組織的開發(fā)者之間交流不如相同組織成員之間高效，致使commit數(shù)變多.甚至，當(dāng)組成項(xiàng)目團(tuán)隊(duì)的開發(fā)者來自的組織數(shù)超過10時(shí)，有些項(xiàng)目的commit相比組織數(shù)更小的項(xiàng)目的commit數(shù)增加了一倍.

另外，我們也進(jìn)一步分析了項(xiàng)目開發(fā)者的commit數(shù)與項(xiàng)目issue(issue主要指question、bug、enhancement)數(shù)之間的關(guān)系.根據(jù)圖3中給出的項(xiàng)目開發(fā)者提交的commit數(shù)與項(xiàng)目問題issue數(shù)之間的正相關(guān)關(guān)系，說明開發(fā)者的整體commit提交行為越頻繁，項(xiàng)目中issue數(shù)會(huì)越多.換句話說，開發(fā)者之間交流不暢在一定程度上會(huì)阻礙開發(fā)過程中開發(fā)者意見達(dá)成一致，從而影響項(xiàng)目開發(fā)質(zhì)量.

圖2 開發(fā)者提交行為與organizations關(guān)系

圖3 開發(fā)者提交行為與issues數(shù)關(guān)系

圖4 開發(fā)者提交行為與團(tuán)隊(duì)members關(guān)系

前面是從項(xiàng)目團(tuán)隊(duì)的組織來源進(jìn)行分析，我們也對社區(qū)中開發(fā)者的commit提交行為與項(xiàng)目參與成員規(guī)模之間的關(guān)系進(jìn)行了分析.圖4顯示當(dāng)項(xiàng)目團(tuán)隊(duì)規(guī)模在26人以內(nèi)時(shí)，項(xiàng)目開發(fā)者提交的commit數(shù)隨項(xiàng)目團(tuán)隊(duì)規(guī)模增大而增多；然而，當(dāng)項(xiàng)目團(tuán)隊(duì)規(guī)模再增大時(shí)，開發(fā)者提交的commit明顯減少.該實(shí)驗(yàn)結(jié)果表明：開源項(xiàng)目中并不是成員越多，他們之間的交互就越頻繁.小規(guī)模團(tuán)隊(duì)之間交互頻繁，大團(tuán)隊(duì)可能采取任務(wù)分工，因而局部成員之間的交互行為更緊密，這也是為什么規(guī)模大的項(xiàng)目開發(fā)者平均commit數(shù)變小的一個(gè)可能原因.

因此，開源軟件開發(fā)者的commit提交行為與成員的組織來源數(shù)和規(guī)模大小相關(guān)，整體上表現(xiàn)為項(xiàng)目成員的組織來源不宜過于分散，成員的規(guī)?？梢赃m當(dāng)擴(kuò)大(超過26人).項(xiàng)目管理者可通過吸引更多與已有開發(fā)者來自同一個(gè)組織的其他開發(fā)者參與項(xiàng)目的開發(fā)，來提高項(xiàng)目的開發(fā)效率與質(zhì)量.

3.2.2 commit的提交者與創(chuàng)作者關(guān)系以及他們在項(xiàng)目中的角色分析 開發(fā)過程中，先是開發(fā)者生成commit (這類開發(fā)者為commit的創(chuàng)作者author)，再提交給具有更高權(quán)限的核心開發(fā)者或管理員(這類開發(fā)者負(fù)責(zé)把收到的commit提交到軟件庫中，即為committer).因此，本節(jié)我們將重點(diǎn)研究分析commit的author和committer為同一個(gè)人和不是同一個(gè)人時(shí)，他們之間的關(guān)系情況.

我們分析了所有收集的commit數(shù)據(jù)，通過整理分析，發(fā)現(xiàn)項(xiàng)目commit的committer和author在大多數(shù)情況下是同一個(gè)人，其中author和committer是同一個(gè)人的commit數(shù)占90.2%的比例，而不是同一個(gè)人的commit數(shù)有54 211條.這說明大多數(shù)情況下，從事項(xiàng)目commit提交行為的開發(fā)者都是項(xiàng)目的核心開發(fā)者，僅有少量具有較低權(quán)限的邊緣開發(fā)者參與其中，這也間接反映了社區(qū)中在可供利用的人力資源基礎(chǔ)上調(diào)動(dòng)的還不夠充分，還未能充分對群體智慧加以利用.

針對54 211條author和committer不是同一人的commit數(shù)據(jù)，我們按照以上兩類角色的開發(fā)者是否來自同一個(gè)項(xiàng)目和同一個(gè)組織進(jìn)行分類.圖5顯示這些commit中author和committer來自不同項(xiàng)目的比例占84.5%，author和committer來自不同組織的比例占87.3%，而兩人來自于同一項(xiàng)目和同一組織的比例均不超過20%.另外，我們還發(fā)現(xiàn)即使兩個(gè)開發(fā)者來自同一個(gè)項(xiàng)目或同一個(gè)組織，但他們之間有共同參與commit提交的合作者比例也分別僅占0.03%和6.56%(見圖6).說明項(xiàng)目commit的author和committer之間往往沒有太多交集，但是卻能自覺地建立合作.

圖5 author與committer來自同項(xiàng)目或同組織的比例

圖6 author與committer有共同合作者的比例

由于committer一般為項(xiàng)目的核心開發(fā)者，author為外圍或邊緣開發(fā)者.因此，上述結(jié)果表明，絕大部分項(xiàng)目依舊還是其主要開發(fā)者在進(jìn)行開發(fā)與維護(hù)，還沒有充分調(diào)動(dòng)開源社區(qū)中廣大愛好者參與開源項(xiàng)目開發(fā)的積極性.

3.3 開發(fā)者評論行為 每個(gè)項(xiàng)目提交的commit數(shù)通常至少上百個(gè)不等，而每個(gè)commit的評論人數(shù)也各不相同，本節(jié)我們重點(diǎn)探討關(guān)于項(xiàng)目commit的評論行為.

首先，我們將commit的評論人劃分為3類：來自同一個(gè)項(xiàng)目(組織)、來自不同的項(xiàng)目(組織)、其他.根據(jù)圖7發(fā)現(xiàn)大部分commits的評論人是來自不同的項(xiàng)目(組織)、極少部分是來自相同項(xiàng)目(組織)的開發(fā)者之間交互，只占0.45%(8.26%)；而一個(gè)commit中參與評論的開發(fā)者既有一部分來自同一個(gè)項(xiàng)目(組織)，又有一部分來自不同項(xiàng)目(組織)的情況大約占四分之一.說明目前參與commit評論的人多是彼此之間素不謀面或者相互合作過的開發(fā)者.然而，通過對相鄰兩個(gè)評論人之間發(fā)表評論的時(shí)間間隔分析，圖8中我們可以看出大部分commit的評論在一個(gè)月內(nèi)完成，超過一個(gè)月的比例僅占19.8%.并且我們對所有commits的評論人數(shù)進(jìn)行統(tǒng)計(jì)分析發(fā)現(xiàn)大部分的commits的評論人在5個(gè)以內(nèi)，只有少部分的項(xiàng)目commits的評論人超過24個(gè).

圖7 commit的評論人同項(xiàng)目或同組織分配比例

圖8 commit的評論產(chǎn)生頻率

圖9 commit評論人構(gòu)建的開發(fā)者網(wǎng)絡(luò)模型

其次，我們選取commit數(shù)為3 411的項(xiàng)目(proj_id=22980)作進(jìn)一步分析，選取原因是該項(xiàng)目的開發(fā)者數(shù)適中且其commit數(shù)接近所抓取的項(xiàng)目commit數(shù)分布的中位數(shù)，具有一定的代表性.我們利用網(wǎng)絡(luò)可視化軟件Gephi對該項(xiàng)目下的一個(gè)commit(commit_id=124 678)的全部評論人(共123人)建立合作網(wǎng)絡(luò)模型(見圖9).其中節(jié)點(diǎn)代表對commit進(jìn)行評論的評論人，節(jié)點(diǎn)之間的邊則說明兩個(gè)開發(fā)者之前有過共同評價(jià).由圖9可見123個(gè)評論人中，合作緊密程度并不大，主要以兩個(gè)評論人為主，存在大量只是參與此次commit的評論但跟其他評論人沒有交互經(jīng)驗(yàn)的開發(fā)者.

實(shí)驗(yàn)結(jié)果表明：整體上commit的評論人在5個(gè)以內(nèi)，且參與同一個(gè)commit評論的評論人大多來自不同的項(xiàng)目或組織，這些人之間有關(guān)聯(lián)的占少數(shù)，表現(xiàn)出群體交互還不夠緊密.

4 討論

本文中對開源軟件項(xiàng)目開發(fā)者的commit提交行為進(jìn)行了挖掘分析，得出了一些結(jié)論，如開發(fā)者的commit提交行為受成員的組織來源和規(guī)模大小的影響，commit的author和committer通常都是同一個(gè)人，評論人之間的聯(lián)系不夠緊密，等等.然而，本文也存在著以下不足之處.

首先，我們選用作實(shí)驗(yàn)的數(shù)據(jù)為2013年10月以前抽取的數(shù)據(jù)，目前GHTorent項(xiàng)目中數(shù)據(jù)已更新到2016年，提供的數(shù)據(jù)表中還包括其他信息，如項(xiàng)目的編程語言、里程碑(milestone)、用戶的關(guān)注者(watcher)，以及issue的評論等.這些信息目前我們都沒有考慮，主要是出于數(shù)據(jù)量的處理問題，毫無疑問在后期的工作中我們將對這部分信息進(jìn)行進(jìn)一步分析利用.

其次，在3.2.1節(jié)中分析項(xiàng)目開發(fā)者的commits數(shù)與成員的組織數(shù)之間關(guān)系時(shí)，圖2中橫坐標(biāo)設(shè)置為20以內(nèi)，根據(jù)對數(shù)據(jù)的統(tǒng)計(jì)發(fā)現(xiàn)，平均每個(gè)項(xiàng)目的開發(fā)者數(shù)不超過25個(gè)，且只有少數(shù)的項(xiàng)目開發(fā)者數(shù)比較多，所以我們僅考慮那些開發(fā)者來源組織數(shù)不超過20的項(xiàng)目是具有一定的代表性的.

目前較為流行的開源社區(qū)除Github之外，還有Sourceforge、Rubyforge、Google code等.本文中以Github社區(qū)為研究對象，除了因?yàn)樵撋鐓^(qū)提供了大量的數(shù)據(jù)集，其知名度更廣也是一個(gè)原因.我們選用該社區(qū)進(jìn)行分析，相信我們的結(jié)論在其他社區(qū)中大體一致.

5 總結(jié)與展望

本文中主要圍繞開源社區(qū)中項(xiàng)目開發(fā)者的commit提交行為進(jìn)行了挖掘分析，分析了影響開發(fā)者commit提交的因素、commit的提交者與創(chuàng)作者關(guān)系分析，以及commit的評論者之間的交互關(guān)系.研究發(fā)現(xiàn)：1)開源項(xiàng)目在招募開發(fā)者時(shí)因考慮成員的組織來源不宜太分散，但規(guī)?？梢赃m當(dāng)擴(kuò)大；2)大多數(shù)項(xiàng)目的commit提交主要來源于少數(shù)核心成員的貢獻(xiàn)，對社區(qū)中廣大愛好者的參與積極性調(diào)動(dòng)不夠；3)整體上參與commit評論的開發(fā)者并不多，且參與同一個(gè)commit評論的評論人多來自不同的項(xiàng)目或組織.

我們的工作為開源社區(qū)中項(xiàng)目成員的招募與推薦提供了一定的指導(dǎo)依據(jù)，但正如前面討論部分所提到，Github社區(qū)中還提供了更多豐富的數(shù)據(jù)，所以還有很多有價(jià)值的工作等待我們?nèi)ネ诰?在下一步工作中，我們將根據(jù)得到的分析結(jié)果對開發(fā)者提交的commit及時(shí)推薦評論者，幫助軟件高效開發(fā)，提高軟件開發(fā)質(zhì)量.

[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.

(責(zé)任編輯 江津)

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重點(diǎn)基礎(chǔ)研究發(fā)展規(guī)劃項(xiàng)目(2014CB340401),國家自然科學(xué)基金(61273216),湖北省重大科技創(chuàng)新計(jì)劃(2013AAA020),武漢市青年科技晨光計(jì)劃(2014070404010232)和湖北大學(xué)青年自科基金資助

陳丹(1992-)，女，碩士生；何鵬，通信作者，講師， E-mail:penghe@hubu.edu.cn

1000-2375(2017)02-0176-07

TP301

A

10.3969/j.issn.1000-2375.2017.02.014