開源軟件社區開發者角色的演化分析

汪文娟，李 兵，2，何 鵬

（1.武漢大學a.軟件工程國家重點實驗室；b.復雜網絡研究中心，武漢430072；2.南京財經大學江蘇省電子商務重點實驗室，南京210046）

0 引言

近年來，物聯網、云計算技術等互聯網應用逐漸深入和推廣，引發了軟件技術的變革，為適應海量信息處理、用戶需求的個性化和多元化、軟件的服務化，新型軟件工程——群體軟件工程［1］應運而生，實現了軟件開發過程從封閉到開放，人員從精英到大眾，組織從工廠到社群，方法從機器工程到社會工程的轉變。典型的群體軟件開發實例，有蘋果的App Store和谷歌的Android應用商店。隨著軟件工程的轉型，軟件系統的規模越來越大且開發過程越來越復雜，面對群體軟件開發的這一復雜特征，將軟件工程與“網絡科學”相結合，應用網絡智能方法，開展對項目開發過程中面向群體的行為分析，為群體軟件開發特性研究和質量保證提供有力支撐。

復雜網絡與軟件工程的交叉研究已引起了眾多學者的關注與認可，相關研究成果［2－3］已發表在軟件工程領域的權威期刊上，具有廣闊的發展前景。軟件網絡的研究結合了復雜網絡和軟件工程理論，它以軟件系統的結構特征為切入點，將復雜網絡的理論應用到軟件工程領域，研究軟件這一類型的人工設計實現的系統是否也像社會和自然界中的網絡一樣具有復雜網絡的特性。目前，軟件網絡研究主要是對已有軟件采用逆向工程方法得出其中的組織結構進行分析，發現其中的復雜網絡特性，反映軟件系統的一些整體度量性質。隨著軟件的網絡化趨勢越來越明顯，軟件與網絡的關系更加密不可分，用網絡的觀點來分析軟件，為軟件工程實踐提供了新的視角，也是現今軟件工程主要研究的問題之一。但軟件開發是一個社會性（“人”）和技術性（“軟件”和“網絡”）匯聚［4］的過程，很多研究只是從技術性出發，探索了軟件系統技術維度的復雜性，而軟件開發是一項人工參與的活動，還涉及各類行為者的貢獻，即軟件開發的社會性，只有結合社會網絡分析，才能使得網絡化環境下軟件的各個組成部分構成一個完整的生態系統。

軟件是由人開發的系統，是一個人與人交互的網絡，系統的結構、功能和演化方向與人的交互有著密切的關聯。軟件的結構可視為開發者間關系的一種折射。開發者合作關系的變動與軟件的演化之間存在決定與反作用的關系。通過分析開發者網絡的演化過程，挖掘出開發者在軟件開發過程中的協作行為、活躍程度、貢獻價值，為管理者及其他開發人員的開發行為提供決策參考。

在對軟件進行分析時已有研究遇到了很多難題，例如，軟件系統的數據很難得到，很少有現存的相關理論可供參考，開發者的邊緣學習以及團隊人員間的遷移融合過程。幸運的是，開源軟件的廣泛流行與發展，相比與商業軟件，它更能滿足人們的需要，促使越來越多的人自愿參與到開源軟件社區中。開源軟件的繁榮使得我們能夠便捷、快速地獲取到大量相關的數據，從而進行相關的研究。通常一個成功的開源軟件在其生命周期中都會有一系列版本，針對軟件的每個版本，我們構造相應的開發者網絡，本文把開發者視為節點，把從事于同一個組件或包、類、方法開發的開發者間視為有一條合作邊，構建開發者網絡。引入開發者活躍度指標，通過該指標探析社區開發者的角色演化趨勢。本文對一個成功的開源軟件Tomcat（http：／／tomcat.apache.org／）的10個版本的開發者網絡進行實例分析。

