董 晨 尹 剛

1(天津理工大學(xué)計(jì)算機(jī)科學(xué)與工程學(xué)院天津市智能計(jì)算及軟件新技術(shù)重點(diǎn)實(shí)驗(yàn)室 天津 300384)2(國防科技大學(xué)計(jì)算機(jī)學(xué)院復(fù)雜系統(tǒng)軟件工程湖南省重點(diǎn)實(shí)驗(yàn)室 湖南 長沙 410073)

0 引 言

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

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

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

研究問題1:開源軟件版本發(fā)布對(duì)開源社區(qū)貢獻(xiàn)第一次評(píng)估反饋延遲的影響。

研究問題2:開源軟件版本發(fā)布對(duì)開源社區(qū)貢獻(xiàn)接受概率的影響。

通過這些研究，我們深入分析了開源軟件版本發(fā)布與開源社區(qū)開發(fā)者貢獻(xiàn)評(píng)估的關(guān)聯(lián)關(guān)系。與此同時(shí)，我們也對(duì)開源社區(qū)提出了相應(yīng)的實(shí)踐建議，以促進(jìn)開源社區(qū)的健康持續(xù)發(fā)展。

1 研究方法

如圖1所示，我們首先構(gòu)建開源軟件版本發(fā)布與社區(qū)貢獻(xiàn)數(shù)據(jù)集，然后基于此數(shù)據(jù)集分別開展兩方面的研究：1) 軟件版本發(fā)布與第一次評(píng)估反饋延遲的關(guān)聯(lián)分析；2) 軟件版本發(fā)布與貢獻(xiàn)接受概率的關(guān)聯(lián)分析。

圖1 研究方法概覽

1.1 數(shù)據(jù)集構(gòu)建

(1) 調(diào)研項(xiàng)目。GitHub是目前最火的開源社區(qū)，它為開源軟件提供源代碼托管、開發(fā)任務(wù)管理等一系列功能和服務(wù)，目前已經(jīng)托管了超過一千多萬的開源軟件項(xiàng)目。鑒于GitHub平臺(tái)是極具代表性的開源社區(qū)平臺(tái)，我們選取它作為我們的調(diào)研平臺(tái)，并在該平臺(tái)上進(jìn)一步選取了要具體分析的開源軟件。我們設(shè)定的軟件篩選標(biāo)準(zhǔn)為：

? 軟件版本發(fā)布頻繁。

? 軟件比較流行，參與的開源開發(fā)者數(shù)量大。

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

表1 調(diào)研項(xiàng)目的基本信息

表2 調(diào)研項(xiàng)目的流行度指標(biāo)

(2) 原始數(shù)據(jù)采集。如圖2所示，我們通過Github網(wǎng)站提供的數(shù)據(jù)服務(wù)接口采集實(shí)驗(yàn)所需的原始數(shù)據(jù)。Github提供了豐富的接口以獲取其網(wǎng)站的各種數(shù)據(jù)，其中社區(qū)貢獻(xiàn)數(shù)據(jù)通過接口“/repos/:owner/:repo/pulls”采集，版本發(fā)布數(shù)據(jù)通過接口“/repos/:owner/:repo/releases”采集。采集到的數(shù)據(jù)存儲(chǔ)于關(guān)系型數(shù)據(jù)庫MySQL中。

圖2 數(shù)據(jù)采集方案

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

? 剔除起始階段的數(shù)據(jù)：由于在軟件發(fā)展的起始階段，軟件的開發(fā)和維護(hù)還未進(jìn)入穩(wěn)定狀態(tài)，其版本發(fā)布還未處于正常狀態(tài)，因此我們對(duì)這一部分?jǐn)?shù)據(jù)不予考慮，而從軟件管理團(tuán)隊(duì)開始有規(guī)律性地發(fā)布版本開始。

