開源社區中開發者的跨項目行為

趙佳斌，趙海燕，曹 健，陳慶奎

1(上海理工大學 光電信息與計算機工程學院,上海市現代光學系統重點實驗室光學儀器與系統教育部工程研究中心，上海 200093)2(上海交通大學 計算機科學與技術系，上海 200030)

E-mail：cao-jian@sjtu.edu.cn

1 引 言

伴隨社交網絡與軟件開發技術的逐步融合，形成了一種以開源社區為平臺的社交化軟件開發形態，原本集中封閉式的軟件開發模式向開放、分布的軟件開發模式轉變.諸如GitHub這樣的自組織、自愿參與的開源社區平臺吸引了大量來自不同國家和地區、擁有不同開發經驗的開發者參與到開源軟件的開發中.

GitHub采用git來托管項目，支持基于pull-request[1]的開發方式，允許社區內的開發者分叉(fork)任意公開的軟件項目，該操作會復制原始的項目進而允許開發者完成新功能編寫或錯誤修復，從而為潛在的貢獻者提供了低準入門檻.開發人員通過創建和分叉開源項目，推送修改的代碼，審查合并他人推送的代碼，收藏和關注感興趣的開源項目和開發者等以便了解最新的開發動態.同時，開發者之間也通過評論、提問、@等機制相互交流、共享開發經驗.這種開放化、社交化的協同開發方式支撐了群體性軟件開發活動，使得開源社區不斷壯大，也為軟件開發提供了強大的生產力.截止到2018年，GitHub上托管的開源項目已經超過了9600萬，開發者人數也突破了3100萬.

GitHub鼓勵軟件開發活動的透明性[2]，它指的是開發者身份及其活動對其他用戶是可見的.因而，開發者在開源社區的開發活動會留下大量的用戶行為數據，這些行為數據能夠反映開發者的意圖、能力和經驗等.GitHub平臺上項目開發活動數據的公開和透明，為研究大規模軟件協同開發平臺的開發模式、協作方式和人員特點等提供了良好的條件.

開發人員通過參與某一項目可以提高其能力，了解技術的最新動態、乃至實現其自我價值.出于不同的目的與動機，多數開發者在一段時間內會同時參與到多個項目中，同時，在結束或者退出某一個項目后，又會選擇另一個項目，這種同時或者依次在不同項目中的參與行為，本文稱之為跨項目行為.在GitHub上，跨項目非常普遍，然而，對這一普遍性行為目前還缺乏研究.圍繞這一行為有許多問題值得探討，例如，開發者的跨項目行為有怎樣的特點？開發者同時參加的項目或者依次參加的項目之間存在什么樣的關聯？回答這些問題對于設計和改善開源項目的推薦系統有著重要的意義.開源項目需要找到感興趣的開發者，而開發者也需要找到感興趣的項目，目前的推薦系統中忽略了開發者當前的項目參與狀態，因此，對跨項目行為的理解能夠有助于開發更好的推薦算法.

本文旨在通過分析開發者的行為數據，理解開發者跨項目行為特點.具體來說，我們嘗試回答以下5個研究問題：

1)開發者在短期內是否會參加多個不同的項目；

2)開發者是否會在一個項目中長期貢獻；

3)時間間隔對開發者再次回歸項目有何影響；

4)一個開發者同時活躍參與的多個項目的相似性如何；

5)在某個項目中不活躍后新加入的項目與原來項目是否存在相似性.

本文組織如下：在第二節中介紹相關的研究工作，第三節中介紹研究所用的數據集，第四節介紹了本文的研究方法，第五節中對結果進行討論，最后總結全文并對未來的研究進行了展望.

2 相關工作

近年來GitHub開源社區不斷壯大，研究人員也對其展開了大量的研究，其中就包括對社區中開發者的分析.開源社區的開發團隊成員多為自發組織的，具有較高的流動性和多樣性[3].文獻[4，5]對開源社區中新加入的開發者面臨的問題做了總結并給出了解決方法的參考指南.文獻[6，7]將開發者在開源社區中的角色分為項目負責人、核心成員、活躍開發人員、臨時開發人員、錯誤修復者、錯誤報告者、讀者和被動用戶等，并將這種結構稱之為“洋蔥結構”.不同角色的開發者承擔著不同的任務.值得注意的是流行項目的貢獻者中48.9%都是臨時貢獻者[8].

