Lotka’s Law and Power Law

Lotka’sLaw 是 1900 年初，Lotka 用以預測不同生產力的作者，數量的分布 情形。由寫書的形式對應到開放程式碼中的生產力，來對開放程式碼中的作者，

依照生產力區分。

(Ei=E1 / iⁿ)原本為一量化生產力分布的數學式，也可預測每個作者未來的 authoring behavior。這裡不分析特定作者的生產力，而是針對”一群”作者。指數 n 代表不同 level 作者之間生產力的差異。若寫書模式的 n 與軟體寫程式的 n 相 若，則可證明兩種 authoring pattern 是相似的。N 值越小，代表差異性越小。

Power Law用來描述一些領域的分部情形，也適用於開放程式碼的分布狀 況。原本描述的領域包括英文字彙各個單字出現的頻率、地震強度出現的頻率、

美國公司的規模大小、以及城市大小的統計等。主要的用途是轉換座標圖中的數 據，採用對數座標之後，可得到近似線性的關係。

Figure 2,3表示取Log前與後的曲線。

原始資料(取Log之前)

10542 4819

1013 507 96 47 12 6 1 0

5000 10000 15000

Data1 Data2 Data3 Data4 Data5 Data6 Data7 Data8 Data9 原始資料

資料比數

Figure 2.取log 之前的資料統計圖

原始資料取Log之後

0 1 2 3 4 5

Data1 Data2 Data3 Data4 Data5 Data6 Data7 Data8 Data9 資料比數

Log(原始資料)

Figure 3.取 log 之前的資料統計圖

2.4 Brook’s Law and Linus’s Law

Brook’s Law："Adding manpower to a late software project makes it later"，意 指增加人力，卻無法使效率成正比增加。這個問題可以依 PCMM 在管理層面上 做改進，以提升開發團隊整體生產力。

開放程式碼著名的理論”Linus’s Law”—“give enough eyeballs, all bugs are shallow”，意即有足夠數量的使用者檢測軟體，就可以找所有的臭蟲。但由 Brook’s Law 的角度來檢視，這樣卻是最浪費人力資源的方法，有許多人會花很多的時間 去檢查一個臭蟲是否真的存在。

在 OSS 中，Linus’s Law 必定是成立的，但 Brook’s Law 是否會成立，尚需 另外的討論。若只單就抓出 Bug 來看，多增加人力找出一個特定的臭蟲，不會 拖累整體的生產力。但若牽扯到專案中的開發，又恰巧需要與其他人做一些溝通 合作，Brook’s Law 預測的情形就會發生，只要有兩個人以上做同樣的事，即滿 足 Brook’s Law。

另一方面，OSS 專案較商業軟體專案多的優勢，即擁有廣大的使用者(或者 說 co-developer)，他們會在使用軟體的過程中發現臭蟲，使用過程中所花費的時 間心力，是否算是” Adding manpower”也是可以深入討論的問題。

2.5 Cooking Pot Theorem

在OSS上的發展者，其貢獻的出發點不若在現實世界中，以可以獲取的回報 多寡為考量，而在可獲得的成就感這種非物質的回報。此理論的重點在使用者可 到網路(視為一個Cooking Pot)上，找出他需要的東西，不強迫使用者取得資源之 後要有所付出。使用者使用後，視使用者自己的意志決定是否回饋，像回報臭蟲 (bug report)以及對原始碼做一些修正等。簡言之就是各取所需，但並不強制要求 要付出才可以獲得。在網路上面的付出，所得到的回報並不一定馬上顯現，可視 為一種長期的投資。或許現在做了一點貢獻，數年之後，回報可能是無可估計的。

若只著眼在立即的回報，就是提出了一些解決問題的方法，而在此領域中得到他 人信任，也就是所謂的名聲(reputation)。

2.6 PCMM(people capability maturity model)

PCMM 起源是為了增加公司生存的機率，人員的流動率若過高，則公司無 法有穩定的人力資源幫助公司成長，公司生存的機率與公司員工的流動率有絕對 的關係，因此 PCMM 唯一套方法來減低人員流動率，並增加公司的整體競爭力。

