Motivation of developer and user to contribute

參與貢獻的人，都有其動機，而參與貢獻的動機不外乎是名聲與自身能力的 提升。

其中名聲是 Reputation，不是實質上的物質利益，而是虛擬的聲望，貢獻者

可透過在社群裡面貢獻，漸漸提升自己的地位，往核心的部分接近。也可以透過 貢獻，證明在某個特殊領域中有一定的能力，這對未來找工作會相當有幫助。

另 一 個 原 因 是 提 升 自 己 的 能 力 ， 也 就 是 透 過 LPP(legitimate peripheral participation)，這個參與的過程在開放程式碼社群中發生。單純的使用者，可藉使 用專案發展的軟體，透過網路與一些使用者交換心得，成為進階使用者後，可針 對專案發展的軟體提出建議。並取得部分程式碼做修正後再釋出，自己做修正，

透過與其他發展者的溝通，對整個專案運作有更進深的了解，甚至加入開發團隊 成為發展者。成為發展者之後，一開始由資深發展者帶領，逐步熟悉專案架構，

以及撰寫程式碼需要依循的規則。慢慢地再往核心團隊接近，甚至成為整個發展 團隊的領導者。

上述的兩個原因，都不是著重在物質上的回報，而是滿足挑戰自我的渴望。

3 相關研究方法

3.1 Two Case Studies of Open Source Software Development:

Apache and Mozilla

提出開放程式碼的多個特徵，包括工作不會委任給特定成員、沒有一定計畫 以及缺乏傳統合作的機制等等。提出了兩大問題群組，第一組是把發展過程中的 變數弄清楚，第二組是以使用者角度來看專案，著重在發展過程的結果。

先擷取 Apache 的資料之後，統計分析得到一些基本的假設，基本假設如下 由一個 10-15 個人組成的團隊來掌控整個發展過程，這個團隊創造了大於

80%的功能。

10-15 個發展者無法寫出超過 80%的程式碼，需要再將工作分細一點給子團 體去開發。

在事件的發生頻率上，問題回報>缺陷修正>發展。

核心發展者可以創造新的功能，但是無法發現缺陷。

與商業軟體比缺陷密度，只有在商業軟體在釋出正式版本之前實作相比，

Apache 的表現才會比較好。

發展者也是有經驗的使用者。

發展者對於使用者提出的問題總可以很快地回應。

等到也統計分析 Mozilla 的資料後，再驗證以上假設，只有前兩個假設需要 作修正，得到下面的結論。

如果發展團隊，用非傳統合作方式進行工作，則團隊規模不會超過 10-15 個 人。

如果專案夠大，則對於每個人責任劃分會更為明確，要加入程式碼中的新程 式碼需要被檢查審核。

用 perlscript 至 email list、CVS、BugDB 擷取 Apache 資料，用 perlscript 至

CVS 以及 BugDB 擷取 Mozilla 資料，利用 MR(modification request)取代 code added 較為公平。將 Apache 以及 Mozilla 與商業軟體作比對。

優點是先分析 Apache 的數據，有假設後再對 Mozilla 做數據分析並驗證之 前的假設。拿草稿給 core team 的成員看，公信力高。缺點是取樣的專案為開放 程式碼中成熟的專案，無法看出一般的開放程式碼專案與商業軟體比較的結果。

無法看出 OSSF 中一般情形。

3.2 Characteristics of open source projects

藉由 freshmeat.net 上面的統計資料訂出公式計算各專案所得分數，另一方面 也訂立指標的差距來分析。分析了各個領域中的專案數。定義出 stable 以及 transient developer，認為影響一個專案的主要原因是 stable developer 的數量多寡。

將生命力(vitality)與普遍度(popularity)分開來計算，利用 freshmeat.net 上面 的 定 義 再 加 以 改 良 。 其 中 popularity=((record hits + URL hits)*( subscriptions+1))^1/2，意義是將瀏覽數目與一些論壇(forums)討論的人氣，取 其幾何平均數。而 vitality 的定義是(announcements * age) / (last_announcement)，其 中的 announcements 與 releases 同義，其所代表的意義是接下來專案活動力的期望 值。Announcements 就是全部 release 的次數，age 是專案註冊至今的時間，

last_announcement 為此專案上次發表 release 的間隔天數。

提出發展者團隊大小與專案大小無關的結論。將水平(horizontal)與垂直 (vertical)的應用程式(application)分開來討論，水平的專案佔了 66%以上。水平的 應用程式代表使用者會利用該應用程式來開發其他的軟體，像是系統開發軟體、

軟體開發軟體以及資料庫開發軟體等等。而垂直的應用軟體則是像一般普通使用 者使用的軟體，像是 filezilla 跟 gaim 這些軟體就隸屬於這部分。

優點是提出一些新的指標，像 app domain、doc level 以及 modularity level 對於生命力以及普遍度的影響。這是之前沒有提出過的想法。若將 developer 的

Law 造成的影響。缺點是取樣的數目不夠多(全部指取樣 406 的專案)，沒有一定 的取樣原則。有些專案的間距過小，無法看出差異。未做到公平性與一般性。其 中生命力的定義存在不小問題。

3.3 SourceForge default attributes

藉 SourceForge 上面的統計資料，經由公式計算，專案可得到活躍度的分數。

優點是可以量化表示活躍度，讓使用者有一個基本的判斷依據。缺點是沒有將普 遍度以及生命力分開來看，較不明確，無法得知哪個指標對哪一個影響較大，只 能看出很粗淺的比較。

Sourceforge 是計算分數之後再列出百分比，但百分比無法看出專案之間的 差異，只能當做篩選的標準，若可把計算所得到的絕對分數列出來，更能看出專 案間的差異，或以第一名為標準，其後的專案分數以百分比顯示約為第一名的百 分之幾(此為 freshmeat.net 的方法)。

