開源軟件版本發布與開源社區貢獻評估的關系實證研究

董 晨 尹 剛

1(天津理工大學計算機科學與工程學院天津市智能計算及軟件新技術重點實驗室 天津 300384)2(國防科技大學計算機學院復雜系統軟件工程湖南省重點實驗室 湖南 長沙 410073)

0 引 言

開源軟件是一種源代碼可以自由獲取、修改、再分發的軟件[1-2]，其所展現出的強大創新力和生命力給軟件產業帶來了巨大的變革，開源軟件正在被越來越多的領域所應用。例如著名的開源軟件Linux正在被大量的企業和機構用作服務器操作系統，成為支撐起如今互聯網高效運轉的重要基礎設施。開源軟件的成功來自于開源社區的開源開發者[3-4]，這些開源開發者分布在世界各地，他們通過網絡進行溝通和合作，并在一定的協同機制下為開源軟件貢獻代碼[5]。據Linux基金會2017年的官方數據統計，已經有來自1 300多個公司的14 000多個開發者為Linux內核提交了代碼貢獻。由此可見,開源開發者是開發軟件得以生存和發展的重要推動力。

另一方面，開源軟件在不斷發展的過程中會經歷一個個的里程碑，并在恰當時機發布新的軟件版本[6]。每一個軟件版本可能包含了對上一個版本所包含的bug(軟件缺陷)的修復，也可能包含了新添加的功能。在每次發布新的軟件版本時，軟件項目的管理團隊需要在綜合考慮軟件的穩定性以及任務的緊迫性的前提下，決定是否需要把某些特定改動加入到本次發布計劃中[7]。

軟件版本發布規劃不僅僅會直接影響到軟件用戶群體的使用體驗，還有可能會影響到開源開發者的參與體驗。然而正如前所述，開源開發者是促進開源軟件不斷發展的核心力量。因此，為了更好地分析開源社區對開源開發者貢獻的接受現狀，本文從開源軟件版本發布的角度出發，對開源開發者的貢獻評估進行了實證研究，并試圖回答以下兩個研究問題：

研究問題1:開源軟件版本發布對開源社區貢獻第一次評估反饋延遲的影響。

研究問題2:開源軟件版本發布對開源社區貢獻接受概率的影響。

通過這些研究，我們深入分析了開源軟件版本發布與開源社區開發者貢獻評估的關聯關系。與此同時，我們也對開源社區提出了相應的實踐建議，以促進開源社區的健康持續發展。

1 研究方法

如圖1所示，我們首先構建開源軟件版本發布與社區貢獻數據集，然后基于此數據集分別開展兩方面的研究：1) 軟件版本發布與第一次評估反饋延遲的關聯分析；2) 軟件版本發布與貢獻接受概率的關聯分析。

圖1 研究方法概覽

1.1 數據集構建

(1) 調研項目。GitHub是目前最火的開源社區，它為開源軟件提供源代碼托管、開發任務管理等一系列功能和服務，目前已經托管了超過一千多萬的開源軟件項目。鑒于GitHub平臺是極具代表性的開源社區平臺，我們選取它作為我們的調研平臺，并在該平臺上進一步選取了要具體分析的開源軟件。我們設定的軟件篩選標準為：

? 軟件版本發布頻繁。

? 軟件比較流行，參與的開源開發者數量大。

最終，我們選取了GitHub平臺上三個流行開源軟件：bootstrap、scikit-learn以及elasticsearch，三個開源軟件具有不同的編程語言和應用領域，其基本信息如表1所示。如表2所示，其社區關注數量和開發者群體以及其代碼提交數量都是位于社區前列水平，表明其是具有一定流行度的軟件。

表1 調研項目的基本信息

表2 調研項目的流行度指標

(2) 原始數據采集。如圖2所示，我們通過Github網站提供的數據服務接口采集實驗所需的原始數據。Github提供了豐富的接口以獲取其網站的各種數據，其中社區貢獻數據通過接口“/repos/:owner/:repo/pulls”采集，版本發布數據通過接口“/repos/:owner/:repo/releases”采集。采集到的數據存儲于關系型數據庫MySQL中。