據了解，關于開源軟件社區開發者的角色劃分，Nakakoji等［5］把開源軟件項目劃分為3類并提出將角色劃分為8類，即：被動用戶、積極用戶、bug報告員、bug修復員、邊緣開發者、積極的開發者、核心人員、項目經理。作者只是簡單地根據節點度對開發者進行角色劃分，而衡量節點重要性的指標目前已有很多，僅通過節點度無法很好地刻畫節點的重要性，因此，本文提出了一個活躍度指標用于衡量開發者的活躍性，便于角色演化分析。另外，Xu等［6－7］進一步對開發者的角色進行劃分，數量由8類簡化為5類，最后又進一步簡化為4類角色：即積極用戶，核心開發者，合作者，項目經理。Borgatti［8］最早提出網絡的核心－邊緣結構概念，并提出算法和測試驗證該結構的正確性。Crowston等［9］根據bug修復信息構建網絡，闡述了開源軟件開發團隊中的核心－邊緣結構，提出一種確定開發團隊核心成員的有效方法。Sureka等［10］挖掘缺陷追蹤系統中的信息，發現開發者合作網絡的洋蔥結構，并把開發者分為核心、半邊緣、邊緣三類。除此之外，Pinzger等［11］研究了開發者貢獻網絡與軟件發布后缺陷數的關系，使用網絡中心性指標衡量貢獻網絡的重要程度，指出中心模塊比非中心模塊有更多的缺陷傾向。在文獻［12］中，Crowston論證了中心性在跨項目和時間上的分布，實證了項目的核心成員變動情況相對比較少，而且參與跨項目社區的情況也不多見。Wiggins等［13］對Fire和Gain兩個項目的中心勢動態做了研究，發現兩個項目均隨時間變化趨向于分散化。Huang等［14］指出在開源軟件網絡中，節點的重要性遵循二八定律。以上工作主要是用中心性指標來衡量節點的重要性，并用于缺陷分析與網絡整體趨勢分析。他們并沒有關注單個開發者的演化趨勢，以及網絡中典型演化模式的提取。

本文重點對一個項目不同版本階段的開發者網絡中開發者角色進行演化分析，主要貢獻為：1）收集整理了Tomcat 6項目從2006—2010年10個版本的開發者修改日志和郵件列表信息，構建每個版下的開發者網絡，便于后續研究者在提供的數據集上對本工作的重現與更深入的研究；2）提取了5類典型社區開發者演化模式和每類開發者擅長從事的工作類型，有利于開發者的角色預測與任務分配，為管理者提供決策參考。

1 研究方法

首先利用我們團隊開發的聚焦爬蟲工具從svn日志與郵件列表信息中爬取開發者行為數據；然后根據項目的版本信息，把數據劃分為10個連續的版本，并依次根據開發者參與的任務構建10個相應的開發者網絡；基于所得的開發者網絡，對開發者的活躍度進行演化分析，并基于開發者活躍度的演化趨勢把開發者劃分為5種類型，通過分析開發者活躍度與提交日志數之間關系的分布進而衡量開發者貢獻度；最后，通過對日志信息的分類，得到每類開發者在不同任務上的實踐技能。

1.1 開發者網絡模型

本文選取了Apache軟件基金會（ASF）資助的一個典型的開源軟件項目－Tomcat作為實驗案例，采用課題組自行開發的聚焦爬蟲工具爬取Tomcat 6從2006年到2010年的開發者日志和郵件列表信息，主要包括信息的鏈接URL，開發者的姓名，commit的主題及提交時間。根據提供的版本發布信息，將數據劃分為10個版本，考慮到有些版本相距時間只有幾天，我們只選取相隔至少1個月的版本作為實驗版本，因此，表1中第一列只給出每個版本相應的序號。在數據處理過程中，類似于已有文獻的處理方法，只選取了具有提交日志權限的開發者，于是部分邊緣用戶被排除在外，表1給出了每個版本的詳細信息。

在構建開發者網絡過程中，用DevNet＝（V，E），V為網絡的節點集，E為連邊集。網絡中節點代表參與的開發者，如果開發者i，j參與同一工作線程的開發則被視為存在一條合作連邊eij＝1，否則eij＝0，本文沒有考慮兩個開發者間的合作次數，且兩個開發者之間的合作被視為是相互的。圖1是版本1的開發者網絡拓撲結構。

表1 版本信息Tab.1 Version information

圖1 版本1的開發者網絡Fig.1 The developer network of version 1

1.2 活躍度