開發者在一個項目中的角色并不是一成不變的，文獻[9]分析了開發者從新加入人員逐步成為長期貢獻者甚至是核心人員的原因，包括參與動機和整體開發環境，與普通加入者相比，他們在項目中的狀態表現更為積極因而也更受關注.文獻[10]對活躍項目中的開發者進行了研究，發現其中的開發者類型往往是混合型的，即開發者在各自的開發活動中表現出不同特征.例如一些貢獻者在代碼，評論和問題解決上表現相對均衡，而有的貢獻者側重其中的一方面.文獻[11]以訪談的方式分析了影響開發者參與狀態轉變的因素.文獻[12]研究了如何改善團隊管理，他們發現項目中不活躍但作為潛在貢獻者的這批開發者占80%，對整個項目的開發活動有著較大的影響，主要表現在問題解決速度和對pull-request響應上.

參與動機和社交關系將影響社區中開發者的行為.動機理論被廣泛用于解釋人類行為，同樣適用于開源社區.開源社區中的開發者參與動機主要包括：學習如何寫代碼、關注社區中的名人、為個人或團隊的工作做宣傳、尋找有趣的新項目等[13].社交關系是另一大影響因素，開發者加入存在好友的項目其貢獻率將會有大幅提升[14].社交因素有利于維持一種長期的貢獻狀態.文獻[15]重點研究了開發者的關注網絡，發現了四種典型的社交行為模式.文獻[16]研究了開發者的合作模式，開發者之間的合作次數越多，那么他們再次合作的可能性也就越大.同時，開發環境及管理者對于合作有著明顯的影響.

Commit提交行為是開源社區項目版本控制的一個重要操作，同時也是衡量開發者的貢獻的一個重要指標[17].文獻[18]對項目中組織及個人的提交行為做分析，大多數連續提交之間的時間間隔很短且滿足冪律分布.文獻[19]提出四個指標研究開發提交行為與項目版本變換的關系，研究發現，大規模提交所需時間是普通提交的3倍.

從上述相關研究工作的進展看，研究人員從不同的角度探索了開發者的行為特征，然而，本文探討了開發者的跨項目行為特點，對上述研究進行了補充，從而有利于我們更完整地理解開源社區的開發者行為.

3 數據集

3.1 數據采集

本文的研究所依賴的數據借助GitHub提供的豐富的API接口獲得.開發者在進行軟件項目協同開發的過程中會積累一定數量的粉絲，粉絲數量代表了他在開源社區中的地位和影響力，擁有大量粉絲的開發者被視作社區中的“名人”.本文據此選擇了在GitHub社區中最具影響力的1000名開發人員，提取了這些開發者在2017年1月-2018年12月為期兩年的活動行為數據.

GitHub平臺對開發者提供了貢獻統計，開發者的貢獻是以月為時間單位記錄的，貢獻次數及內容越多，該月所在區域顯示的顏色就越深.記錄的行為主要包括以下7種：Create Repository，Created commits，Created a pull request，Opened pull requests，Created an issue，Reviewed pull requests，Opened issues.

3.2 數據預處理

我們獲取的原始數據包含了1000名開發者、47042個項目、7種不同操作的209562條行為數據.這些數據需要進行預處理.考慮到GitHub開源社區中的數據相對稀疏，本文將“月”作為分析周期；鑒于本文分析的是開發者跨項目的行為，僅保留開發者對社區中他人公開項目的行為數據；為了盡可能減少“被降低”的情況，即開發者新加入的項目由于沒有足夠的觀察時間就被認為在加入后沒有在該項目中進行長期的貢獻和活動，剔除了2018年中新加入項目的記錄，保證了開發者在項目中的行為數據的觀察周期至少為一年.

4 問題分析及研究方法

4.1 開發者在短期內是否會參加多個不同的項目

