開源生態(tài)系統(tǒng)中項目與開發(fā)者推薦

趙海燕，李 娜，陳慶奎，曹 健

1(上海市現(xiàn)代光學(xué)系統(tǒng)重點實驗室，光學(xué)儀器與系統(tǒng)教育部工程研究中心，上海理工大學(xué)光電信息與計算機工程學(xué)院，上海 200093)

2(上海交通大學(xué) 計算機科學(xué)與技術(shù)系，上海 200030)

1 引 言

在開源生態(tài)系統(tǒng)中，相互依賴的軟件項目形成了協(xié)同發(fā)展的社區(qū)[1].開源社區(qū)的蓬勃發(fā)展吸引了數(shù)量眾多的高水平開發(fā)人員.這些來自不同國家、不同文化與專業(yè)知識背景的開發(fā)者自愿加入社區(qū)，并與其他開發(fā)者建立合作關(guān)系[2]，共同推進項目的開發(fā).

盡管開源社區(qū)發(fā)展迅速，但是由于開源社區(qū)公開、自愿、非盈利等原則，也出現(xiàn)了諸多問題：1)很多項目因未能及時找到合適的開發(fā)者而處于停滯狀態(tài)；2)開發(fā)者也不能準(zhǔn)確找到自己感興趣并能夠勝任的項目；3)95%以上的開發(fā)者只參與了不超過5個項目，大量的人力處于空閑狀態(tài).上述情況之所以存在，一方面是由于開發(fā)者無法通過現(xiàn)有的項目檢索方法找到真正匹配自己技能的項目；另一方面是由于項目負責(zé)人沒能掌握社區(qū)開發(fā)者的興趣、專業(yè)特長以及開發(fā)者的合作偏好.

目前，可用于開發(fā)者及項目推薦的信息來源有用戶(users)、項目(projects)、項目成員(project members)、追隨者(followers)、提交(commit)、評論(comments)、問題(issues)、拉取請求(pull request)等.項目中的成員相互合作，并進行一系列操作對項目進行貢獻.圖1展示了開發(fā)者之間的合作關(guān)系以及進行推薦的幾種可能性，其中成員之間直線連接表示曾有過合作關(guān)系.

圖1 開源社區(qū)中項目與開發(fā)者的關(guān)系

由于開源社區(qū)存在眾多的項目及開發(fā)者，且其興趣是動態(tài)變化的，因此想要精準(zhǔn)地為開發(fā)者推薦項目，或者為項目推薦合適的開發(fā)者是相當(dāng)困難的[3].在此背景下，開源生態(tài)系統(tǒng)中的項目與開發(fā)者推薦具有非常重大的意義.

推薦算法是近年來的熱門研究領(lǐng)域，將推薦算法應(yīng)用于開源生態(tài)系統(tǒng)中，也引起了研究者的廣泛興趣.有些推薦系統(tǒng)的典型方法已經(jīng)被用于項目及開發(fā)者推薦，如，基于內(nèi)容的推薦、基于協(xié)同過濾與內(nèi)容的混合推薦、基于社交網(wǎng)絡(luò)的推薦等.許多研究者在通用的推薦系統(tǒng)模型基礎(chǔ)上，加以針對性的改進，使得其推薦模型具有更好的性能.

為了對開源生態(tài)中的項目與開發(fā)者推薦進行更為合理的評估并分析其未來的研究方向，本論文首先總結(jié)了開源項目中項目、開發(fā)者的特性，在此基礎(chǔ)上，分別對項目推薦、開發(fā)者推薦進行了介紹，最后，文章對未來的研究方向進行了討論.

2 開源項目中的項目與成員特性

2.1 項目特征

在開源項目中，無論進行項目推薦或是開發(fā)者推薦，項目特征與開發(fā)者特征都是相互依賴的.項目(projects)中包含的信息有項目id、url、創(chuàng)建者id、項目名稱、項目描述、語言、創(chuàng)建時間等.自述文件主要是開發(fā)者對一個項目的實現(xiàn)目標(biāo)及實現(xiàn)過程進行描述.社區(qū)中的成員可以通過檢索關(guān)鍵字搜索自己感興趣的項目加入或者進行代碼重用.此外，開源項目還有其他的屬性，如stars、pull request、issues以及項目的已有成員的信息.其中：

1)stars指一個項目的的關(guān)注者個數(shù)，它代表了一個項目的流行程度.

2)Pull Request用于開發(fā)者之間的協(xié)作，比如，開發(fā)者想要為一個項目進行貢獻，可以先fork這個倉庫，相當(dāng)于拷貝一份，再克隆到本地分支，然后對項目進行缺陷修復(fù)或增加一些功能，貢獻完成后，則可以發(fā)起一個Pull Request，即請求另一個開發(fā)者(比如項目的維護者)進行代碼審查，若代碼合格，則拉取這份分支倉庫.發(fā)起Pull Request時，需提供4個信息(源倉庫、源分支、目的倉庫、目的分支).

3)Issues中包含了在項目開發(fā)過程中產(chǎn)生的所有缺陷、缺陷提出者、缺陷指派者、缺陷狀態(tài).每個issues有獨一無二的編號以便對這些缺陷狀態(tài)進行跟蹤.

2.2 開發(fā)者特征

開源社區(qū)用戶眾多，任何人都可能成為開源項目的貢獻者.在分析開發(fā)者的特征時，需結(jié)合項目特征，挖掘出開發(fā)者的興趣點和擅長的項目類型.

社區(qū)中的用戶(users)均有個人id、姓名、所屬公司、所屬國家及地區(qū).開發(fā)者在社區(qū)中的所有行為均會被記錄，這些行為包括提交、評論、追隨其他用戶等.

提交(commit)包括bug提交、bug評論提交、pull request評論提交.每一個提交也會有特定id，提交者id、項目id以及提交時間也會被記錄，這有利于挖掘開發(fā)者的個人興趣.評論(comments)與提交相同，也分為問題評論、提交評論、pull request評論.評論id、評論者id、評論內(nèi)容、評論時間等一系列細節(jié)被詳細記錄，這些信息在一定程度上能夠衡量開發(fā)者所擅長的東西.

追隨者(followers)這一特征中記錄用戶id及其追隨者id，這一指標(biāo)反映出開源社區(qū)中的領(lǐng)導(dǎo)力，那些活躍且技能突出的人會擁有更多追隨者.

由于開發(fā)者會不斷學(xué)習(xí)新的東西，其興趣會隨著時間而有所變化，因此開發(fā)者的特征比較難衡量.

2.3 開發(fā)者與項目的關(guān)系

對開源社區(qū)中，開源項目和開發(fā)者的關(guān)系是非常復(fù)雜的[4].進行項目及開發(fā)者推薦首先需要理解針對一個開源項目什么樣的成員能夠符合要求.因此，以下對開發(fā)者與開源項目的關(guān)系進行了總結(jié).