活躍度是度量開發者的交際范圍以及衡量開發者重要性的指標?；钴S度具體來說，就是開發者與多少人進行過交互。在開發者網絡中，如果一個節點擁有更多的合作對象，那么這個節點所代表的開發者的活躍度越高。反之，活躍度很低的開發者與其他人建立的合作也相對少。因此，活躍度與節點的度息息相關，但又不簡單地等于節點度。本文用Activei表示開發者i的活躍度：

1.3 標準化

在進行數據分析之前，通常要進行數據標準化以減少實驗偏差。已有的標準化方法很多，本文采用Min－Max標準化，Min－Max標準化是對原始數據進行線性變換。設Min和Max分別為網絡中所有節點Active指標值的最小值和最大值，將Active的一個原始值x通過Min－Max標準化映射成在區間［0，1］中的值x′：

對活躍度標準化后，計算相應的rank值，即若Active′i∈［k，k＋0.1），0≤k≤0.9，則ranki＝k＊10＋1。最后，根據rank值找到對應的活躍度等級?；钴S度等級劃分的標準：7≤rank≤10，等級為高；4≤rank≤6，等級為中；1≤rank≤3，等級為低。

1.4 日志信息類型

在文獻［15］中，作者對5個開源軟件的bug庫進行分析，發現很多bug報告實際上并不是修復bug，而是提出一個新功能或者提高系統性能等。他采用人工對bug報告進行分類的方法，探究誤分類對缺陷預測的影響。類似于該文獻，我們對開發者日志信息類型分為6大類：BUG類，日志記錄了糾正性的維護任務：對源代碼進行語義上的更改；RFE類，日志記錄了適應性的維護任務：增加新功能；IMPR類，日志記錄了完備性的維護任務：提高系統整體性能；DOC類，日志記錄了外部網站或代碼文檔的更新；REFAC類，日志記錄了重構源代碼的問題，通常由開發者提交；OTHER類，日志記錄了代碼移植，代碼清理，規范更改（非文檔和代碼），測試用例。

日志信息的分類規則為：如果出現空指針異常NullpointerException源代碼，需要進行語義上的更改缺陷導致運行時間或內存出現問題，該日志歸類為BUG；如果出現非最優算法和垃圾收集策略導致的資源問題（時間，內存）要求對代碼，日志信息，文檔信息，異常信息，屬性字段進行非語義上的修改或修復要求增加或刪除文檔和日志信息要求更新文檔或日志信息的內容要求改變拋出異常的類型或信息要求變更支持新的輸入和輸出格式介紹已有功能的并發版本建議升級或修補第三方庫去解決問題要求按照規約／文檔修正已經實現的功能，該日志歸類為IMPR（改進請求）；如果要求實現一個新的接口或方法要求增加新功能要求支持新的對象類型，規范或標準，該日志歸類為RFE（功能請求）；如果由于丟失文檔或文檔過時而提交報告請求更新文檔或增刪文檔請求更新外部網站，該日志歸類為DOC（文檔請求）；如果請求將代碼移動到其他包，類或方法中請求為變量，方法，類，包或配置文件重命名請求屬性在不同環境中的通用，該日志歸類為REFAC（重構請求）；如果報告了違反java合同但是沒有導致異常的事件有關兼容性修補程序的建議任務不需要修改源代碼或文檔（如包裝，配置，下載），該日志歸類為OTHER。

按照以上規則對日志信息分類，便于后續部分對不同角色演化模式的開發者所從事的工作進行對比分析。

2 實證分析

實驗對象的選取是影響實證分析結果的重要因素之一，本文定義了一些篩選標準用于實驗的軟件系統，比如版本的數量，參與的開發者人數，演化周期，最終選取Tomcat項目為實證對象展開分析。

2.1 開發者活躍度的演化

軟件需求的改變，功能的增加或刪除等，促使軟件開發和維護成為一個不斷演進的過程，而整個過程中開發者間由于合作形成一個合作網絡。隨著開發者合作網絡的演化，開發者活躍度也在不停的改變?；钴S度的改變意味著開發者在團隊中角色地位可能也會發生改變，實時地掌控開發者的角色能有效執行任務分配，為軟件開發與維護帶來便利。