1998 年的一份報告指出，持續改善工作力(workforce)的公司，獲利會比沒有改善 的公司高出 20%，也可以減少 7.05%的員工流動率。改善工作力的公司，其生存 率與獲利都會有所提高。有很多方法可改善工作力，但仍有許多公司在施行上有 困難或者進展緩慢，這是因為還缺乏了委任管理的因素，而 PCMM 即是將改進 工作力以及管理議題整合在一起的方法。

對於一般公司，有些東西是根深蒂固較難以改變的，像公司的文化等，要短 時間內改變公司過去的習慣並不容易，於是 Humphrey 提出了漸進式的方法，逐 步改善公司的文化以及行為，並改變工作力常規(workforce practice)以增加公司 的競爭力。

PCMM 是一套方法，以漸進方式加強管理，來改善發展團隊的內部管理。首 先提升單一專案的管理能力，進而提升整體發展團隊的能力。其中提升專案管理

方面的準則，恰巧可以提供開放程式碼團隊依循的方向。PCMM 分五階段，從一 開始沒有管理的第一層(initial level)開始，若可以成功地重複之前的範例(practice) 來避免造成混亂的情形；便可進到第二階段的管理層(managed level)，此階段強調 的是可以重複成功的範例，若每個單位(unit)做好管理的工作；即進入第三階段的 整合層(defined level)，此階段中，會把較好的範例整合成一個程序(process)，若 可 以 做 到 這 點 ， 組 織 即 已 建 立 起 其 專 業 的 文 化 基 礎 ； 第 四 層 是 可 預 測 層 (predictable level)，能對程序所表現出來的績效(performance)量化，加以分析評估 以對現有的範例做改進。應可重新產生(reproducible)，此階段可預測範例的績 效；第五層是最佳化層(optimizing level)，強調有勇氣改變，改變管理(change management)變成一種不斷進行標準的程序，組織內部一直做改進，找出使組織 獲利最多的程序以及減少常犯的錯誤來提升獲利。重點在強調管理階層一步一步 找出影響專案的因素，希望將 KPAs 其中一些重要的 process 加以量化成幾個程 度的指標，方便檢視專案的成熟度到了哪一個階段。

下圖 Figure5 代表 PCMM 在各層之間需要加強的能力

Figure5. PCMM 各個 level 演進的示意圖(from reference[2])

下表為 PCMM 之 level 分類以及其中之 KPAs(Key Process Areas) Table1.KPAs of PCMM

Level KPAs

2-managed staffing：分配工作、資源

compensation：給予名聲或實質的獲得

training and development：讓技能與工作可以相符 communication and coordination：爲未來的層級做準備 3-defined competency analysis：確保成員能力仍有競爭力

workgroup development：增加團體的競爭力 e career development：有更好的職位讓人去奮鬥

competency-based practices：確保範例(practices)爲了增加競爭力 4-predictable competency integration：把有競爭力的程序(process)做整合

mentoring：經驗傳承

competency based assets：competency process 相關的 asset，藉此增加競爭力

empowered workgroups：授權給 workgroup 對其負責的 business activity 負責

quantitative performance management：達到 measurable performance objects

organization capability management：管理以及量化整個 workforce 的技能

5-optimizing continuous workforce innovation：校準整體的績效

continuous capability improvement：提供基礎以增加競爭力 (在職進修等等)

organization performance alignment：評估新的想法，找出最合適 的實做

2.7 XP(Extreme Programming)

XP 是一開始不要規劃太多太深入，就目前的需要中，找出最急迫的一個，

以最簡單的方法做。不同於一般軟體發展，需要分析很多東西，再完整地實做。

這樣的方法適合用在變動性很大的開放程式碼世界，如果開發的時間太久，等到 軟體推出的時候，通常產品已經跟潮流脫節了。

XP 的原理就是，簡單的設計(simple design)及簡單的基本測試(simple unit test)，讓重複(iteration)的週期變短，錯誤可以及早發現及修正，而非等產品出來 之後，才發現產品規格已不符潮流了。

具體的活動(activity)方面，分成下列十二個：規劃遊戲(planning games)、小 量發行(small release)、隱喻(metaphor)、簡單的設計(simple design)、測試(testing)、