近年來，隨著開源社區(qū)的發(fā)展，許多研究者從不同的角度探索開源社區(qū)開發(fā)者的參與動機和他們之間協(xié)調(diào)合作的機理等[5]，但是缺乏一個系統(tǒng)的總結(jié).我們對相關(guān)的研究工作進行了梳理，見表1，它包括開發(fā)者加入/離開項目的原因、開發(fā)者合作關(guān)系對參與項目的影響、開發(fā)者在開源項目中的能力衡量.

表1 開發(fā)者與項目的關(guān)系

2.3.1 開發(fā)者加入/離開項目時考慮的因素

開發(fā)者的積極參與及長期貢獻是一個項目成功的必要前提，了解開發(fā)者加入項目的動機、行為具有重要價值.文獻[6，7]探究了社區(qū)中開發(fā)者的參與動機，這些動機均與項目相關(guān)，包括金錢、榮譽等等.項目有利于個人發(fā)展在所有動機中排名最高.

項目開發(fā)從來都不是單打獨斗，因此開發(fā)者加入項目時還會考慮項目的團隊成員.文獻[8，9]研究了社會意識的提高和工作的透明度如何影響開發(fā)者參與開源項目這一問題，文獻[10]探討了開發(fā)者協(xié)作網(wǎng)絡(luò)如何影響開發(fā)者對開源項目的選擇.研究表明，若一個項目中有他之前合作過的人員，則該開發(fā)者更傾向于加入該項目.開發(fā)者在過去的工作中表現(xiàn)優(yōu)秀會被優(yōu)先推薦加入項目，同時，項目中成員的素質(zhì)、聲望會影響開發(fā)者是否加入項目.項目開發(fā)離不開溝通交流，開發(fā)者自身缺乏互動會影響項目的正常推進[11].

開發(fā)者加入項目除了考慮項目、團隊成員兩個因素外，還考慮個人的因素，開發(fā)者自身專業(yè)知識是否不足是開發(fā)者加入項目時必須考慮的因素[12].

眾多文獻研究了開發(fā)者加入項目的動機，相對而言，開發(fā)者離開項目的原因的研究還沒有得到足夠的重視.文獻[13，14]使用反向滾雪球的方法，定義了開發(fā)者在開源項目中的生命周期，通過識別開發(fā)者的“休眠”狀態(tài)(即暫時離開)、“死亡”狀態(tài)(即永久離開)來探索開發(fā)人員退出項目的原因.開發(fā)者的個人私事[13]、職業(yè)的變動以及開發(fā)興趣的改變[14]均會導(dǎo)致開發(fā)者中途退場，導(dǎo)致個人在項目中的不穩(wěn)定參與.同時，項目開發(fā)過程中，開發(fā)者收到消極的反饋會使其喪失參與項目開發(fā)的信心及動力，很有可能會導(dǎo)致開發(fā)人員離開社區(qū).與項目其他成員存在分歧，開發(fā)者之間意見不統(tǒng)一對于開發(fā)者參與項目的積極性起到負面影響[15].

2.3.2 開發(fā)者合作關(guān)系對開源項目的影響

溝通質(zhì)量以及合作效果被認為是開源項目成功的決定因素之一.探究開發(fā)者之間的合作情況，也有利于為開源項目推薦較為合適的開發(fā)人員.

1)開源項目中的合作關(guān)系

開發(fā)者之間通過合作關(guān)系構(gòu)成了一個社交網(wǎng)絡(luò).社交網(wǎng)絡(luò)可以用許多指標(biāo)進行度量，例如，其密度是網(wǎng)絡(luò)中形成的連接數(shù)與網(wǎng)絡(luò)中所有節(jié)點連接總數(shù)的比例[16].文獻[17]通過研究GitHub上開源項目的協(xié)作模式pull request，開發(fā)了一種基于有向圖的社交網(wǎng)絡(luò)，并分析項目成員之間的等級制度、生產(chǎn)力、受歡迎程度、彈性和穩(wěn)定性.研究表明，成員的社交網(wǎng)絡(luò)特征與項目的成功之間存在相關(guān)性，例如，開源項目的參與者越多，則項目效果越好.這些分析為如何有效進行協(xié)作軟件開發(fā)提供了見解.

在開源項目中，團隊合作大多都是暫時性的.文獻[18]在GitHub上挖掘能夠跨項目的社交連接(CRSC)團隊，研究了團隊的合作是否能擴展到不同的項目.作者使用復(fù)雜網(wǎng)絡(luò)分析法研究這些團隊的結(jié)構(gòu)，研究發(fā)現(xiàn)，擁有持久社會聯(lián)系的開發(fā)團隊，成員之間的合作更加穩(wěn)定，且會在多個項目上相互合作.

文獻[19]研究了開發(fā)者的加入率和退出率、任務(wù)分配率和任務(wù)完成率、現(xiàn)有開發(fā)者在不同項目間的活動以及新成員的加入率.

研究發(fā)現(xiàn)，成功的開源項目中的開發(fā)人員具有專注的特征，且少數(shù)核心開發(fā)人員貢獻了大部分代碼，這部分人對軟件集成的質(zhì)量起著重要的作用.

2)開源項目中合作關(guān)系的特點

開源社區(qū)社區(qū)成員和合作隨時間不斷地變化，分析網(wǎng)絡(luò)中新加入開發(fā)者的合作偏好行為有利于了解社區(qū)開發(fā)者網(wǎng)絡(luò)結(jié)構(gòu)的動態(tài)變化與合作趨勢的走向.

社會網(wǎng)絡(luò)結(jié)構(gòu)具有封閉性、中介性和中心性等特征，研究發(fā)現(xiàn)，有影響力的人會影響其他開發(fā)人員，開發(fā)者傾向于與有影響力的人相互合作.識別中心度高的開發(fā)者，挖掘、利用隱含于網(wǎng)絡(luò)中的知識，并依靠中心位置開發(fā)者者的聲望和權(quán)力的影響、支配作用，可以達到快速知識共享的目的.

github上的協(xié)作開發(fā)主要通過拉取請求來完成，拉取請求審核過程的效率取決于技術(shù)(如代碼質(zhì)量)和社會(如貢獻者與項目維護者的關(guān)系)等因素.為了確定社會因素對項目開發(fā)效率的影響因子，文獻[20]研究了基于拉取請求的開發(fā)人員組成的團隊結(jié)構(gòu).核心貢獻者和開發(fā)人員之間更緊密的交互與更快的響應(yīng)對拉取請求的處理至關(guān)重要.研究發(fā)現(xiàn)，中小型項目開發(fā)的特點是少數(shù)核心貢獻者保持反復(fù)的交互，并且能夠更有效地處理傳入的請求.文獻[21]利用社會網(wǎng)絡(luò)分析(SNA)探討開源項目中開發(fā)者的協(xié)作行為，將SNA技術(shù)用于識別那些在其他社區(qū)成員中扮演中心者角色的成員，發(fā)現(xiàn)技術(shù)出色的開發(fā)者建立的合作會更穩(wěn)固、更高效.也有研究表明，開發(fā)者擁有相同的興趣、目標(biāo)，會使開發(fā)過程更順暢[22].