圖2 數據采集方案

(3) 數據清洗。為保證實驗的準確性和有效性，消除其他干擾因素的影響，我們對采集到的原始數據進一步清洗，其中包括以下操作：

? 剔除起始階段的數據：由于在軟件發展的起始階段，軟件的開發和維護還未進入穩定狀態，其版本發布還未處于正常狀態，因此我們對這一部分數據不予考慮，而從軟件管理團隊開始有規律性地發布版本開始。

? 只保留正式版本：在發布正式版本前，項目管理管理團隊還會發布一些測試版本，而測試版本的發布較為隨意一些，同時也過于頻繁。因此，我們在實驗中只保留了正式發布的版本而去掉了測試版本。過濾方式是使用文本分析的技術，判斷每一個版本發布的后綴名是否以數字結尾，并且不包含“beta”字樣。

? 只保留有效版本間的貢獻數據：在確定了有效的正式版本后，我們定位出最老版本和最新版本，并只保留這兩個版本之間的貢獻數據。

最終，我們共收集了174個軟件版本發布數據以及103 892個貢獻數據。

1.2 軟件版本發布與第一次評估反饋延遲的關聯分析

為評估軟件版本發布對開源社區貢獻第一次評估反饋延遲的影響，我們首先定義了以下三個變量。

(1) 版本發布周期：

RC(i)=Time(Ri+1)-Time(Ri)

(1)

式中：Ri表示按照時間順序排列的第i個版本，而Time函數用于返回所傳遞參數的創建時間點。因此，發布周期RC表示兩個相鄰版本的時間間隔差。

(2) 發布后提交相對間隔：

(2)

式中：P表示處于版本Ri和Ri+1這時間段時，開源社區開發者所提交的某次貢獻。因此，發布后提交相對間隔RI(i,R)表示的是：以上一個版本為基準點，貢獻P在本次周期內是哪個階段提交的。當RI取值為0時，表明貢獻P是在上一個版本發布時被提交的；而當RI取值為1時，表明貢獻P是在本次發布周期的結尾，也就是下一個版本發布時被提交的。

(3) 評估延遲：

ED(P)=Time(CMTfirst(P))-Time(P)

(3)

式中:CMTfirst函數用于返回某次開源貢獻所接受到的第一個反饋，因此評估延遲ED表示從貢獻P被提交開始，到它接收到第一個評估的時間延遲。對于每一條開源貢獻數據，我們計算它的發布后相對間隔和評估延遲，然后分析它們之間的關聯關系。

1.3 軟件版本發布與貢獻接受概率的關聯分析

為評估軟件版本發布對開源貢獻接受概率的影響，我們首先定義了如下變量(發布后評估相對間隔)：

(4)

式中：TimeD函數用于返回開源貢獻P的評估結果時間點。因此RID(i,P)的含義類似于式(2)中RI(i,P)的含義，只是P的分析時間發生了變化。

接著，我們統計了以下兩組數據。

(1) 被合并的貢獻分布數據:

(2) 被關閉的貢獻分布數據:

在上面兩組數據中，RID表示發布后相對間隔的取值分布，而Countaccepted和Countrejected分別表示被接受的和被關閉的開源貢獻在RID下的數量分布。進而，我們對這兩組數據進行對比統計，分析軟件版本發布是如何影響開源貢獻的接受概率的。

2 研究結果

2.1 研究問題1

發布后提交相對間隔和評估延遲的關聯關系如圖3所示。可以看出，當發布后相對間隔取值在0.5左右或者1.0左右時，開源貢獻的第一次評估反饋延遲較小；而當發布后提交相對間隔取其他值時，反饋延遲具有波動性，不過在0.0附近時反饋延遲相對穩定地維持在一個較高水平上。

圖3 軟件版本發布與第一次評估反饋的關系