據1.3中提到的根據rank值把活躍度劃分為3個等級：高、中、低。通過對數據的初步分析，發現在項目演化過程中，每個版本中都存在開發者的加入和離去，而且有一小部分開發者僅在某一個版本中參與合作或做出了貢獻。為了進行版本間的開發者活躍度演化分析，本文提取出在這10個開發者合作網絡中都出現過的11名開發者。如果將活躍度演化趨勢相似的開發者歸為一類，則這11名開發者可整體劃分為5類，分別表示為A～E。圖2分別給出了A，B，C，D，E 5類開發者在對應10個版本中的活躍度變化趨勢，其中橫軸表示版本序列號，縱軸表示rank值。

從圖2可發現：A類開發者起初一段時間非?；钴S，后來變得越來越不活躍。充分體現為他們在前5個版本都是處于非?；钴S狀態，隨后逐漸由非?；钴S變為活躍，最后變為不活躍。B類活躍度整體上先增后減。他們的活躍度在第五個版本的時候達到最大，之后下降到最小。他們的活躍度一直處于中等偏下的狀態。C類活躍度整體下降且處于中等偏下的狀態。曲線波動不大，活躍度偏小，整體上是下降的趨勢。D類活躍度整體下降但處于中等偏上的狀態。與C類開發者相似的是，活躍度整體都是下降的趨勢，不同的是，曲線波動較大，活躍度偏大。E類活躍度遞增而且一直處于非?；钴S的狀態。追蹤Mark Thomas的rank值，起初為2，第6個版本已經達到10，且隨后一直保持最大。

這5種演化趨勢呈現的一種可能的解釋是，在每個時間段可能分配給開發者的任務不一樣，由于開發者在不同的工作上能力大小可能也不同，導致活躍度的變化。當分配給他們擅長的工作時，他們的活躍度大，當他們做自己不擅長的工作時活躍度就會變小。為了使所選取的11名開發者的演化模式盡可能代表社區開發者的存在的演化模式，我們還考慮了那些不是在每個開發者網絡中都出現的開發者。如圖2f，可以看到這3個人分別只在軟件開發前期，中期和后期出現，但是他們都能歸到所提取的5類模式中。即Jean－Francois Arcand屬于第二種類型，活躍度先增后減。Johnny Kewl屬于第三種類型，活躍度慢慢減弱且處于中等偏下的狀態。Konstantin Kolinko則屬于第五種類型，活躍度呈遞增的趨勢。這樣進一步驗證了我們對開發者角色類型的劃分在很大程度上具有合理性，為開發者行為預測提供了一種新的視角。

圖2 5種開發者類型Fig.2 Five types of developers

2.2 活躍度與貢獻度的關系

研究活躍度與貢獻度的關系，本文用開發者提交日志數作為衡量開發者貢獻度的指標，開發者提交的日志數越大說明開發者貢獻度越大，于是問題轉化為研究活躍度與提交日志數的關系。我們分別統計了每個版本中rank值為1～10的開發者的平均提交日志數。根據10個版本開發者平均提交日志數隨rank值的變化趨勢，把擁有相同變化規模的版本畫在同一個圖中，如圖3所示，橫軸代表rank值，縱軸表示平均提交日志數。可以看出10個版本中開發者的平均提交日志數隨rank值的變化都呈現指數增長趨勢，說明當開發者的活躍度越大時，他提交的日志越多。一種可能的解釋為，當一個開發者變為活躍時，很大程度上由于當前任務是該開發者所擅長或熟悉的工作，以至于該開發者貢獻越大。反之，當開發者的活躍度小時所做的工作可能是他不太擅長的工作。因此，我們得出兩個結論，活躍度與貢獻度呈指數關系，開發者活躍度的改變意味著開發者角色地位的改變。

2.3 開發者的參與程度

基于2.1節實驗結果，我們發現開發者的活躍度隨時間是動態變化的。因此，為了分析社區中不同角色演化模式下開發者從事的工作類型，有必要研究所得的5類演化模式在不同的工作類型的分布情況。研究每個開發者對不同類型工作的貢獻程度稱之為開發者的專業技能，挖掘出每種工作類型中專業技能最好的開發者，有助于實現人到項目的推薦或者項目到人的推薦。在項目管理過程中，掌握開發團隊中開發者專業技能的優劣勢對項目管理者而言也至關重要，通過活躍度的變化定位開發者的角色演化趨勢，預測開發者的行為便于任務分配。因此，本節重點對每個工作類型中5類開發者的參與程度進行分析。