除了開發(fā)者自身的硬實力之外，其人際交往能力、溝通能力、性格等因素會對項目開發(fā)產(chǎn)生或多或少的影響.一個成熟的項目開發(fā)團隊對開發(fā)流程更熟悉，平臺更廣，開發(fā)者通常會優(yōu)先選擇與其合作[23].

2.3.3 開發(fā)者在項目中的能力衡量

開源項目中，開發(fā)者在項目中的表現(xiàn)行為和擔(dān)任的角色是不同的，他們的活動推動著項目的發(fā)展[24].通過對開發(fā)者的貢獻方式以及個人能力進行衡量，能夠幫助我們了解、挖掘不同開發(fā)者的技能專長，從而合理地進行開發(fā)者推薦.針對開發(fā)者在過去項目中的表現(xiàn)，可以將開發(fā)者能力的衡量分為技能評估和社區(qū)影響力評估.

1)技能評估

技能評估主要根據(jù)代碼行或功能點來衡量開發(fā)者對軟件項目開發(fā)的貢獻.軟件開發(fā)人員主要通過編寫代碼、提交源文件、發(fā)表評論以及執(zhí)行缺陷修復(fù)來參與項目.除了源代碼之外，技能評估還包含開發(fā)人員活動軌跡的分析，這對開發(fā)者推薦過程非常重要.

軟件開發(fā)過程中仍然缺乏技術(shù)來評估開發(fā)人員在流行的庫和框架中的專業(yè)技能.文獻[25]收集了關(guān)于開發(fā)人員在GitHub項目上活動的13個特性，包括對源代碼文件的提交.通過評估了無監(jiān)督學(xué)習(xí)(基于聚類)和有監(jiān)督學(xué)習(xí)(隨機森林和SVM)分類器的性能，以識別3個流行的JavaScript庫中的專家，最后提出了一種基于GitHub聚類特征數(shù)據(jù)的專家識別方法.文獻[26]為了對GitHub的貢獻進行評估，提出CoreDevRec模型用于推薦核心成員.CoreDevRec使用支持向量機分析不同事件類型的特征，包括修改代碼的文件路徑、貢獻者與核心成員之間的關(guān)系以及核心成員的活動性.研究者評估了GitHub中5個流行項目的18651個pull請求，結(jié)果表明，CoreDevRec在前3名推薦中的準(zhǔn)確率為72.9%-93.5%.

一般認為，在開源項目中，貢獻者本身的技術(shù)價值是非常重要的.隨著開發(fā)人員和代碼操作之間的關(guān)系變得可見，我們可以從中推斷出開發(fā)者重要但隱藏的特性.例如，在決定是否接受一名開發(fā)者貢獻之前，項目經(jīng)理可以查看新成員之前參與的所有項目，并將其作為開發(fā)人員技能的信號進行評估.對這些信息的分析為評估開發(fā)人員在開源軟件項目中的潛在貢獻提供了證據(jù).

2)社區(qū)影響力評估

在開源社區(qū)中，一個開發(fā)人員的活動和興趣很容易被其他開發(fā)人員注意到.研究表明，開發(fā)人員使用這些信息對其他開發(fā)人員和項目進行推斷.

對Github用戶社交互動的數(shù)據(jù)進行分析可以揭示許多有趣的特征.文獻[27]通過分析基于follow、star的活動數(shù)據(jù)，從普遍性、中心性、代碼價值、貢獻和活動等方面來衡量用戶在Github開發(fā)者社交網(wǎng)絡(luò)中的影響力.研究表明，開發(fā)者的跟隨者數(shù)量對其社交影響力有較為突出的權(quán)重.

文獻[28]通過對GitHub中社交編碼網(wǎng)絡(luò)結(jié)構(gòu)的進行研究，從GitHub收集了10萬個項目和3萬個開發(fā)人員，構(gòu)建了開發(fā)人員-開發(fā)人員和項目-項目關(guān)系圖，并計算了圖的各種特性，然后使用PageRank來識別GitHub這個子網(wǎng)絡(luò)上有影響力的開發(fā)人員和項目.研究表明，在圖上距核心開發(fā)者的社交距離越近，做出貢獻的可能性越大.而在文獻[29]中指出，開發(fā)者在線活躍的時長也是其為開源社區(qū)做出貢獻的指標(biāo).

3 開源生態(tài)中的項目與開發(fā)者推薦

推薦系統(tǒng)的主要目的是為用戶推薦感興趣的信息、產(chǎn)品或?qū)ο?開源平臺為開發(fā)人員提供了學(xué)習(xí)和積累經(jīng)驗的巨大機會.為了促進開源項目的成功和開源軟件的演化，項目與開發(fā)者之間的相互匹配是非常重要的.在開源社區(qū)中，我們能夠獲取到大量的開發(fā)者信息、項目信息以及開發(fā)者合作信息.利用這些信息能夠為開源項目推薦合適的開發(fā)者，也能為開發(fā)者推薦自己感興趣的項目.

為開發(fā)者推薦項目，其核心是開發(fā)者，需要在掌握開發(fā)者的偏好的基礎(chǔ)上，幫他來篩選其可能感興趣的項目.為項目推薦開發(fā)者，其出發(fā)點是項目的需求，一方面需要根據(jù)項目的需要找到那些能夠為項目做貢獻的開發(fā)者，另一方面，也需要這些開發(fā)者確實對該項目具有一定的興趣.因此，兩者的共同之處在于開發(fā)者需要對此項目感興趣，愿意參加該項目，而不同之處在于，為項目推薦開發(fā)者需要更多的考慮項目中所欠缺的人員.

本節(jié)對現(xiàn)有的研究工作進行了分類、歸納，將開源社區(qū)推薦模型分為項目推薦、開發(fā)者推薦，并對目前深度學(xué)習(xí)在此問題上的應(yīng)用進行單獨的總結(jié).

3.1 為開發(fā)者推薦項目

在開源社區(qū)中，超過50%的源代碼文件被重用[30].開發(fā)人員會搜索感興趣的項目，以便重用其功能或者為其做出貢獻.加入不合適的項目不僅無助于個人的發(fā)展，也無助于開源項目本身的發(fā)展.因此，為開發(fā)者進行主動的項目推薦非常有必要.然而，由于項目數(shù)量極其龐大，而開發(fā)者的需求許多時候又是隱性的，因此，為開發(fā)者進行項目推薦具有一定的挑戰(zhàn)性.

3.1.1 直接推薦相似項目的方法

為開發(fā)者推薦項目的直接想法就是為他推薦與他參與過的項目相似的項目.因此，這成為了不少方法的出發(fā)點.