重 組 (refactoring) 、 雙 人 組 程 式 設 計 (pair programming) 、 集 體 程 式 碼 擁 有 權 (collective ownership)、持續性的整合(continuous integration)、每週 40 小時工作時 (40-hour week) 、 客 戶 全 程 駐 點 (on-site customer) 、 編 寫 程 式 碼 協 定 (coding standards)。沒有硬性規定都要做到，只是做到越多越好。

XP 代表的另一個意義是工作都可以在數分鐘內完成，甚至一天之內可以做 好幾個循環(iteration)。以下就是在數分鐘之內可以完成的工作。

XP 與一般軟體發展流程的不同在於，一般軟體發展模式是”do it right the first time”，而 XP 則是”do it right the last time”。XP 並不期望一開始就做到最好，

而是隨著時間以及需求的變遷，慢慢調整接下來的步調並對未來的方向作細部修 正。它強調的是將一開始詳盡規劃的時間省下來，多出來的時間用在後面的修訂 上。一般認為省下來的時間會比較多，因為一開始的規劃並不一定與未來的趨勢 契合，如果一開始就詳盡規劃，到後面要對程式碼進行大規模的修改反而更耗費 資源。

2.8 XP 與 PCMM 之相關性

XP 的特色可助組織提升 PCMM 中的成熟度等級。XP 中的規劃遊戲(planning games)以及快速的改版(small release)可助組織縮短到達 PCMM 成熟度等級二 (managed level)的時間。而到 PCMM 的 Level 3 之後，XP 較難提供有效幫助。因 為 PCMM 成熟度等級三強調整合以及管理，但管理的部分卻是 XP 最欠缺的，

因此 XP 無法適用於即時系統(real-time system)以及虛擬團隊(virtual team)。

XP 可以針對每個專案不同的特性提供不同的常規(practices)，這也是他具有 的彈性。XP 的溝通與簡單化也提供了 PCMM 所需的基礎。簡言之，XP 提供的 常規，可讓使用者具備提升內部成熟度的基礎，但若想將組織的成熟度推高到下 一等級的話，需用 PCMM 成熟度等級三之後的管理相關的程序(process)來幫助 協助。

2.9 XP 與 OSS(open source software)之異同

相同之處是立即的回饋(rapid feedback)以及高頻率的釋出版本(frequent releases)。立即的回饋在 XP 方面是面對面溝通，找出最迫切的需求並完成，開 放程式碼軟體是透過郵件名單(mailing list)作臭蟲報告(bug report)或是新功能要 求(new feature request)。高頻率的釋出版本，XP 完成一兩個新的功能立即釋出，

聽取顧客的評價及建議後，再做下一次的規劃並馬上實作，版本間的間隔很短。

而開放程式碼軟體版本釋出時間間隔會比 XP 的循環(iteration)長，但仍比商業軟 體的釋出時間間隔短。

XP 跟 OSS 不同的地方在於發展團隊的規模(team scope)以及溝通的方式 (communication way)。團隊的規模上，XP 適用在小公司的規模，OSS 的規模常 常是世界性的，沒有地理環境上的限制。溝通的方式，XP 強調的是立即回饋及 面對面溝通，發展者跟顧客都可清楚表達自己意見，但 OSS 溝通的方式是利用 email 居多，且受到各地時區不同影響，效率上會比 XP 遜色許多。

簡而言之，在地理區域小的地方發展開放程式碼軟體，可利用 XP 的優點，

來縮短釋出版本之間的間隔時間。下圖 Figure 6 表示了 Extreme Programming 與 Open Source 交集的部分以及不同的部分。

Figure 6 Extreme Programming 與 Open Source 的差異

2.10 Open Source Project and Open Source Community

一個發展良好的開放程式碼專案，通常會有一個組織完整的社群支持著。兩 者的關係是相輔相成的，專案提供軟體給社群成員使用，而社群提供了一個環境

一個發展良好的開放程式碼專案，通常會有一個組織完整的社群支持著。兩 者的關係是相輔相成的，專案提供軟體給社群成員使用，而社群提供了一個環境