本節主要分析開發者短期內參與到多個不同項目的現象是否很普遍及這種同時參加多個項目的行為與開發者屬性的關系.

按條件對數據篩選后，按月作分組統計，結果如圖1所示，其中在一個月中僅參與一個項目的記錄數最多，為2497條，占23.7%，參與多于一個項目的記錄數則占76.3%.其中的最大記錄是某一位開發者在一個月中參與了67個不同的項目.在數據集上的平均值是7.29個.

圖1 開發者在一個月中參與項目個數Fig.1 Number of projects the developer participatesin in a month

我們進一步按人員計算開發者每月參與項目數的均值，其頻率直方圖如圖2所示.我們發現在一個月中參與項目個數的均值大于5個時，人數出現大幅下降.具體來看，參與項目個數不超過1個的占14.1%；其中均值在1-5之間的占57.1%.參與項目個數均值大于20個的僅占5.3%.

圖2 一個月中參與項目數的頻率直方圖Fig.2 Frequency histogram of the number of participatedprojects in a month

上述結果表明，絕大多數的活躍開發者會同時參加多個項目，但是，他們同時參加的項目也不可能太多.產生這樣的結果的原因主要是開發者的精力通常是有限的，完成一項新功能或者漏洞的修復需要一段時間；同時開發者有一些自己的項目需要編寫和維護，所以通常無法參與數量過多的項目.

開發者的自身屬性包括加入社區時長、擁有項目數量、關注項目的數量、常用編程語言等.首先分析參與項目數量與加入社區時長、擁有項目數量及關注項目數量的相關性.此處我們使用Pearson相關系數來衡量相關性，它是一種衡量兩個隨機變量相關程度的常用方法，相關系數r值取值范圍在[-1，1]之間，取值越大就表示兩個變量之間的相關程度越高，反之，相關程度越低.顯著水平p值則是用來評估相關程度計算結果的“顯著程度”.我們分別計算一個月中參與的項目數與加入社區時長、擁有項目數量、關注項目數量的Pearson相關性，計算結果如表1所示.根據取值范圍判斷變量的相關強度關系表及p值遠小于0.01可知，短期內參與的項目數與所涉及的三個因素都有著很強的顯著水平.其中，短時間參與項目數量與加入社區時長和關注項目數量弱相關；與擁有項目個數為強相關.

表1 跨項目行為的因素相關性分析Table 1 Correlation analysis for factors of cross-project behaviors

我們也分析了開發者常用語言與參與項目數量的關系，結果如表2所示.其中R語言的開發者參與項目數最多，其次為PHP，最少的是C語言的開發者.

表2 開發語言與參與項目數Table 2 Relationship between language and number of participating projects

4.2 開發者是否會在一個項目中長期貢獻

本節分析開發者在項目中參與時長以及開發者在項目中的角色對其長期貢獻的影響.互聯網中，用戶通常存在一個生命周期，這里的生命周期是指用戶從加入平臺，熟悉平臺，參與平臺到最終流失的過程.用戶的生命周期就自身而言，是一種參與度的變化，用戶參與度也可以稱之為用戶在該平臺的活躍度.

開發者參與到開源項目中也會存在一種活躍度的變化，開發者從發現一個自己感興趣的項目、熟悉該項目、參與其中到逐步流失這樣的一個過程通常會體現在行為的時間間隔中.

在對開發者首次加入項目的時間做篩選后，以開發者參與的開源項目作為對象按月統計，結果如圖3、圖4所示.在開源項目中僅僅參加了一個月就不再參加的記錄條數為14401條，占58.7%；參與月數為2-5個月的記錄數為6519條占26.6%，在所分析的時間內參與月數超過15個月的有1673條記錄，占6.83%，有142條記錄在項目中的參與月數為24個月，受制于數據采集時長，實際持續的時間可能更長.