為了克服一些研究只使用了有限的信息，或者使用了項目中不可用的信息的問題，文獻[31]分析了兩個未在以前的工作中考慮到的數(shù)據(jù)源(即項目stars和自述文件)，基于3種啟發(fā)式規(guī)則提出了一種能夠有效地檢測GitHub上相似項目的方法.這3種規(guī)則是：在短時間內(nèi)由相同用戶開始的項目可能彼此相似，由相似用戶參與的項目可能彼此相似，自述文件包含類似內(nèi)容的項目可能彼此相似.作者分別計算其相關(guān)性得分并進行整合，構(gòu)建了一個名為RepoPal的推薦系統(tǒng)來檢測相似的項目.與文獻[31]的方法相近的是文獻[32]中提出的方法.文獻[32]創(chuàng)建了一種新的自動檢測相關(guān)項目的方法，使用java api幫助用戶檢測給定Java項目的相似項目.他們在8000多個Java應(yīng)用程序上進行了評估，發(fā)現(xiàn)他們的方法比以前提出的技術(shù)具有更高的精度.

文獻[33]提出一種基于協(xié)同過濾的推薦技術(shù)來為GitHub用戶生成個性化的存儲庫推薦.用戶可將其作為新項目的靈感、特定項目的代替方案或自我學(xué)習(xí).文章首先依據(jù)是否給存儲庫評分，將用戶劃分為兩個群體，然后針對不同群體進行算法測試.測試結(jié)果表明，給存儲庫評分的用戶做推薦是準(zhǔn)確率更高.

文獻[34]使用樸素貝葉斯模型，根據(jù)項目的描述信息利用文本分類來預(yù)測開發(fā)人員可能加入的項目：首先，將候選開發(fā)者過去參與的項目打上標(biāo)簽作為訓(xùn)練集，放入樸素貝葉斯分類器進行訓(xùn)練，然后通過該分類器將待參與的項目進行分類，分類結(jié)果為正例的即為開發(fā)者推薦的項目，該方法在實驗數(shù)據(jù)集上的推薦準(zhǔn)確率約為30%.文獻[35]在文獻[34]的基礎(chǔ)之上，提出了一種半監(jiān)督文本分類方法，這種方法將開發(fā)人員與他們過去參與項目的對應(yīng)關(guān)系看作是訓(xùn)練集，并將樸素貝葉斯與期望最大化相結(jié)合，提高了推薦的性能.研究者利用Bugzilla數(shù)據(jù)集在Eclipse環(huán)境下進行了評估，結(jié)果表明，使用監(jiān)督的樸素貝葉斯分類器的分類精度為11%-43%，與之相比，使用半監(jiān)督方法的分類精度提高了6%.

3.1.2 基于開發(fā)者行為獲取開發(fā)者對項目的興趣的方法

為了能夠給開發(fā)者推薦其感興趣的項目，需要獲取開發(fā)者的興趣.然而，開發(fā)者的興趣往往并不進行顯式表達.而用戶行為數(shù)據(jù)可以反映開發(fā)人員對軟件開發(fā)活動的偏好和興趣.開源社區(qū)提供了各種功能來促進開源項目的發(fā)展，如stars、fork和pull請求.當(dāng)使用這些功能時，會記錄大量的用戶行為數(shù)據(jù).

文獻[36]設(shè)計了一種基于用戶行為數(shù)據(jù)的方法，向開發(fā)人員推薦相關(guān)的開源項目.還有眾多文獻以開發(fā)者行為作為切入點[37-39]，它們不僅考慮用戶行為，還考慮項目特性，從而挖掘開發(fā)人員的興趣和經(jīng)驗，從每個項目的描述文檔和源代碼中提取開發(fā)人員行為和特征，為GitHub的開發(fā)者自動推薦前N個個性化的軟件項目.不同之處在于，文獻[37]集成了用戶反饋，并使用SA算法自動優(yōu)化參數(shù)配置，以提高推薦的準(zhǔn)確性.最后通過對GitHub抓取的數(shù)據(jù)進行實證研究，結(jié)果表明，該方法能夠以較高的精度向開發(fā)人員推薦相關(guān)的軟件項目.文獻[38，39]提出的REPERST模型是用MapReduce并行處理框架Apache Spark實現(xiàn)的，它可以擴展到大量的用戶和項目中進行實際使用.

文獻[40]通過構(gòu)建開發(fā)者協(xié)作圖的方式進行網(wǎng)絡(luò)分析，并提出了一個使用鏈接預(yù)測的推薦系統(tǒng).其數(shù)據(jù)來源于GHTorrent網(wǎng)站上公開的GitHub事件.作者選擇前1000個提交數(shù)最多的原始項目(即未從另一個項目倉庫派生出來，且仍處于活動狀態(tài))和所有為這些頂級項目倉庫做出貢獻的用戶.貢獻包括提交和合并請求.文獻[41]指出，將開發(fā)者的各種特征和項目語義關(guān)系靈活地結(jié)合，對于OSS生態(tài)系統(tǒng)中的相似性計算是非常有益的.作者提出CROSSSIM模型，使用圖表示法將開發(fā)人員社區(qū)與OSS項目、庫和各種構(gòu)件以及它們之間的交互作為一個整體來考慮，從而計算開源項目的相似性.

以上文獻均通過對Github中選定的數(shù)據(jù)集進行實驗來探索這種方法的可能性.從用戶行為數(shù)據(jù)中挖掘項目相關(guān)性是一個很有前途的方向.

3.1.3 考慮開發(fā)者之間的關(guān)系

對于一個開發(fā)者，如果一個項目中存在具有一定聯(lián)系的其他開發(fā)者，則該項目也具有一定的吸引性[42].因此，一些方法中把開發(fā)者關(guān)系也進行了利用.如文獻[43]提出一種預(yù)測開發(fā)人員的興趣向他們推薦項目的新方法RepoLike：一方面，探索開發(fā)人員的歷史開發(fā)活動和與其他開發(fā)者的社會聯(lián)系，另一方面，挖掘項目的技術(shù)特性和它們之間的依賴關(guān)系，然后將這兩個方面結(jié)合起來向開發(fā)人員推薦項目.

3.2 為項目推薦開發(fā)者

開源項目有賴于開發(fā)者的積極參與，因此需要為項目確定潛在的開發(fā)者.

進行開發(fā)者推薦需要深入研究開發(fā)者的興趣、社交關(guān)系等.為項目推薦開發(fā)者的特殊之處在于我們不僅需要考慮他們是否有興趣，而且需要考慮他們能否勝任這個項目的要求，甚至需要針對項目的不同任務(wù)的要求進行更有針對性的推薦.

3.2.1 從相似項目中獲取開發(fā)者的推薦方法

為了推薦開發(fā)者，一個直觀的想法就是去尋找類似的項目，那些項目中的開發(fā)者應(yīng)該對本項目具有興趣，也具有相應(yīng)的能力.

每一個開源項目都有其特征，例如項目語言、項目背景等.對這些項目的特征進行分類、建模，可以幫助開發(fā)者更快的選擇自己感興趣的項目.