? 只保留正式版本：在發(fā)布正式版本前，項(xiàng)目管理管理團(tuán)隊(duì)還會(huì)發(fā)布一些測試版本，而測試版本的發(fā)布較為隨意一些，同時(shí)也過于頻繁。因此，我們在實(shí)驗(yàn)中只保留了正式發(fā)布的版本而去掉了測試版本。過濾方式是使用文本分析的技術(shù)，判斷每一個(gè)版本發(fā)布的后綴名是否以數(shù)字結(jié)尾，并且不包含“beta”字樣。

? 只保留有效版本間的貢獻(xiàn)數(shù)據(jù)：在確定了有效的正式版本后，我們定位出最老版本和最新版本，并只保留這兩個(gè)版本之間的貢獻(xiàn)數(shù)據(jù)。

最終，我們共收集了174個(gè)軟件版本發(fā)布數(shù)據(jù)以及103 892個(gè)貢獻(xiàn)數(shù)據(jù)。

1.2 軟件版本發(fā)布與第一次評(píng)估反饋延遲的關(guān)聯(lián)分析

為評(píng)估軟件版本發(fā)布對(duì)開源社區(qū)貢獻(xiàn)第一次評(píng)估反饋延遲的影響，我們首先定義了以下三個(gè)變量。

(1) 版本發(fā)布周期：

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

(1)

式中：Ri表示按照時(shí)間順序排列的第i個(gè)版本，而Time函數(shù)用于返回所傳遞參數(shù)的創(chuàng)建時(shí)間點(diǎn)。因此，發(fā)布周期RC表示兩個(gè)相鄰版本的時(shí)間間隔差。

(2) 發(fā)布后提交相對(duì)間隔：

(2)

式中：P表示處于版本Ri和Ri+1這時(shí)間段時(shí)，開源社區(qū)開發(fā)者所提交的某次貢獻(xiàn)。因此，發(fā)布后提交相對(duì)間隔RI(i,R)表示的是：以上一個(gè)版本為基準(zhǔn)點(diǎn)，貢獻(xiàn)P在本次周期內(nèi)是哪個(gè)階段提交的。當(dāng)RI取值為0時(shí)，表明貢獻(xiàn)P是在上一個(gè)版本發(fā)布時(shí)被提交的；而當(dāng)RI取值為1時(shí)，表明貢獻(xiàn)P是在本次發(fā)布周期的結(jié)尾，也就是下一個(gè)版本發(fā)布時(shí)被提交的。

(3) 評(píng)估延遲：

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

(3)

式中:CMTfirst函數(shù)用于返回某次開源貢獻(xiàn)所接受到的第一個(gè)反饋，因此評(píng)估延遲ED表示從貢獻(xiàn)P被提交開始，到它接收到第一個(gè)評(píng)估的時(shí)間延遲。對(duì)于每一條開源貢獻(xiàn)數(shù)據(jù)，我們計(jì)算它的發(fā)布后相對(duì)間隔和評(píng)估延遲，然后分析它們之間的關(guān)聯(lián)關(guān)系。

1.3 軟件版本發(fā)布與貢獻(xiàn)接受概率的關(guān)聯(lián)分析

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

(4)

式中：TimeD函數(shù)用于返回開源貢獻(xiàn)P的評(píng)估結(jié)果時(shí)間點(diǎn)。因此RID(i,P)的含義類似于式(2)中RI(i,P)的含義，只是P的分析時(shí)間發(fā)生了變化。

接著，我們統(tǒng)計(jì)了以下兩組數(shù)據(jù)。

(1) 被合并的貢獻(xiàn)分布數(shù)據(jù):

(2) 被關(guān)閉的貢獻(xiàn)分布數(shù)據(jù):

在上面兩組數(shù)據(jù)中，RID表示發(fā)布后相對(duì)間隔的取值分布，而Countaccepted和Countrejected分別表示被接受的和被關(guān)閉的開源貢獻(xiàn)在RID下的數(shù)量分布。進(jìn)而，我們對(duì)這兩組數(shù)據(jù)進(jìn)行對(duì)比統(tǒng)計(jì)，分析軟件版本發(fā)布是如何影響開源貢獻(xiàn)的接受概率的。