圖4中，橫坐標代表任務信息的類型，縱坐標代表每類開發者參與某類任務占所有這類任務的百分比。圖中A，B，C，D，E分別對應于圖2中所劃分的5種類型。從工作類型看，不難找出每類日志中提交比例最大的開發者。簡單地說，就是可以找到每個工作類型中參與程度最好的開發者。在圖3中，提交RFE日志比例最大的是B類開發者，說明B類開發者更多從事RFE類型工作。B，C，E 3類開發者在BUG修復過程中比重均相對比較大，并且非常接近，所以，在bug分配時可以考慮優先給這3類的開發者。尤為明顯的是，在DOC和REFAC中，B類和E類開發者比重均超過60%，說明這兩類開發者都集中從事某一類工作，且在圖2中，不難發現，這兩類開發者整體演化趨勢相對比較穩定。

從開發者類型看，可以找出每類開發者提交得最多的日志類型即找出每類開發者的優勢。例如圖4中A類開發者提交的RFE和IMPR日志所占的百分比較其他日志類型大，所以A類開發者的優勢是做RFE和IMPR工作。分析出開發者專業技能的優劣勢，然后根據開發者活躍度的演化趨勢來預測他的角色，以便更好地分配任務。

圖3 10個版本中開發者平均提交日志數隨rank值的變化趨勢Fig.3 The change of the average number of logs commited by developers along with the change of rank in 10versions

3 結束語

根據社區開發者的活躍度演化趨勢，文章把開發者的演化模式劃分為5種類型，每種類型開發者的活躍度表現出不同的變化趨勢。在分析開發者活躍度與貢獻度的關系時，我們發現開發者的活躍度與開發者所提交的日志數呈指數關系，表明交互越活躍的開發者，提供的貢獻也越大。因此，活躍度的改變意味著提交的日志數的改變，相反，可根據開發者提交日志的頻率來預測其角色的改變。在2.1節中，我們得到A類開發者在前5個版本中非?；钴S后來變得越來越不活躍，結合2.3節中的分析，A類開發者更擅長從事RFE和IMPR兩類工作。在實際的軟件開發過程中，在開發前期軟件對提高功能和性能方面的需求更大，而此時A類開發者占主導，所以在圖2a中表現為前5個版本A類開發者的活躍度非常大。在開發中后期，更多的時間會花費在對軟件的測試，重構，修復上，因此他的活躍度會慢慢下降。圖2e描述了E類開發者的活躍度逐漸變大，且隨后保持最大。在統計5類開發者提交的日志數時，我們發現E類開發者提交的日志數非常大，是其他類型開發者提交的日志數的幾倍甚至幾十倍。從圖4不難發現E類開發者對每類工作的貢獻度都不小，這也說明了他是個全能型的人才。在軟件開發的每個階段，他都是核心人物。

實驗結果表明，在不同的項目版本中，根據開發者活躍度的演化趨勢，可將開發者大致劃分為5種典型的演化模式。整體上，越活躍的開發者，提交的日志數也越多，兩者呈指數增長關系。最后，對比不同演化類型的開發者在6類工作上的分布，發現開發者的演化趨勢與軟件開發周期有關，不同的開發者階段由于關注事項的不同，擅長此類事項的開發者開始變得活躍，而已有活躍的開發者開始受到影響，一般的開發者仍然保持穩定的趨勢。總之，我們的工作發現開源社區中開發者的角色隨時間動態變化，表現明顯的學習過程，越活躍的開發者往往貢獻越大，且不同類型的開發者偏好的工作事項也不同。

關于時效網絡，國內外都備受關注，如國內復旦大學的李翔教授團隊，華中師范大學的池麗萍副教授團隊，以及國外知名的巴拉巴西團隊。時效網絡模型可以保留事件的時序信息，能更好地描述動態系統的特征，其比例分布可以揭示不同事件之間隱藏的共性。在我們的演化分析過程中，演化本身就是一個時間序列分析，文章構建的開發者網絡一定程度上就是一個在一段特定時間內交互網絡，而時效網絡是一個更細粒度的網絡，關注開發者網絡構建過程中的這種時間屬性，對開發者角色度量與演化分析會提供一個新的研究視角。