文獻[44]提出了一種基于特征匹配的跨域開發(fā)者推薦算法.首先，研究者尋找與當(dāng)前目標(biāo)項目主題最相似的歷史項目.然后檢索了這些項目的開發(fā)人員.最后，我們將目標(biāo)項目的主題與檢索的開發(fā)人員進行匹配，篩選出最相似的開發(fā)人員，以組成當(dāng)前任務(wù)的推薦開發(fā)人員集.為了驗證所提算法的有效性，作者將該模型與各種先進的開發(fā)人員推薦算法進行比較.實驗結(jié)果表明，該算法在不同的評價指標(biāo)上具有優(yōu)于以往算法的優(yōu)勢.

文獻[45]提出了一種新的方法DevRec來自動推薦開發(fā)人員.該方法基于兩種分析：基于項目的分析和基于開發(fā)人員的分析.基于項目的分析通過k近鄰搜索與新項目相似的老項目，為新項目推薦參與過老項目的開發(fā)者；在基于開發(fā)者的分析中，對開發(fā)人員以及之前參與過的項目進行建模，計算開發(fā)者與新項目之間的術(shù)語、主題、組件和產(chǎn)品關(guān)聯(lián)度.將基于項目和基于開發(fā)者分析的分?jǐn)?shù)線性組合，得到最終的DevRec模型分?jǐn)?shù).

文獻[46]提出了一種基于主題模型的開發(fā)者推薦算法DRETOM(Developer Recommendation based on Topic Models).該方法選擇了潛在主題分布(LDA)從歷史項目中提取主題.它可以幫助我們分析開源社區(qū)中的新項目屬于哪些主題.如果開發(fā)人員參與的歷史項目與新項目屬于同一主題，我們可以認定開發(fā)人員對此項目主題感興趣.基于從歷史項目中構(gòu)建的主題模型來模擬開發(fā)人員對錯誤解決活動的興趣和專業(yè)知識.在Eclipse JDT和Mozilla Firefox項目上的實驗結(jié)果表明，DRETOM在推薦的前5名和前7名開發(fā)者中的召回率分別達到82%和50%.

從相似項目中去尋找開發(fā)者的方法雖然比較直觀，但是一個開發(fā)者留在某一個項目中不僅是因為該項目的技術(shù)特性，還受到了社交關(guān)系等的影響.因此需要考慮開發(fā)者的關(guān)系.另一方面，開發(fā)者在參與項目中的行為、關(guān)系等體現(xiàn)了其積極度和能力的差異，在開發(fā)者推薦時我們需要盡量推薦那些態(tài)度積極、能力高的開發(fā)者.

3.2.2 基于合作關(guān)系進行開發(fā)者推薦

在開源軟件社區(qū)中，項目是通過開發(fā)者之間的動態(tài)協(xié)作來完成的.利用開發(fā)者的社交關(guān)系進行推薦有兩個意義，一方面人們愿意和協(xié)作過的開發(fā)者繼續(xù)協(xié)作；另一方面，通過合作關(guān)系也可以判斷哪些開發(fā)者在社區(qū)中具有重要的地位.

研究者利用開發(fā)者協(xié)作圖上的隨機游走模型探究了開發(fā)者之間的協(xié)作關(guān)系，該模型又被稱為開發(fā)者協(xié)作網(wǎng)絡(luò)[47-49].開發(fā)者協(xié)作網(wǎng)絡(luò)是使用以下規(guī)則構(gòu)造的：若兩名開發(fā)者都參與了同一項目，則在協(xié)作網(wǎng)絡(luò)中他們之間有一個鏈接，在同一個項目中工作的兩個開發(fā)人員被認為具有共同的興趣和技能.

文獻[47]指出對于同一種數(shù)據(jù)資源中蘊含的協(xié)作關(guān)系，具有不同的建立圖模型的方式，應(yīng)當(dāng)結(jié)合具體問題探討協(xié)作圖的邊的方向性、權(quán)重的賦值方式等問題.文獻[48]提出了一種基于k近鄰搜索的開發(fā)人員推薦方法DREX.DREX首先搜索k個與新項目類似的歷史項目文檔，并檢索出為這些歷史項目做出貢獻的開發(fā)人員；其次，DREX在這些開發(fā)者的協(xié)作圖上定義了中心度指標(biāo)來對開發(fā)者節(jié)點進行度量；然后根據(jù)歷史項目中的參與記錄，采用度中心度、中間中心度和接近中心度3個指標(biāo)對開發(fā)人員的技能進行排名.實驗結(jié)果表明，當(dāng)為250個測試項目分別推薦10名開發(fā)人員時，DREX比傳統(tǒng)的多標(biāo)簽文本分類方法具有更好的性能.

文獻[49]通過構(gòu)建開發(fā)者協(xié)作圖，然后將帶有重啟動的隨機游走模型建立在協(xié)作圖之上，完成開發(fā)者的全局性排名，實驗結(jié)果表明利用該方法能夠識別社區(qū)中高貢獻度的開發(fā)者.在協(xié)作圖中，頂點的入度越大，說明該開發(fā)者接收到其他開發(fā)者傳遞給他的任務(wù)越多，意味著該開發(fā)者解決問題的能力越強，越有知名度.

基于協(xié)作網(wǎng)絡(luò)進行推薦利用了開發(fā)人員、項目之間的復(fù)雜的關(guān)系.但是，該方法中缺乏對開發(fā)人員的技能的顯式 建模，可能造成重復(fù)推薦同一類人員.

3.2.3 基于專業(yè)知識的開發(fā)者推薦

在開源軟件項目開發(fā)中，越來越需要找到具有相關(guān)專業(yè)知識的開發(fā)人員.現(xiàn)有的開發(fā)者推薦系統(tǒng)大多依據(jù)更改代碼數(shù)量多少來衡量開發(fā)人員的能力.雖然該方法已經(jīng)取得成功，但想要更精準(zhǔn)的進行開發(fā)者推薦需要分析開源項目的大量開發(fā)歷史記錄.

在文獻[50]中，引入了開發(fā)者專業(yè)知識的概念，它通過開發(fā)人員的特定行為對其專業(yè)知識進行建模，如功能函數(shù)的使用及使用次數(shù)、代碼提交的頻率等.研究結(jié)果證明，利用專業(yè)知識作為開發(fā)者推薦的主要依據(jù)能有效提高推薦準(zhǔn)確度.文獻[51]同樣對開發(fā)人員的專業(yè)知識進行了建模，提出了基于模糊集的自動推薦技術(shù).該自動推薦技術(shù)將不同的專業(yè)知識與其對應(yīng)的模糊集合結(jié)合起來，以找到最有能力的開發(fā)者.研究結(jié)果表明，利用模糊集表示專業(yè)知識進行推薦比現(xiàn)有的方法具有更高的精度和時間效率.