2 研究結(jié)果

2.1 研究問題1

發(fā)布后提交相對(duì)間隔和評(píng)估延遲的關(guān)聯(lián)關(guān)系如圖3所示。可以看出，當(dāng)發(fā)布后相對(duì)間隔取值在0.5左右或者1.0左右時(shí)，開源貢獻(xiàn)的第一次評(píng)估反饋延遲較?。欢?dāng)發(fā)布后提交相對(duì)間隔取其他值時(shí)，反饋延遲具有波動(dòng)性，不過在0.0附近時(shí)反饋延遲相對(duì)穩(wěn)定地維持在一個(gè)較高水平上。

圖3 軟件版本發(fā)布與第一次評(píng)估反饋的關(guān)系

由以上實(shí)驗(yàn)觀察我們可以得到初步的結(jié)論：在一個(gè)軟件版本發(fā)布周期內(nèi)，在后半期提交的開源貢獻(xiàn)更有可能得到及時(shí)的反饋，而在前半周期提交的開源貢獻(xiàn)的反饋延遲則更長一些。對(duì)于這種現(xiàn)象，一種可能的解釋是在軟件版本發(fā)布前，項(xiàng)目管理團(tuán)隊(duì)需要對(duì)項(xiàng)目整體的動(dòng)態(tài)進(jìn)行全局把握，并且由于籌劃版本發(fā)布的事務(wù)，管理團(tuán)隊(duì)可能會(huì)有更多的時(shí)間關(guān)注項(xiàng)目，從而有更多的機(jī)會(huì)注意到開源貢獻(xiàn)者所提交的工作，從而給予及時(shí)的反饋。

2.2 研究問題2

發(fā)布后相對(duì)間隔與開源貢獻(xiàn)的接受概率的對(duì)應(yīng)關(guān)系如圖4所示?？梢钥闯觯m然開源開發(fā)者的貢獻(xiàn)的接受率大體維持在40%～50%之間，但確實(shí)也存在著一定的變化。尤其是在發(fā)布后評(píng)估相對(duì)間隔取值在[0.9,1.0]區(qū)間時(shí)，開源貢獻(xiàn)的接受率是最低的；而當(dāng)發(fā)布后評(píng)估相對(duì)間隔在較小區(qū)間取值時(shí)，開源貢獻(xiàn)的接受率相對(duì)是高一些的。

圖4 軟件版本發(fā)布與貢獻(xiàn)合并概率的對(duì)應(yīng)關(guān)系

由以上實(shí)驗(yàn)觀察我們可以得到初步的結(jié)論：在軟件版本發(fā)布前，項(xiàng)目管理團(tuán)隊(duì)對(duì)開源貢獻(xiàn)持謹(jǐn)慎態(tài)度，更傾向于拒絕而不是接受；而在版本發(fā)布后，項(xiàng)目管理團(tuán)隊(duì)對(duì)開源貢獻(xiàn)持相對(duì)樂觀一些的態(tài)度，具有更高的概率去接受開源貢獻(xiàn)。對(duì)于這種現(xiàn)象，一種可能的解釋是在軟件版本發(fā)布前，項(xiàng)目管理團(tuán)隊(duì)更希望發(fā)布一個(gè)穩(wěn)定的版本，而不是額外接受一個(gè)開源貢獻(xiàn)，從而承擔(dān)更多的不可控的風(fēng)險(xiǎn)。而在版本發(fā)布后，項(xiàng)目管理的緊張氛圍有所緩解，同時(shí)又有后續(xù)充裕的時(shí)間對(duì)開源貢獻(xiàn)和合并效果進(jìn)行監(jiān)控，因此管理團(tuán)隊(duì)有更高一些的概率去接受一個(gè)開源貢獻(xiàn)。

3 實(shí)踐建議

根據(jù)實(shí)驗(yàn)結(jié)果，我們對(duì)開源社區(qū)的參與者提出了針對(duì)性的實(shí)踐建議，以促進(jìn)開源社區(qū)更高效的健康發(fā)展。

