开源软件项目的定性和定量分析指标 ———— CHAOSS 指标解析
點擊藍字關注我們
“科學管理在實質(zhì)上要求任何一個具體機構或機構中的工人及管理人員進行一場全面的心理革命,沒有這樣的心理革命,科學管理就不存在。”?
———— 泰勒 《科學管理原理》
引言
筆者最近閱讀了CHAOSS 在8月份發(fā)布的開源軟件項目的量化指標,頗受啟發(fā),于是索性將所想所得和大家分享一番,開源之道走過了這幾年,抽絲剝繭,一直試圖找到和大家探討的話題,一同解決令人困惑的難題,但是缺少必要的積累,一直傾向于定性的探索和研究,鑒于知識背景和視野的不同,于是很難找到讓大家感興趣的話題,甚至某位朋友善意的提醒:“多講點實在的”,多年過去了,我也終于對關于定性的問題有了一些理解和認識,那么這也意味著是該集中起來做些定量的指標衡量的事情了。
當然,伴隨著科技的進步,很多人開始迷信數(shù)據(jù),比如流行GitHub star數(shù)量、fork數(shù)量等等,這尤其體現(xiàn)在某些公司做考核之用,非常的實惠。但是這并不是開源之道所看重的,盡管量化指標很重要,正如紅帽開源項目辦公室的高級首席社區(qū)架構師Brian Proffitt(同時也是CHAOSS的治理委員會成員)所言,你有了指標和衡量,就一定保證Community是健康的嗎?對此開源之道是頗為贊同的,一直以來堅持在沒有搞清楚性質(zhì)之前,不要去迷信數(shù)據(jù)的緣由。
如果搞清楚了定性的問題,那么量化指標是自然而然的事情,畢竟這是一個科學管理為王的世界。所以開源之道接下來會有意的寫一些關于指標量化方面的文章和知識輸出。
什么是CHAOSS?
開源的重要是不言而喻的,大家默認都是承認開源對于我們所生活的世界的重要性的,也是可以看得到的,唯一的問題就是所有權下的經(jīng)濟形式限制了很多人的思考模式,如何從中獲利?需不需要承擔其中的道德責任?更有甚者便是隨著開源生態(tài)的形成,問題反而更多,大家對其的關注度越來越高。例如:
開源的貢獻者想知道哪些開源項目具有影響力,自己該往哪個方向努力?
開源Community則希望能夠吸收到更多的成員、確保始終如一的質(zhì)量、以及獎勵那些做出重大貢獻的成員。
擁抱開源的公司則希望知道哪些Community和軟件項目是值得合作的?通過交流能夠產(chǎn)生一定的影響,以及想評估自己的員工在開源當中的工作。
開源非盈利組織,如基金會則希望能夠識別出Community的需求,最好能做到積極的響應,進一步評估自身的工作,以促進community的良性發(fā)展
所有的這些問題,都是需要一些數(shù)據(jù)和指標來進行衡量的。當然也是所有開源Community所必需的內(nèi)容。
為了解決這些問題,CHAOSS 應運而生,開發(fā)開源的指標、方法論、以及相應的軟件項目,旨在讓開源項目能夠良性的發(fā)展且具有可持續(xù)性,通過衡量開源項目的健康度和可持續(xù)性,進一步,CHAOSS 會尋求提高開源項目健康度和可持續(xù)性的可操作性,進而讓所有的利益相關者能夠做出更加明智的決策,而不是在盲人摸象般的行進。
CHAOSS 的目標
目前來說,有三類目標:
建立與實施無關的度量標準,以衡量Community活躍度、貢獻以及健康度
開發(fā)和集成相應的開源軟件,來分析Community的開發(fā)
構建可復制的項目健康報告
CHAOSS 是Linux基金會下的項目。區(qū)分了兩個委員會和五大工作組。委員會主要區(qū)分為指標委員會和軟件委員會。顧名思義,指標委員會即是實現(xiàn)上述目標的決策機構。
五大工作組的任務和方向
工作組的目標即完善開源Community相關的指標,并確保其可以使用相應的軟件可以實現(xiàn)。使用 GitHub 的項目進行組織和管理,具體的有:
多樣性和包容性:目的是在開放源代碼項目中引入經(jīng)驗以衡量一致性和包容性,并在可能的情況下獲得軟件的支撐。
Evolution指標(用于軟件開發(fā)項目):專注于開源項目的生命周期,
通用指標:所有的用于Community和開源相關的指標均在這個工作組進行,除非需要特別的對待進而分離出更多的工作組。
經(jīng)濟價值:圍繞開源項目和Community的相關經(jīng)濟活動。
風險評估:重點關注與開源風險有關的指標。
解析指標
讓我們回到CHAOSS在2019年8月份發(fā)布的指標本身上,總結起來可以使用下面這個表格來涵蓋所有的內(nèi)容:
指標項 | (嘗試回答的)問題 | 開源之道注解 |
組織多樣性 | 何謂貢獻者的組織多樣性? | — |
不同的參會票 | 在會議中,如何設置不同的票來體現(xiàn)多樣性和包容性? | 例如女性貢獻者 |
在會議上的行為準則 | 在會議中,行為準則體現(xiàn)出多樣性和包容性。 | |
家庭友好程度 | 使家庭能夠一起參加會議,進而闡釋會議的多樣性和包容性。 | |
項目行為準則 | 項目行為準則如何支持多樣性和包容性? | |
導師制度 | 我們的導師制度在支持項目的多樣性和包容性方面的效果如何? | |
代碼變更 | 在指定時間段內(nèi)對源代碼進行了哪些更改? | |
代碼變更行數(shù) | 在特定時間段內(nèi)對源代碼進行的所有更改中的代碼行數(shù)(添加、刪除的都算)的總和是多少? | |
Review | 在一個時間段內(nèi),有哪些對項目進行更改的review請求。 | |
已接受的 Review | 在代碼的變更中有多少已經(jīng)接受的review。 | |
新建issue | 在一個時間段內(nèi),有多少新建的issue? | |
issue活躍度 | 在一個時間段內(nèi),有多少issue是保持活躍的? | |
關閉的issue | 在一個時間段內(nèi),有多少是已經(jīng)處理完畢的issue。 | |
Elephant Factor | Community的工作分布均勻程度如何? | 公司成員、個人開發(fā)者、基金會成員等的分布。 |
委員會 | Community貢獻者的健壯性和多樣性。 | |
測試覆蓋率 | 代碼測試得如何? | |
許可證統(tǒng)計 | 有多少種不同的許可證? | |
許可證覆蓋 | 有多少代碼庫已聲明許可證? | |
材料清單 | 軟件包的依賴、許可、安全性等相關的問題是否已經(jīng)清晰明白的有記錄。 | |
勞務投資 | 公司為其員工提供了多少財務上的支撐。 | 所有的勞動都是有成本的。 |
項目進度 | 公司的發(fā)展速度如何? | 有的公司可能在走下坡路。 |
公司或企業(yè)項目的技能需求 ? ?有多少公司在使用該開源項目,如果一位工程師掌握了相關的技術,被雇傭的幾率有多大?? ?
具體良好的內(nèi)容,在本指標中有如下格式來進行立體的敘述:
具體描述
目標
策略
成功的指標
? ? ? ? ?????定性因子
? ? ? ? ?????定量因子
已知的軟件實現(xiàn)
參考資料
下面以開源之道最為關注的Elephant Factor為例給大家進行一番示例:
Elephant Factor 指標
描述:
所謂的“Elephant Factor”,其實來自于英語世界的“房間里的大象”這樣的說法的,放在開源項目代碼當中,即是指代碼倉庫中的總的提交中,公司的占比數(shù)量。例如,一種常見的過濾器是說50%的提交是由n家公司執(zhí)行的,這就是“Elephant Factor”。先是以貢獻度最大的公司,然后是貢獻量次之的公司,以此類推。例如,如果一個項目有8個參與組織,每個組織貢獻了項目中的12.5%的提交,如果將Elephant Factor參數(shù)化為50%,則Elephant Factor為“ 4”。如果在相同的情況下,其中一個組織負責50%的提交,則Elephant Factor將為“ 1”。
Elephant Factor 提供了清晰明了的指示,用來標識出一個項目中的最小化公司參數(shù)(如50%),Elephant Factor 這一專業(yè)術語是由Venters等人(2014)提出,主要用來表述軟件的可持續(xù)性發(fā)展中非功能性部分的關鍵指標,但是他們并未在文獻中像本文這樣明確的定義。
具體的公式描述請見:Elephant Factor 公式
目標:
評估開源軟件產(chǎn)品的公司可能會使用 Elephant Factor 來比較項目對一小部分公司貢獻者的依賴程度。顯而易見,一個低 Elephant Factor 的項目對于決策者來說更具吸引力,沒有人愿意看到開源項目是某一家公司所事實上把控,當然,該參數(shù)在根據(jù)不同的項目應該有所調(diào)整,具有1000個組織參與的項目和只有10個組織參與的項目是非常不同的。也有仁者見仁智者見智的看法。
樣本的過濾和可視化:
時間:要動態(tài)的看待Elephant Factor,也就是說查看結果的時候,要關注一下時間,要縱觀全局,準確把握軟件的生命周期。
倉庫group:(現(xiàn)代)軟件項目一般都擁有非常多且分散的代碼倉庫,在某些情況下,檢查與任何給定項目相關聯(lián)的所有代碼倉庫,可以更全面地了解Elephant Factor。
已知的軟件實現(xiàn):
Augur 已實現(xiàn)該功能。
Grimoirelab提供該功能,不僅僅是一串數(shù)字,還將之可視化了。按如下方式操作:
查看有關Bitergia Analytics的CHAOSS實例的示例。
下載Grimoirelab 所給的示例代碼。
按照如下步驟在GrimoreLab Kibiter面板中顯示出來:
新建一個餅圖
選擇git的索引
指標切片大小:Count聚合
Buckets 切片:Terms聚合、author_org_name、按metric: Count和Descending排序、500大小,如下截圖所示:
參考資料:
Colin C. Venters, Lydia Lau, Michael K. Griffiths, Violeta Holmes, Rupert R. Ward, Caroline Jay, Charlie E. Dibsdale, and Jie Xu. 2014. The Blind Men and the Elephant: Towards an Empirical Evaluation Framework for Software Sustainability. Journal of Open Research Software 2, 1.?https://doi.org/10.5334/jors.ao
什么是大象因子
eclipse新的開放式分析面板
https://www.stackalytics.com/
開源之道 點評
在定量分析的道路上,人類從未放棄過努力,統(tǒng)計學的蓬勃發(fā)展和人工智能的突破就是最好的明證。
軟件工程是前所未有的復雜,隨著技術的發(fā)展,大量人員的參與,復雜性日益增加,即使是在某個區(qū)域下的某個組織,開發(fā)一款軟件也是足夠復雜的了,更何況是充滿不確定性的開源項目。但是由于開放的、多樣性的、動態(tài)的實用主義的成功,誕生了非常重要的開源項目,并在人類的生活中發(fā)揮著非常重要的作用,那么其中發(fā)生效用的究竟是什么?是冥冥之中的神力嗎?還是僅僅依靠運氣?目前為止,還沒有確切的答案,只有無數(shù)的試圖找到答案的充滿好奇和激情的人類。
或者正是因為沒有確切的答案,才能夠更加的吸引人,充滿了迷人的魅力。但是也因為沒有確切的答案,魚龍混雜、真假難辨,被一些別有用心的人利用。人類和人類社會都是異常復雜的,一個微小的心理變化,產(chǎn)生出完全不同的歷史后果,而挖掘的每一個量化的因素,都需要花去一群人相當?shù)木蜁r間,而且還要經(jīng)歷時間的驗證。
從微觀到宏觀,在開源軟件項目中,可以體現(xiàn)得非常明顯!一連串的決策思路和基本條件都讓我們有機會去捕捉和分析,想象力才是決定你能夠走多遠的極限。
接下來的工作
開源之道將會在2020年,做一些關于定量分析的學習和工作:
參與到CHAOSS Community中,希望能夠有所貢獻吧。
按照該方法論和軟件、指標,分析一些較為特定的項目,能夠形成一定的模板是最好不過的了。
Good Luck!
點擊下方“閱讀原文”查看更多超鏈接
總結
以上是生活随笔為你收集整理的开源软件项目的定性和定量分析指标 ———— CHAOSS 指标解析的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: x.norm(p=2,dim=1,kee
- 下一篇: ROS基础学习笔记(五)