尤其活躍度降到一定程度時(像 90%以下)，專案的差異其實並不大，活躍度 在 95%與 80%的專案差異程度，比活躍度在 80%與 50%的差異程度更大。這是 因為” Pareto distribution”造成的。下圖 Figure10 表示用百分比來表示活躍度造成 的誤差。

Figure 10 活躍度百分比 V.S. 活躍度絕對值

3.4 The Perils and Pitfalls of mining SoureForge

針對如何分析 SourceForge，方法包含了三個階段：存取資料、分析、總結 (spidering、parsing、summarizing)，並點出每階段需要注意的地方。Spidering(fetch data)的陷阱在於，要用 wait loop 防止被 ban IP，建議是將整個網頁都抓下再分

析。Parsing 的陷阱在於，不規則的行中斷(line break)，可藉由使換行符號變的可 見 來 預 防 。 以 及 如 何 找 到 正 確 的 終 止 日 期 (close_date) 方 便 計 算 貢 獻 度 。 Summarizing 的陷阱在於，對於 Nobody 這種匿名貢獻度如何做計算。它提供了 四種看法，其中將每個 nobody 視為單一個體較適合(這種做法跟把 nobody per item 或者 thread 算一個個體得到的數據差不多。)。另外有些欄位有不止一個值，

也是處理的問題之一。

優 點 是 可 把 臭 蟲 報 告 (bug report) 中 有 實 際 貢 獻 (code written or regular expression)部分另外註記，可以找出真的有一些釋出程式碼(code submission)的臭 蟲報告(bug report)。提出較有意義的觀點 如何將目前可以看到的一些指標 (downloads 等等)的數目，反推回去得到他背後代表的意義。

缺點是沒有辦法看出所有專案的狀況，只能看出大略性的狀況。

3.5 On the Pareto distribution of Sourceforge projects

闡述 Open Source 分部的情形，與許多的領域相似，像是地震震度的統計、

用字中英文字母的頻率、國民收入的分布等等，均是呈現特殊狀況與一般狀況的 差異相當大的情形(”winner takes all”)。

評量標準以”下載”數為基準。提出了兩個問題，其一為資料的可靠程度，用 人力去 check 其中五個專案，確定抓到的資料跟網站上的相同。其二為是資料的 可表現度(representative)，就是是否可代表整體的情形，他認為 SF.net 的資料可 說明 Open Source 的情形，即使有些最熱門的專案統計資料不在此(Apache、

Mozilla 等)。

第一種統計方式是以整個 SF.net 的下載數目做分析，發現有個週期性，一個 禮拜中的某幾天下載次數會最多，週末反而比平常日少，911 攻擊事件之後，有 兩週的下載量跌到谷底算是特例。

第二種是以 30 天內，專案下載次數的分布。平均下來一個專案的下載數為

70 次，但是分布很不平均(heavily skewed)。呈現了”winner takes all”的現象，如 果將數據取 Log，會呈現很直的直線。一般而言，下載數少的專案，成長空間會 下載數高的專案大。SF.net 下載數的成長有極大部分是由小專案的成長所貢獻。

並有統計結果顯示，下載數少的專案易受到外力影響，比較不穩定。

優點是用實際的數據去顯示了一些大家都認為很簡單不用證明的現象，但是 至少比較有證據。提出的下載數有一個週期性是新的說法。缺點是只用單一相度 來評斷有失主觀。不過可以大略看出普遍度。

3.6 The open source software development phenomenon：An analysis based on social network theory

分 析 發 展 者 與 專 案 之 間 的 關 係 。 認 為 OSS Community 有 高 度 偏 移 (highly-skewed) 的 特 性 ， 若 將 兩 個 數 值 都 取 log 後 ， 可 得 到 線 性 關 係 ， 稱 為”power-law”。基本假設為 SF.net 的專案代表了所有的 OSS 的專案。

表現方式是將發展者視為節點，參與同一個專案的成員會連成一個叢集 (cluster)。分析的結果，最大叢集的人數為 6862 個人，次大的只有 55 個人，只 有一個人組成的叢集的總人數佔了所有註冊發展者的 25%。以電影工業來看，大 約 90%的演員會被連結到一個極大的叢集，但開放程式碼社群還不到這樣的狀 況，推測原因是因為 SF.net 提供的開放程式碼社群發展得還不夠成熟所致。

14 個月的觀察中，最忙碌的發展者，所參與的專案由 14-27 個不等。只隸屬 於一專案的發展者人數均維持在全體發展者的 80%左右。若以 top10 專案中的發 展者來看，有 70%指屬於一個專案，但單一發展者，參與最多的專案數為 12。

最後結果顯示，分析每個單一專案的人數統計(number of projects with N developers)，如果兩個相度均取 Log 的話，其分布可以找到一條極佳的直線。另 外一個是以發展者參與的專案數來看(Number of developers on P projects)，也是取 log 的話，也可得到類似結果。如果以從集的角度來看，扣除掉最大的叢集(6862

developers)後的分布取 log，也可以得到一條直線。

優點是使用另一種相度(log-log)來檢視分布狀況，認為 sourceforge 還發展得 不夠久，沒有足夠時間讓發展者之間產生互動關係。用了兩種方法解釋(專案人 數以及叢集人數)，會比較客觀。

4 研究方法

4.1 取樣

之前的研究中，最常遇到的挑戰是取樣的問題。這裡將取樣的問題分成兩個 方面來討論，一種是隨機取樣，一種則是取出表現比較好的專案做統計。

如果要看一般性，也就是開放程式碼軟體中大略的狀況，必須採用大量的取

如果要看一般性，也就是開放程式碼軟體中大略的狀況，必須採用大量的取