3.1 面向管理者

對(duì)于開源軟件項(xiàng)目的管理者來說，管理項(xiàng)目的版本發(fā)布以及管理開發(fā)社區(qū)開發(fā)者的貢獻(xiàn)均為及其重要的事務(wù)。項(xiàng)目的版本發(fā)布管理是軟件能夠階段性有序演化的必要手段，開源社區(qū)的貢獻(xiàn)管理是軟件能夠持續(xù)發(fā)展的重要條件。然而管理團(tuán)隊(duì)的時(shí)間和精力是有限的，因此如何平衡好軟件版本發(fā)布和社區(qū)貢獻(xiàn)評(píng)估對(duì)于開源軟件的發(fā)展是至關(guān)重要的。

就實(shí)際情況而言，軟件版本發(fā)布管理是一個(gè)階段性的集中工作，而社區(qū)貢獻(xiàn)評(píng)估是一個(gè)持續(xù)性的工作，因此這兩類工作的沖突不是一直存在的，只有在需要對(duì)軟件版本發(fā)布進(jìn)行規(guī)劃和操作時(shí)才有可能發(fā)生。因此為了避免兩類工作的沖突，開源軟件的管理團(tuán)隊(duì)可以指派專人負(fù)責(zé)版本管理，而其他人則更加專注社區(qū)貢獻(xiàn)的管理，這樣既可以保證版本發(fā)布的質(zhì)量，也可以保證社區(qū)貢獻(xiàn)評(píng)估的及時(shí)反饋。此外，在版本發(fā)布期間，可以把不太確定的社區(qū)貢獻(xiàn)接受到測試版本中而不是拒絕該貢獻(xiàn)，這樣既能保證發(fā)布版本的穩(wěn)定性，又能吸收社區(qū)的貢獻(xiàn)。

3.2 面向貢獻(xiàn)者

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

4 相關(guān)工作

4.1 開源軟件/社區(qū)

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

4.2 貢獻(xiàn)評(píng)估

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

4.3 軟件開發(fā)管理

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

5 結(jié) 語

本文選取了GitHub平臺(tái)上三個(gè)流行開源軟件bootstrap、scikit-learn以及elasticsearch作為實(shí)驗(yàn)對(duì)象，采集了這些項(xiàng)目的軟件版本發(fā)布數(shù)據(jù)以及社區(qū)貢獻(xiàn)數(shù)據(jù)?；诓杉臄?shù)據(jù)，對(duì)開源軟件版本發(fā)布與開源社區(qū)貢獻(xiàn)的評(píng)估展開了實(shí)證研究。重點(diǎn)分析了開源軟件版本發(fā)布對(duì)開源貢獻(xiàn)第一次評(píng)估反饋、開源貢獻(xiàn)接受概率的影響，我們發(fā)現(xiàn)：

1) 臨近軟件版本發(fā)布時(shí)間點(diǎn)前所提交的社區(qū)貢獻(xiàn)的第一次評(píng)估延遲更低一些。而在軟件版本發(fā)布剛結(jié)束后所提交的社區(qū)貢獻(xiàn)的第一次評(píng)估延遲則要高一些。

2) 臨近軟件版本發(fā)布時(shí)間點(diǎn)前所提交的社區(qū)貢獻(xiàn)被接受的概率更低一些。而在版本發(fā)布后所提交的社區(qū)貢獻(xiàn)被接受的概率要高一些。

另外，根據(jù)實(shí)驗(yàn)結(jié)果我們還對(duì)開源軟件管理者以及貢獻(xiàn)者的行為模式以及協(xié)作理念提出了針對(duì)性的建議。

在將來的工作中，我們計(jì)劃進(jìn)一步研究開源軟件版本發(fā)布對(duì)開源社區(qū)貢獻(xiàn)類型的接受偏好，即修復(fù)軟件缺陷的貢獻(xiàn)以及實(shí)現(xiàn)新特征的貢獻(xiàn)的接受率是如何受開源軟件版本發(fā)布的影響的。