開發者在GitHub中的角色通常分為三種：成員、貢獻者和臨時參與者.當開發者提交的pull-request被合并至源項目后，他就成為了該項目的貢獻者.一個重要的問題是不同的角色是否會影響開發者的貢獻時長?為此本文做了相應分析.由于存在開發者既是成員又貢獻者的情況，此時將這類開發者劃分為成員，分別計算三種角色參與項目的平均時長.我們發現作為成員，平均參與時長為7.39個月，貢獻者為5.02個月，臨時參與者為3.51個月.這個結果符合我們的一般認識.

圖3 開發者在不同項目中參與月數Fig.3 Length of time developers participate in different projects

圖4 聚合統計結果Fig.4 Cumulative results

4.3 時間間隔對開發者再次回歸項目的影響

開發者長期參與到一個項目的過程中，可能會出現一段時間沒有行為的情形，我們稱之為“空窗期”.出現空窗期后，有些開發者會再次參加項目(本文稱之為“回歸”)，而有些開發者就不再參加項目了(本文稱之為“流失”).

圖5 時間間隔與回歸項目的關系Fig.5 Relationship between the situation and time of returning to the project

本節分析參與過程中所存在的空窗期長短對開發者再次回歸的影響.計算間隔n個月后開發者回歸的情況，首先對記錄中間隔周期不滿n個月的進行刪除，尤其是處于采集周期尾部的記錄；然后統計在間隔了n個月后開發者回歸到項目的記錄數并計算其占比，結果如圖5所示.在間隔周期為零個月的情況下(在連續的兩個月中都有參與行為)，開發者再次回歸的占比為62.51%；當間隔周期為一個月那么這個占比會下降到13.98%；當間隔為兩個月，開發者再次回歸的情況占6.95%；當間隔時間為8個月，回歸情況占比不到1%.

4.4 開發者同時活躍參與的多個項目的相似性如何

根據前文的討論，本文界定開發者在一個項目中的參與狀態是否活躍的標準如下：開發者從發現一個感興趣的開源項目、參與貢獻、結束貢獻從該項目中流失是一個連續的過程.本文將其中的啟動期設置為兩個月即當開發者連續兩個月在一個項目中有行為，視作在該項目中開始活躍；設置啟動期的目的是為了區分出那些臨時的參與者；在持續活躍的過程中出現的空窗期不得超過兩個月(超過兩個月將引發較大的流失率).當時間間隔大于兩個月，視作開發者在該項目中結束了本階段的活躍.基于上述對與開發者在項目中的活躍度評判標準，得到了符合條件的621名開發者以及他們參與的5791個開源項目.

首先分析開發者在項目中活躍的持續時間，結果如圖6所示.持續時間為2個月的記錄數量最多；當持續時間增長到3個月時出現大幅回落；活躍持續時間在3-22個月的記錄數相對平穩；活躍持續時長超過22個月的記錄數又出現了明顯的上升，這表明，每個項目中都會有一部分核心貢獻者.

圖6 活躍狀態的持續時間Fig.6 Duration of the active state

接著我們分別從開源項目的開發語言、描述、標簽、流行度和項目規模這五個不同的維度對開發者同時活躍參與項目的相似性進行計算.

開發語言相似性：開發語言描述的是項目所使用的開發語言，通常情況下開發者掌握了兩種及以上的開發語言，根據項目語言的種類選擇自己擅長的一種.

描述相似性：描述是項目的一個簡介，大致描述了該項目實現的功能及用途，方便其他開發者根據描述所表達的內容來選擇自己中意的開源項目.描述通常是一段簡練的文字.本文采用了TF余弦相似性計算兩個項目描述的相似性.具體做法是：首先對描述文本做分詞處理，然后去停用詞，接著構建詞典并將文本轉化為向量，由于文本信息轉為向量，故采用余弦相似度計算其相似性.標簽相似性：標簽是開源項目的另一個特征，它是描述項目的一組關鍵詞，這些關鍵詞組成了一個集合，而Jaccard系數可以用來衡量兩個集合的相似性，其核心就是計算兩個集合交集與并集大小的比值，比值越大表示相似度越高.

流行度的相似性：GitHub中的大量開源項目會受到開發者不同程度的關注，關注者的數量代表著項目的流行度，為了有明確的區分度，本文根據關注者數量對項目的流行度進行劃分如表3所示.