文獻[52]提出了專業(yè)技能指標(biāo)和機能衰退指標(biāo)來評估開發(fā)者交互數(shù)據(jù)中的專業(yè)技能，指出開發(fā)者的專業(yè)技能水平是在時間上定義的，專業(yè)技能強的開發(fā)者與完成任務(wù)所需的時間應(yīng)該呈負相關(guān)，任務(wù)完成時間越久，開發(fā)者的專業(yè)技能會隨之衰退.作者首先計算開發(fā)者在代碼源文件上的原始專業(yè)技能度量，然后將專業(yè)技能值標(biāo)準(zhǔn)化為開發(fā)者在專業(yè)知識總和上的專業(yè)知識比率，從而使專業(yè)技能值介于0和1之間.在計算了開發(fā)人員在單個代碼源文件的專業(yè)知識后，需要對開發(fā)人員的綜合技能水平進行計算：用開發(fā)者的專業(yè)技能指標(biāo)減去機能衰退指標(biāo)后，再除以代碼源文件的數(shù)量，最后對每項技能進行加權(quán)平均，其中權(quán)重是某項技能在項目中出現(xiàn)的次數(shù)，這樣就得到了開發(fā)者的綜合技能評估指標(biāo)得分.研究顯示，開發(fā)者的綜合技能指標(biāo)得分越高，說明該開發(fā)人員專業(yè)技能越強，能夠勝任項目開發(fā)的可能性越大.

3.2.4 針對特定任務(wù)的推薦

進一步，一些研究考慮了針對項目中的特定任務(wù)進行開發(fā)者推薦，例如，對bug報告修復(fù)者進行推薦[53，54]、對Pull請求的評審者進行推薦[55，56]、為項目推薦測試人員[57，58].

為了幫助開發(fā)人員解決bug報告，已經(jīng)提出了各種自動化技術(shù)來識別和推薦開發(fā)人員處理新bug.目前有兩類bug指派人推薦技術(shù)，且都是單獨研究的，包括基于開發(fā)者先前活動的推薦，以及根據(jù)bug的位置推薦合適的開發(fā)人員.文獻[53]提出了一個統(tǒng)一的模型，它將來自開發(fā)人員先前活動的信息和可疑程序位置的信息以相似特征的形式組合在一起.對來自eclipsejdt、eclipseswt和ArgoUML項目的11000多個bug報告進行了評估，實驗表明該模型優(yōu)于先前的研究.文獻[54]中將主題模型和開發(fā)人員關(guān)系(如bug報告者和指派者)結(jié)合起來，捕捉開發(fā)人員對特定bug報告的興趣和經(jīng)驗，從而推薦最合適的開發(fā)人員來修復(fù)bug.研究者使用3個大型開源項目(Eclipse、mozillafirefox和Netbeans)來評估該方法的性能.實驗結(jié)果表明，該方法推薦的準(zhǔn)確性優(yōu)于其他推薦方法.

Pull Request(PR)是開源項目外部開發(fā)人員的主要貢獻方式.PR評審是開源軟件開發(fā)中保證項目質(zhì)量的重要環(huán)節(jié).推薦合適的PR評審員，可以提高PR評審的效率.然而，GitHub沒有一個自動推薦PR的機制.文獻[55]提出了一種自動推薦核心評審員的方法，它將PR主題模型與社交網(wǎng)絡(luò)中的開發(fā)者相結(jié)合.通過潛在Dirichlet分配從PR中提取PR主題，然后利用協(xié)作者和PR之間的連接構(gòu)建協(xié)作者-PR網(wǎng)絡(luò)，并計算每個協(xié)作者的影響.最后依據(jù)PR評審的歷史行為建立PR主題與協(xié)作者之間的關(guān)系.當(dāng)一個新的PR出現(xiàn)時，根據(jù)協(xié)作者的影響力以及新PR與合作者之間的關(guān)系，選擇一個合作者作為核心評審者.實驗結(jié)果表明，該方法推薦精度優(yōu)于70%.為了支持評審員推薦，文獻[56]提出了一種自適應(yīng)的評審員排名模型來對一個請求中的所有評審員候選人進行排序.排名模型利用多種特性來衡量拉取請求和評審者候選人之間的關(guān)系.利用學(xué)習(xí)排序技術(shù)，根據(jù)先前解決的拉取請求，自動訓(xùn)練排序模型的權(quán)重參數(shù).其特征選擇實驗表明，最重要的特征是統(tǒng)計請求者發(fā)送并由開發(fā)人員審閱的先前pull請求的數(shù)量.另一個重要特性是度量在拉取請求中，更改的文件與開發(fā)人員先前修改的文件之間的文件路徑相似性.

在項目開發(fā)過程中，由于缺乏有效的眾包測試員推薦方法，任務(wù)發(fā)布者往往直接從大量的申請者中選擇測試者.以此方式選擇的測試人員往往不能完成預(yù)期任務(wù)，因此為測試用例自動化推薦測試人員很有必要.目前，將推薦系統(tǒng)應(yīng)用于軟件測試階段的人并不多.為了使推薦的測試人員與任務(wù)相匹配，文獻[57]提出了一種基于Top-K的測試員推薦算法.為了降低Top-K算法的時間復(fù)雜度，引入了類別.通過對測試任務(wù)進行分類并計算各類別與測試員的匹配得分得到最適合該類別的測試員.在計算測試人員和特定類別的任務(wù)之間的相似性后，從選定的類別中推薦前K名最適合該任務(wù)的測試人員.實驗表明，提出的Top-K-Worker算法可以大大提高測試人員與推薦任務(wù)的匹配度.文獻[58]開發(fā)了一個推薦系統(tǒng)，將測試用例分配給測試人員.該系統(tǒng)是使用Eclipse集成開發(fā)環(huán)境在Python中開發(fā)的.它提供了兩個好處，首先，它可以幫助測試經(jīng)理更快地分配測試用例.其次，它可以向新的測試經(jīng)理提供關(guān)于測試用例和測試人員詳細信息(包括以前分配的歷史記錄).測試任務(wù)與測試人員的匹配度決定了測試的效率和質(zhì)量，針對測試人員的推薦是軟件工程中重要的一步.

由于不同的任務(wù)具有不同的特性，挖掘開發(fā)者在特定任務(wù)背景下的特征并對其能力進行衡量是比較困難的.因此，針對特定任務(wù)進行開發(fā)者推薦是一個值得研究的方向.

3.3 基于深度學(xué)習(xí)的項目與開發(fā)者推薦

在項目推薦與開發(fā)者推薦的過程中，需要將項目信息及開發(fā)者信息映射到另一個維度，即將現(xiàn)實世界中的信息轉(zhuǎn)換成計算機和數(shù)學(xué)公式能夠處理的形式.深度學(xué)習(xí)神經(jīng)網(wǎng)絡(luò)表示法能夠很好的抽取詞與詞之間的關(guān)系，應(yīng)用最廣泛的就是卷積神經(jīng)網(wǎng)絡(luò)提取和神經(jīng)網(wǎng)絡(luò)提取.隨著深度學(xué)習(xí)應(yīng)用的推廣，近年來，一些學(xué)者嘗試了基于深度學(xué)習(xí)模型的項目與開發(fā)者推薦方法.