由以上實驗觀察我們可以得到初步的結論：在一個軟件版本發布周期內，在后半期提交的開源貢獻更有可能得到及時的反饋，而在前半周期提交的開源貢獻的反饋延遲則更長一些。對于這種現象，一種可能的解釋是在軟件版本發布前，項目管理團隊需要對項目整體的動態進行全局把握，并且由于籌劃版本發布的事務，管理團隊可能會有更多的時間關注項目，從而有更多的機會注意到開源貢獻者所提交的工作，從而給予及時的反饋。

2.2 研究問題2

發布后相對間隔與開源貢獻的接受概率的對應關系如圖4所示。可以看出，雖然開源開發者的貢獻的接受率大體維持在40%～50%之間，但確實也存在著一定的變化。尤其是在發布后評估相對間隔取值在[0.9,1.0]區間時，開源貢獻的接受率是最低的；而當發布后評估相對間隔在較小區間取值時，開源貢獻的接受率相對是高一些的。

圖4 軟件版本發布與貢獻合并概率的對應關系

由以上實驗觀察我們可以得到初步的結論：在軟件版本發布前，項目管理團隊對開源貢獻持謹慎態度，更傾向于拒絕而不是接受；而在版本發布后，項目管理團隊對開源貢獻持相對樂觀一些的態度，具有更高的概率去接受開源貢獻。對于這種現象，一種可能的解釋是在軟件版本發布前，項目管理團隊更希望發布一個穩定的版本，而不是額外接受一個開源貢獻，從而承擔更多的不可控的風險。而在版本發布后，項目管理的緊張氛圍有所緩解，同時又有后續充裕的時間對開源貢獻和合并效果進行監控，因此管理團隊有更高一些的概率去接受一個開源貢獻。

3 實踐建議

根據實驗結果，我們對開源社區的參與者提出了針對性的實踐建議，以促進開源社區更高效的健康發展。

3.1 面向管理者

對于開源軟件項目的管理者來說，管理項目的版本發布以及管理開發社區開發者的貢獻均為及其重要的事務。項目的版本發布管理是軟件能夠階段性有序演化的必要手段，開源社區的貢獻管理是軟件能夠持續發展的重要條件。然而管理團隊的時間和精力是有限的，因此如何平衡好軟件版本發布和社區貢獻評估對于開源軟件的發展是至關重要的。

就實際情況而言，軟件版本發布管理是一個階段性的集中工作，而社區貢獻評估是一個持續性的工作，因此這兩類工作的沖突不是一直存在的，只有在需要對軟件版本發布進行規劃和操作時才有可能發生。因此為了避免兩類工作的沖突，開源軟件的管理團隊可以指派專人負責版本管理，而其他人則更加專注社區貢獻的管理，這樣既可以保證版本發布的質量，也可以保證社區貢獻評估的及時反饋。此外，在版本發布期間，可以把不太確定的社區貢獻接受到測試版本中而不是拒絕該貢獻，這樣既能保證發布版本的穩定性，又能吸收社區的貢獻。

3.2 面向貢獻者

對于貢獻者來說，他們所關注的不應該僅僅在提交的貢獻本身，還要對開源軟件項目的整體發展和規劃有更進一步的認識。在提交貢獻時不干擾項目的版本發布規劃，或者不被項目的版本規劃所影響，盡量在版本發布空窗期提交貢獻，提高自己被接納的概率。此外，如果自己所提交的貢獻沒有得到及時的反饋，不要輕易遷怒于項目的管理團隊，指責其響應時效低，并放棄對貢獻的持續關注和必要更新，這會對項目的環境建設帶來負面的影響，應該要考慮客觀情況，積極應對。

4 相關工作

4.1 開源軟件/社區