項目大小代表整個項目的規模，這也是開發者選擇項目的一個重要依據之一，同樣將其劃分為小規模、中等規模、較大規模和大規模四個等級如表4所示.

五個特征上的相似度結果如表5所示，相似度為1表示在這一特征上完全一致，相似度為0則表示在該特征上完全不相似.根據相似度大小劃分了6個不同的范圍，每個特征下劃分了兩種不同的情況分別是：同時活躍和下一項.

表4 項目規模劃分表Table 4 Project size division table

表5 開發者活躍狀態參與的項目的相似性表Table 5 Similarity table for projects in which the developer is actively involved

同時活躍狀態下開發者對不同項目的參與情況存在差異，以不同的行為、以及角色做區分，結果如表6和表7所示.

表6 角色差異Table 6 Role difference

我們發現臨時參與者的身份占比超過70%，雖然開發者會同時活躍在多個不同的項目中，但是重點參與的通常只有一個

表7 行為差異Table 7 Behavior difference

到兩個，其中commit的次數遠高于pull-request.例如編號為21號的開發者，在其同時活躍的6個項目中，僅在一個項目中為成員，在其余的項目中的角色都是臨時參與者.

4.5 開發者在項目中結束活躍后新加入項目特點

一般情況下開發者在一個開源項目中結束活躍后，會選擇加入一個新的項目，本節分析新加入項目的特點.

圖7 加入新項目的平均時間間隔Fig.7 Average time interval for joining new projects

將開發者結束活躍的項目與隨后加入的項目設置成一對，分別從間隔時間和標簽、描述、開發語言、流行度和規模這些特征分析新加入的項目特點.實驗結果如圖7和表8所示.

表8 新加入項目與結束活躍項目的相似性表Table 8 Similarity table for new and ending active projects

結果顯示開發者在一個項目中結束活躍后再次加入到新項目的平均時間間隔不超過一個月的開發者占75.6%.

5 討 論

5.1 開發者在短期內是否會參加多個不同的項目

結果顯示，絕大部分的情況下(76.3%)，開發者都愿意在一個月內(較短的時間段)參與兩個及以上的不同項目，那么在向開發者進行開源項目推薦的時候就可以摒棄如下顧慮：開發者當前已經參加了一個項目，他將不再接受其他推薦，實際情況是開發者愿意在短時間內參與多個不同的開源項目.當然，這個數量通常是有限的，開發者當前參與的項目數量大于5個后，那么他接受新項目推薦的概率將大幅降低.據此，社區平臺的推薦機制可以優先為那些參與項目數量小于5個項目的開發者提供個性化推薦服務.開發者參與項目的數量與自己所擁有的項目數量存在較強的相關性，開發者擁有的這些項目一部分是他自己創建的，另一部分是fork他人的開源項目，這些項目的數量越多也表示其在社區中越活躍，因而他在短期內參與較多項目的可能性也會相應高于其他開發者.

5.2 開發者是否會在一個項目中長期貢獻

開發者在項目中的行為次數反映了他在該項目中的參與程度，次數越多就表明他在該項目中的參與度就越高，活躍度也越高.開發者在不同項目中參與的周期數和行為次數會存在較大的差異，對大部份的項目參與次數都較少且集中于某一個月中，對小部分的項目會有長周期(平均值為10個月)的參與和貢獻，期間會存在若干的空窗期.這里提到的空窗期指的是對同一個項目兩次參與行為之間的間隔時間.項目中的長期參與者大部分都是項目內部人員，當然臨時參與者的提交被合并后，他就成為了該項目的貢獻者，后續是以內部成員的角色參與其中.不同的角色參與項目的時長也存在明顯的差異，項目成員的持續時間最長，而臨時參與者最短.其中，這類開發者愿意長期參與維護或貢獻的開源項目更能凸顯該名開發者對某一特定領域的偏好.推薦系統在為該名開發者進行開發者建模時不妨可以考慮提高他長期參與貢獻項目特點的權重，使得開發者模型更為精準.

5.3 時間間隔對開發者再次回歸項目的影響