基于卷積神經(jīng)網(wǎng)絡(luò)的推薦算法可緩解傳統(tǒng)推薦算法中面臨的冷啟動問題和數(shù)據(jù)稀疏性問題，并提升推薦系統(tǒng)的性能.卷積神經(jīng)網(wǎng)絡(luò)在開發(fā)者推薦系統(tǒng)中有著廣泛的應(yīng)用[59-61].

文獻[59]提出了一個從開發(fā)者的評論中學(xué)習(xí)項目屬性和用戶行為的深度模型.該模型由兩個并行神經(jīng)網(wǎng)絡(luò)組成，稱為深度合作神經(jīng)網(wǎng)絡(luò)(DeepCoNN).其中一個網(wǎng)絡(luò)利用用戶編寫的評論來學(xué)習(xí)用戶偏好行為，另一個網(wǎng)絡(luò)則從該項目的評論中學(xué)習(xí)項目屬性，并在頂部引入一個共享層，將這兩個網(wǎng)絡(luò)連接在一起.實驗結(jié)果表明，該模型具有較好的推薦性能.

當(dāng)數(shù)據(jù)集稀疏時，難以有效挖掘歷史項目中蘊含的信息，因此，文獻[60]提出了推薦模型ConvMF，該模型將卷積神經(jīng)網(wǎng)絡(luò)(CNN)集成到概率矩陣分解(PMF)中，能夠精準(zhǔn)捕捉項目文檔的上下文信息，進一步提高預(yù)測的準(zhǔn)確性，因此，即使數(shù)據(jù)極其稀少，ConvMF也能較好地預(yù)測和推薦.

文獻[61]提出了一個學(xué)習(xí)排序模型NNLRank(用于列表排序的神經(jīng)網(wǎng)絡(luò))來推薦開發(fā)人員可能貢獻的項目.NNLRank利用項目特性和開發(fā)人員的經(jīng)驗來推薦項目，并利用了一個列表式損失函數(shù)，該函數(shù)旨在最小化預(yù)測項目列表和開發(fā)人員首選的基本真實列表之間的差異.實驗結(jié)果表明，NNLRank能夠為開發(fā)者提供有效、高效的入職推薦，大大優(yōu)于以往的模型.

循環(huán)神經(jīng)網(wǎng)絡(luò)也被用于開發(fā)者推薦中以捕獲開發(fā)者的興趣變化.文獻[62]提出了一個統(tǒng)一的句子表示和文本分類模型C-LSTM，該模型結(jié)合了CNN和RNN兩種架構(gòu)的優(yōu)點.利用CNN提取項目文檔中的關(guān)鍵詞，并貼上標(biāo)簽，然后將其輸入到LSTM中，得到開發(fā)者的技能專長特征.實驗結(jié)果表明，C-LSTM的性能優(yōu)于普通的CNN和LSTM，在開發(fā)者推薦的任務(wù)中取得了較好的性能.

深度學(xué)習(xí)模型在其他推薦領(lǐng)域的應(yīng)用已經(jīng)成為一個技術(shù)熱點，然而，該類模型在項目和開發(fā)者推薦中的應(yīng)用還不普遍，因此，還具有很大的發(fā)展空間.

4 數(shù)據(jù)集和評價指標(biāo)

4.1 數(shù)據(jù)集

目前，GitHub是最流行的源代碼存儲和共享平臺，它組織來自世界各地的開發(fā)者進行代碼貢獻.這一平臺提供一個 官方REST API，允許通過HTTP請求訪問存儲在該平臺的項目信息，這有助于Github在軟件工程研究中的廣泛應(yīng)用.由于近年來研究者對Github產(chǎn)生了廣泛的研究興趣，一些從該平臺收集數(shù)據(jù)的其他平臺被建立，如Github archive和GHTorrent.這些平臺從Github收集數(shù)據(jù)，可對其進行更深入的分析.

Github Rest API(1)https://developer.github.com/v3/可以對托管項目的數(shù)據(jù)進行訪問，是研究者獲取Github數(shù)據(jù)最流行的方式.這個API提供了有關(guān)存儲庫、用戶、問題、拉取請求、評論信息等數(shù)據(jù)，并以JSON格式返回結(jié)果.

Github archive(2)https://www.gharchive.org/是為收集GitHub數(shù)據(jù)而創(chuàng)建的一個平臺，因此用戶可以輕松地檢索和使用這些數(shù)據(jù).該系統(tǒng)每小時收集一次Github事件，并可由HTTP客戶端下載.盡管GitHub Archive不提供關(guān)于存儲庫和用戶的直接數(shù)據(jù)，但它們可以通過Git事件獲得.

GHTorrent(3)https://ghtorrent.org/平臺提供GitHub數(shù)據(jù)的脫機鏡像，通過收集事件來檢索該鏡像.數(shù)據(jù)以結(jié)構(gòu)化和非結(jié)構(gòu)化格式存儲，結(jié)構(gòu)化數(shù)據(jù)存儲在MySQL中，原始事件數(shù)據(jù)存儲在MongoDB中.

除了以Github(4)https://github.com/社區(qū)為研究對象獲取數(shù)據(jù)之外，研究者還以其他開源社區(qū)為研究對象獲取數(shù)據(jù)，如Sourceforge(5)https://sourceforge.net/、Rubyforge(6)https://rubygems.org/等獲取項目及開發(fā)者信息.

4.2 評價指標(biāo)

為了衡量開源軟件社區(qū)推薦算法的有效性，研究者們使用了流行的評估指標(biāo)，包括Top-N準(zhǔn)確率(Top-N Accuracy)、平均精度均值(MAP)、平均倒排序值(MRR)等.

1)Top-N準(zhǔn)確率(Top-N Accuracy)

推薦的準(zhǔn)確率是指推薦給結(jié)果中符合要求的結(jié)果所占的比例.一般來說，推薦結(jié)果前若干項的準(zhǔn)確性比較重要，因此，需要Top-N準(zhǔn)確率這一指標(biāo)來度量前幾個結(jié)果的推薦精度.Top-N準(zhǔn)確率表示其對應(yīng)的真實項目(開發(fā)者)處于推薦列表前N名的概率，如果真實項目(開發(fā)者)在前N名，說明推薦效果好，反之推薦效果差.計算Top-N準(zhǔn)確率如公式(1)所示：

(1)

上式中Nq為推薦項目(開發(fā)者)的總數(shù)，|Instancesuccess|為推薦成功的項目(開發(fā)者)個數(shù).

2)平均精度均值(MAP)