開源軟件的快速發展吸引了大量研究人員的關注。楊波等[8]對托管在GitHub平臺中開源軟件開發過程中產生的數據進行分析并提取了多種類型的指標因素，例如問題解決速度和提交增加速度等，他們對這些因素之間的相關性展開了研究。孫晶等[9]提出了開源軟件的可信性模型，定義了開源軟件的可信屬性及組件可信性，通過火狐瀏覽器驗證了模型的有效性。劉雅新等[10]通過挖掘開源項目郵件列表信息與版本提交日志信息,構建了開發者的合作網絡,基于此網絡他們分別分析了開發者整體活躍度以及個體開發者活躍度的變化趨勢。O’Mahony等[11]研究了開源社區的治理模式。楊彬[12]研究了開源世界的許可證機制的發展歷史以及應用現狀。Mocus等[13]選取兩個著名的開源軟件Apache和Mozilla為研究對象調研了開源軟件的實際開發過程。

4.2 貢獻評估

由于開源開發者群體數量巨大，其編程水平層次不齊，為了保證其所提交貢獻的質量，開源社區需要對其貢獻進行評估，這其中會涉及到一些任務指派和推薦等工作。盧松等[14]利用信息檢索技術,綜合考慮了開發者的影響力因子以及評估的時間衰減的因素,為每一個新提交的開源貢獻自動推薦最合適的評估者。張文等[15]提出一種基于K最近鄰算法的缺陷修復人推薦方法OSDR，該方法首先計算給定的缺陷報告與歷史缺陷報告之間的文本相似度,然后利用K最近鄰算法計算相似度最高的K個歷史缺陷報告及其對應的修復人列表。Bosu等[16]研究了開發者的個人聲譽是如何影響貢獻評估結果的，發現核心開發者能夠得到更及時的評估反饋，并且核心開發者的評估耗時較短，被接受的概率也更大。Beller等[17]對真實開源項目的貢獻評估記錄數據進行了實證研究，深入分析了貢獻評估者的實際關注點。Hamasaki等[18]基于代碼倉庫和代碼審查系統構建了四個開源軟件代碼評估的公開數據庫。

4.3 軟件開發管理

軟件開發往往需要多個開發者一起協同完成某項任務，同時開發過程中會遇到需求變更、人員流動等問題，因此為了保證項目能夠有效推進，需要對軟件的開發過程和開發規劃進行管理。楊崑等[19]調研了軟件開發過程中開發團隊常見的溝通與協調活動，并分析了能夠影響開發團隊溝通與協調活動的項目特征以及溝通協調活動與項目的輸出之間的關系。鄒筱菁等[20]深入分析了基于DevOps開發模式下的軟件開發流程,并對相應步驟給出了規范示例。王曉凱[21]探討了在項目管理過程里出現的常見問題并給出了針對性的解決策略。Münch等[22]從軟件開發過程的基本概念入手，著重介紹了現在具有代表性的集中軟件開發過程模型以及每一種模型所需的執行方法和必要工具。

5 結 語

本文選取了GitHub平臺上三個流行開源軟件bootstrap、scikit-learn以及elasticsearch作為實驗對象，采集了這些項目的軟件版本發布數據以及社區貢獻數據。基于采集的數據，對開源軟件版本發布與開源社區貢獻的評估展開了實證研究。重點分析了開源軟件版本發布對開源貢獻第一次評估反饋、開源貢獻接受概率的影響，我們發現：

1) 臨近軟件版本發布時間點前所提交的社區貢獻的第一次評估延遲更低一些。而在軟件版本發布剛結束后所提交的社區貢獻的第一次評估延遲則要高一些。

2) 臨近軟件版本發布時間點前所提交的社區貢獻被接受的概率更低一些。而在版本發布后所提交的社區貢獻被接受的概率要高一些。

另外，根據實驗結果我們還對開源軟件管理者以及貢獻者的行為模式以及協作理念提出了針對性的建議。

在將來的工作中，我們計劃進一步研究開源軟件版本發布對開源社區貢獻類型的接受偏好，即修復軟件缺陷的貢獻以及實現新特征的貢獻的接受率是如何受開源軟件版本發布的影響的。