開發者參與貢獻或維護一個開源項目通常是一個連續的過程，期間間隔周期的長短是反映他在該項目中活躍與否的重要指標[10]之一，時間間隔越長表示對于該項目的興趣不斷下降，那么他在項目中流失的可能性也就越大.本文認為，時間間隔為兩個月是一個比較合適的分割點[10]，由于間隔超過兩個月開發者回歸的情況大幅降低，所以開發者在一個項目中連續兩個月沒有參與行為，那么可以判定他在該項目中流失即他將不再繼續參與該項目.平臺的開源項目推薦系統在進行項目推薦時，可以優先分析一下開發者在項目中的參與程度積極與否，從而得到一個合適的契機.

5.4 同時活躍狀態下參與項目及新加入項目的相似性

我們發現描述相似性普遍很低，由此可知開源項目的描述相似性在實現推薦中并不是一個合適的特征.標簽相似性略高于描述相似性，但絕大部分的情況小于0.3.開發語言的相似性要明顯好于前兩者，開發者在選擇項目的時候都偏愛自己熟悉的語言.當然也存在開發語言完全不同的情況，主要原因是開發者通常會掌握兩種以上的開發語言以滿足不同的業務需求.在項目的流行度和規模上都表現出了較高的相似性，尤其是在項目的流行度上，這一點應該與選擇分析的對象是有著較高影響力的開發者有關，后續的研究可以討論開發者的影響力與項目流行度是否存在關聯.

在一個項目結束活躍后，開發者往往會在較短的時間內加入一個新的項目，這個時間通常小于一個月.新加入項目和結束活躍項目兩者相似性要明顯高于同時活躍狀態下的項目相似性，在開發語言上完全不同的情況大幅降低，這為項目推薦提供了重要的參考即開發者在選擇下一個項目的時候會偏愛與上一個項目類似的開發語言.

6 總結與展望

本文對開發者在多個開源項目中的參與情況做了分析，意義在于嘗試理解開發者的跨項目行為特點，為后續的開發者建模及開源項目的個性化推薦提供一定的參考依據.結果表明，開發者普遍都愿意同時參與多個開源項目，參與項目數與擁有項目數存在較強的相關性；角色為成員的開發者在項目中持續的時長要明顯高于其他兩種角色的開發者；當開發者在一個開源項目中的行為間隔超過兩個月那么他再次回歸該項目的可能性大幅降低；同時活躍狀態下開發者參與的項目中，大部分都是以臨時參與者的身份參與其中；開發者在一個項目中結束活躍后，普遍愿意在一個月內加入一個新的項目，且新加入項目的相似性要明顯高于同時活躍狀態下的相似性.對開發者進行開源項目推薦時，可通過分析他當前參與項目中的活躍狀態變化，得到一個合適的推薦時機.這樣的考慮開發者當前參與狀態的推薦方式比起以往的推薦機制顯得更合理、更人性化.

當然，本文所做的工作還相對有限，存在需要改進的地方.例如考慮到用戶行為數據的稀疏性(20%的開發者在開源社區中做出了80%的貢獻)，所以本文選取的研究對象是1000名有著較大影響力的開發者.還有就是對項目相似度的衡量，不應只局限于若干自帶的屬性.在下一步的研究工作中，要擴大實驗數據的規模，覆蓋更為廣泛的開發者，同時增加對項目相似度的評價屬性和方法，對開發者的行為進行更精準的評估.

開發者作為開源軟件的核心，是整個開源社區的靈魂所在，開發者的狀態將直接決定一個開源項目的成功與否甚至影響整個開源社區的健康可持續發展.本文分析了開源社區中開發者跨項目參與行為，主要包括參與項目情況、活躍度的變化和參與項目之間的相似度特點.開發者依然是未來研究工作的一個方向，可以重點關注哪些因素會影響開發者在開源項目中的活躍狀態，哪些原因使得開發者從項目中流失及當前狀態下開發者表現出的何種行為特點將預示著他將從該項目中流失.找到其中的影響因素并采取相應的措施將會使得整個開源社區受益.