在已取得研究成果的基礎上，本文也存在一些不足之處：首先，所選取的10個版本的時間跨度并不相等，在數據上引入了一些量的偏差，導致版本更新時間跨度不等，但我們的實驗結果表明，這些小的偏差并沒有影響對開發者角色演化分析，所以，文章發現具有一定的代表性。其次，對合作者的定義比較狹隘，我們假設歷史記錄中參與至少同一個工作線程的開發者間存在合作，沒有考慮其他形式的合作，比如論壇中的討論合作，另外，所構建的開發者網絡為無權網絡，無法呈現他們之間的交互次數，但已有文獻中，也有很多研究者采用了類似構建開發者網絡的方法，并被證實這種網絡的有效性。本文只分析了Tomcat軟件，把開發者歸為了5種角色類型，這樣劃分是否具有通用性，代表性，還需要對更多的開源軟件進行實證，如Eclipse，Mozilla等流行的開源軟件。

圖4 每類日志中5類開發者提交日志所占的比例Fig.4 The proportion of logs commited by five types of developers in each type of logs

在接下來的工作中，我們將對比其他度量節點重要性指標對開發者角色演化趨勢的刻畫，比如節點度中心性，介數中心性，特征向量中心性等，驗證文章提取的5類開發者角色演化模式的一般性。目前時效網絡也備受關注，今后我們也將更細粒度地考慮合作網絡的時間屬性，進一步探究角色的演化分析。另外，本文只對Tomcat軟件進行了研究，更多來自不同開發環境，不同語言的開源軟件有待研究。

［1］ Whitehead J，Mistrík I，Grundy J，et al.Collaborative Software Engineering：Concepts and Techniques［M］.Berlin Heidelberg：Springer，2010：1－30.

［2］ Concas G，Marchesi M，Pinna S，et al.Power－Laws in a large object－oriented software system［J］.IEEE Trans On Software Engineering，2007，33（10）：687－708.

［3］ Louridas P，Spinellis D，Vlachos V.Power laws in software［J］.ACM Trans on Software Engineering and Methodology，2008，18（1）：2.

［4］ Kleinberg J.The convergence of social and technological networks［J］.Communications of the ACM，2008，51（11）：66－72.

［5］ Nakakoji K，Yamamoto Y，Kishida K，et al.Evolution patterns of open－source software systems and communities［C］／／Proceedings of the international workshop on Principles of software evolution.ACM，2002：76－85.

［6］ Xu N.An exploratory study of open source software based on public project archives［D］.Concordia University，2003.

［7］ Xu J，Gao Y，Christley S，et al.A topological analysis of the open source software development community［C］／／Proceedings of the 38th Annual Hawaii International Conference on System Sciences.IEEE，2005：4－7.

［8］ Borgatti S，Everett M.Models of Core／Periphery Structures［J］.Social Networks，2000，21（4）：375－395.

［9］ Crowston K，Howison J.Assessing the health of open source communities［J］.Computer，2006，39（5）：89－91.

［10］Sureka A，Goyal A，Rastogi A.Using social network analysis for mining collaboration data in a defect tracking system for risk and vulnerability analysis［C］／／Proceedings of the 4th India Software Engineering Conference.ACM，2011：195－204.

［11］Pinzger M，Nagappan N，Murphy B.Can developer－module networks predict failures［C］／／Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering.ACM，2008：2－12.

［12］Crowston K，Wei K，Li Q，et al.Core and periphery in free／libre and open source software team communications［C］／／Proceedings of the 39th Annual Hawaii International Conference on System Sciences.IEEE，2006，6：118.

［13］Wiggins A，Howison J，Crowston K.Social dynamics of floss team communication across channels［J］.Fourth International Conference on Open Source Software，2008，275（7）：131－142.

［14］Huang S K，Liu K M.Mining version histories to verify the learning process of legitimate peripheral participants［J］.International Conference on Software Engineering，2005，30（4）：1－5.

［15］Herzig K，Just S，Zeller A.It＇s not a bug，it＇s a feature：how misclassification impacts bug prediction［C］／／Proceedings of the 2013International Conference on Software Engineering.IEEE，2013：392－401.