MAP評價指標(biāo)主要用于衡量推薦結(jié)果排序的好壞程度，它考慮了推薦結(jié)果中所有真實項目(開發(fā)者)的具體排名，排名越靠前，MAP值越高.假設(shè)需要向N個開發(fā)者推薦項目(N個待開發(fā)項目推薦開發(fā)者)，在計算MAP之前，需要先計算每個開發(fā)者(開發(fā)項目)的平均精度(AP)，AP值計算如公式(2)所示：

AP=predictioni×(change in recall)i

(2)

predictioni表示前i個推薦結(jié)果的正確率；(changeinrecall)i為二值項：當(dāng)?shù)趇個推薦結(jié)果正確時，值為1/N；否則為0.

MAP是所有開發(fā)者(開發(fā)項目)的AP的平均值，其計算如公式(3)所示：

(3)

3)平均倒排序值(MRR)

MRR是指將準(zhǔn)確推薦項在推薦系統(tǒng)給出結(jié)果的排序位置的倒數(shù)作為它的準(zhǔn)確度，再對所有的問題求平均.MRR是對推薦結(jié)果進行評價的常用指標(biāo)之一，它的定義如公式(4)所示：

(4)

上式中，Nq表示數(shù)據(jù)集中開發(fā)者(項目)的個數(shù)，Ri表示第i個開發(fā)者(項目)得到正確的推薦結(jié)果中第一次出現(xiàn)的排名位置，如果開發(fā)者(項目)的推薦結(jié)果中沒有出現(xiàn)正確答案則取0.根據(jù)上式的定義，可以看出MRR的值越大說明推薦效果越好.

5 研究展望

5.1 挑戰(zhàn)

當(dāng)前軟件開發(fā)活動分工高度細化，不同的項目需要不同的開發(fā)者，而開發(fā)者又需要加入適合自己的項目，因此對開發(fā)者更細致的特點進行評價和度量很有必要.研究人員需要從軟件資源中提取能夠反映開發(fā)者細粒度技能的證據(jù)，并在此基礎(chǔ)上進行建模.然而，目前還缺乏對開發(fā)者技能進行詳細建模的框架和方法.

現(xiàn)有的研究中，研究者們大多只針對單一的開源社區(qū)中數(shù)據(jù)進行項目及開發(fā)者推薦.目前流行的開源社區(qū)還有很多.一方面，這些社區(qū)的數(shù)據(jù)格式、類型定義、數(shù)據(jù)規(guī)模具有不一致性，另一方面，不同社區(qū)的信息是不同步的，因此整合信息時可能出現(xiàn)沖突.此外，開發(fā)者活動記錄散布在多個社區(qū)之中，要想從多社區(qū)中全面挖掘開發(fā)者的活動規(guī)律及個人專長具有極大的挑戰(zhàn).

現(xiàn)有的開源生態(tài)相關(guān)推薦算法，特別是機器學(xué)習(xí)算法通過擬合開發(fā)者過去參與項目中的數(shù)據(jù)獲得其興趣.然而，開發(fā)中過去參加的項目并不一定就是他最感興趣的，由于開發(fā)者的注意力有限，有可能有些項目被他所忽略，所以他參加的項目只是在他有限的范圍內(nèi)的一個選擇，過度擬合過去的項目可能難以反映開發(fā)者的真正偏好.

另外，開源社區(qū)中可能會出現(xiàn)新型項目，例如新的編程語言，新的應(yīng)用類型等，由于這些項目中缺乏歷史數(shù)據(jù)，這將對開發(fā)者推薦帶來更大的挑戰(zhàn).

5.2 未來研究方向

從上面的討論可以看到，目前對于開源生態(tài)的相關(guān)推薦仍存在著諸多挑戰(zhàn).在未來必將會有更多、更廣泛的嘗試，可能的研究方向包括但不限于：

1)基于開發(fā)者全面畫像的推薦：正如我們在第2節(jié)中所分析，開發(fā)者參與項目的意愿以及其在項目中的表現(xiàn)和貢獻涉及到眾多的因素，現(xiàn)有的推薦算法考慮得不夠全面.在未來研究中，可以進一步擴展考慮的因素，對開發(fā)者進行全面的刻畫，從而能夠進行更有針對性的推薦.另一方面，開發(fā)者的興趣愛好是發(fā)生變化的.在開源社區(qū)中，不同的開發(fā)者參與開源社區(qū)的動機是不同的，因此，需要從不同開發(fā)者的動機出發(fā)，對其當(dāng)前的興趣愛好進行預(yù)測，從而能夠推薦其感興趣的項目.

2)由于有過合作經(jīng)驗的開發(fā)者彼此更加熟悉，在開發(fā)過程中的開發(fā)效率更高.目前的開發(fā)者推薦都是考慮個體開發(fā)的推薦問題.我們可以在開源社區(qū)中挖掘已經(jīng)經(jīng)過配合的開發(fā)團隊，從而能夠為一個項目推薦配合默契的團隊.

3)面向特定任務(wù)的推薦：現(xiàn)有的開發(fā)者推薦面向的是整個項目，然而項目中需要不同角色的配合.我們在某些場景下可能需要針對項目中的某一模塊，甚至某一Pull請求的評審來尋找特定的開發(fā)者.面向特定任務(wù)的推薦涉及到對任務(wù)的詳細描述和對開發(fā)者技能的進一步刻畫.

4)進一步應(yīng)用深度學(xué)習(xí)的最新成果.通過利用深度學(xué)習(xí)模型融合廣泛的多源異構(gòu)數(shù)據(jù)，能夠?qū)W習(xí)到更加抽象、更加稠密的用戶和項目的深層次表示，同時采用深層神經(jīng)網(wǎng)絡(luò)結(jié)構(gòu)構(gòu)建預(yù)測模型也能夠更好地抓住用戶和項目之間交互的非線性結(jié)構(gòu)特征.目前深度學(xué)習(xí)領(lǐng)域發(fā)展非常迅速，各種新的方法、新的模型也不斷出現(xiàn)，新的Word嵌入網(wǎng)絡(luò)、注意力機制，可解釋深度學(xué)習(xí)等都值得應(yīng)用到該問題中去.

6 總 結(jié)

互聯(lián)網(wǎng)的快速發(fā)展使得開源軟件社區(qū)進入了蓬勃發(fā)展的階段.經(jīng)過較長時間的發(fā)展，開源社區(qū)中積累了豐富的數(shù)據(jù)，這為軟件工程領(lǐng)域的研究者認識相關(guān)現(xiàn)象與規(guī)律、優(yōu)化軟件開發(fā)過程奠定了基礎(chǔ).開發(fā)者是軟件開發(fā)中最基本的要素之一.本文先對開發(fā)者行為的相關(guān)研究進行總結(jié)，包括其加入/離開項目時考慮的因素、合作情況、貢獻方式以及能力的衡量.然后對開源生態(tài)中的項目推薦與開發(fā)者推薦方法分別進行總結(jié).最后，本文對研究中面臨的挑戰(zhàn)和未來的研究方向進行了展望.