我們談過: 最好的程式起自於作者個人要解決他每天的切身之痛, 然後因為 這通常也是許多人的痛處, 所以這個程式便開始散佈, 這讓我們把 [格言 1] 用 另一種更有用的說法來陳述:
[格言 18] 為了要解有趣的問題, 開始找你感興趣的問題吧!
18. To solve an interesting problem, start by finding a problem that is interesting to you.
所以 Carl Harris 寫了早期的 popclient, 而我寫了 fetchmail, 然而這句格言 應早已為人所知許久, Linux 和 fetchmail 發展的歷史似乎要讓我們注意到這 有趣的一點, 就是軟體發展的下一步 -- 使用者和協同發展者組成了龐大而活耀 的社群, 帶動軟體的演化.
在 <<人-月的迷思>> 一書中, Fred Brooks 觀察到: 程式師的時間具 不可替換性, 在一個進度已經落後的專案中, 加入更多的發展者只會使進度 更加落後, 他討論到一個專案的複雜度和人員間溝通的代價以參與發展人數的 平方倍成長, 而完成的進度只隨人數做線性成長, 這個聲明自從發表以後, 就被稱為 Brooks 定律且被視為真理, 但假如 Brooks 定律主宰了一切, 那麼根本就不可能有 Linux 這個作業系統.
Gerald Weinberg 的經典著作 <<計算機程式寫作之心理學>> 中有 後見之明, 提出對 Brooks 定律極為重要的修正, 在 Weinberg 對 ``無私程式 寫作'' 的討論中, 他觀察到在軟體工作室中, 如果程式師們不會只 ``自掃門前雪 '', 反而鼓勵其他的程式師去看他們的程式, 以找出錯誤或提出改進的建議, 那麼程式改善的速度會遠超過每個程式師只顧自己的部分.
也許 Weinberg 的術語選擇不當, 以致於原本該為人所接受的觀念卻未被接受, 當想到用 ``無私'' 來形容網際網路上的電腦行家, 令人發出微笑, 但我認為他 的論點在今天要比過去更有力.
UNIX 的歷史其實早已準備好我們從 Linux 學到的東西 (以及經由我實驗得證的 事情, 這個實驗經過仔細地仿效 Linus 的方法, 但規模較小), 當大家還認為 寫程式仍然是單打獨鬥的行為時, 真正了不起的行家已經在善用社群的注意力和 腦力. 在一個封閉專案中的程式發展者, 他們只單靠自己的頭腦, 所達成的進度 將落後於知道怎麼搞一個開放專案的發展者, 因為在開放的專案中, 有數以百計的 人從事回報錯誤及改進程式.
但是傳統 UNIX 的世界因為好幾個原因, 以致於無法把這個方法的功效發揮到最大 , 其中包括: 不同版權的法律限制, 商業機密, 市場上的利益等等, 還有一個原因 (算是後見之明) 就是: 當初的網際網路還不夠發達.
在廉價的網際網路來臨之前, 有一些地域性的社群集中在一起, 他們的文化鼓吹著 Weinberg 的 ``無私'' 程式寫作, 其中的程式發展者可以輕易地吸引許多 有技巧的建言者和協同發展者, 如貝爾實驗室, 麻省理工學院人工智慧實驗室及 加州大學柏克來分校 -- 這些地方都是創新的來源, 都帶有傳奇性的色彩, 至今都仍具有影響力.
Linux 是第一個致力於把全世界當成是它智庫的專案, 我並不認為在 Linux 的 孕育期恰好誕生了全球資訊網是個巧合, 而且在 Linux 發展的早期, 網際網路 服務供應商的事業正在起飛, 網際網路的商機主流正在爆發, Linus 是第一位 學習在網際網路普及的情況下, 如何進行新遊戲規則的人.
雖然廉價的網際網路是 Linux 模式演進的必要條件, 但我認為它並非充分條件, 另一個極重要的因素是專案中領導人的領導風格, 以及一群合作的客戶, 其中 有人會被發展者吸引而成為協同發展者, 進而把網路媒體的功能發揮到最大.
但我們要問什麼是領導風格? 客戶是那些人? 他們之間的關係並非依賴權力而建立 -- 或者就算是, 強制的領導風格沒辦法帶給我們今天這樣的成果, Weinberg 引用 十九世紀俄國無政府主義者克魯泡特金自傳中 ``紀念一位革命家'' 的一段, 來解釋這個問題:
``因自幼在擁有佃農的地主家庭中長大, 當我的生命開始活躍時, 就像那時所有的 年輕人一樣, 我們非常相信命令, 指使, 責罵以及處罰等等行為的必要性, 但當 我早期必須管理正式的企業時, 我要和自由的人打交道, 任何錯誤可能最後都會 引發嚴重的後果, 我才開始欣賞 '命令和規定' 與 '建立共識' 兩種行為間的 不同之處, 前者在軍事體系中效用極佳, 但在真實的生活中卻一文不名, 真實生活 中的目標, 是在許多人同心協力下達成的.''
``許多人同心協力'' 正是像 Linux 這樣的專案所需要的 -- ``命令法則'' 並不適用於無政府主義者天堂 (我們叫它網際網路) 的志願工作者, 為了 更有效的運作和競爭, 想要領導與他人合作的專案的電腦行家, 必須學習如何 吸引和激勵有興趣的社群, 並且是在克魯泡特金所建議的 ``建立共識'' 原則的 模式下進行, 他們也必須要學習去使用 Linus 定律.
稍早我提及 ``Delphi 效應'' 是為了它可能可以解釋 Linux 定律, 但在生物學和 經濟學中的自我調適性系統中, 有更多類似的地方可以更有力地印證它, Linux 的 世界從許多方面看來, 像是一個自由的市場或生態, 由一群個體所組成, 這些個體 以一種自發性的自我更正程序, 試著去發揮他最大的功用, 所發揮出來的功用比起 集中式的規畫要來得更精巧, 更有效率, 這種方式正是在尋求 ``建立共識''.
Linux 行家們發揮到最大的功用不是典型的經濟價值, 而是在行家中得來無形的 自我滿足和榮譽, (你也許可以認為他們的動機是 ``利他'', 但這忽略了一項事實, 就是利他主義只是利他主義者自我滿足的一種型式), 以這種方式進行的志工文化 並非真的不尋常, 就我長期參加的一個科學小說迷俱樂部來說, 它不像電腦行家迷 俱樂部那麼明顯地以 ``egoboo'' (在同好圈裡強調某人的榮耀) 做為驅動志工的 力量.
Linus 在 Linux 專案中, 成功地坐上專案守門員的位置 (這個專案大部份的工作 都由其他人所完成), 也成功地培養專案的利基, 直到它可以自我維持, 這顯示 Linus 精確地抓住克魯泡特金所說 ``建立共識'' 的精神, 用這個似經濟學的觀點 來看 Linux 的世界, 讓我們知道 ``共識'' 是如何作用的.
我們可以把 Linus 的方法, 視作一條開創有效率市場的路 -- 以最強韌的方式 聯合個別的行家來達成困難的目標, 這些目標只有在持續的合作下才能達成. 在 fetchmail 的專案中 (雖然規模比較小), 我已經展示出 Linus 的方法可以 用在別的專案, 並同樣有好的成果, 或許我有意地, 更有系統地利用他的方法.
許多人 (尤其是不信任自由市場的人) 以為重視自我的個體文化會造成分裂, 自掃門前雪, 浪費, 私密, 和敵對, 只要舉一個簡短的實例, 就可以很明顯地 證明這個看法是錯的, 這個例子就是 Linux 相關的說明文件的多樣, 品質, 和 深度都相當令人驚訝, 程式師不喜歡寫說明文件似乎是金科玉律, 但 Linux 的 行家們是如何寫出這麼多的文件呢? 很明顯地, Linux 重榮譽的自由市場運作 得要比商業軟體生產者重金投資的說明文件撰寫公司好.
Fetchmail 和 Linux 這兩個專案都展示出藉由適當地回報許多行家, 優秀的發展 者或協調者能利用網際網路, 獲得許多協同發展者, 但不致讓專案因混亂而失敗, 所以針對 Brook 定律, 我提出以下的反駁:
[格言 19] 假如專案發展協調者擁有至少跟網際網路一樣好的媒體, 而他也不靠強制力來領導, 那麼一群人必定勝過一個人.
19. Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
我認為開放性原始碼軟體的將來屬於知道如何進行 Linus 遊戲規則的人, 屬於 離開教堂擁抱市集的人, 這並不是說個人的眼光和明智不再重要, 而是我認為 開放性原始碼的軟體的優勢將屬於一種人, 他以個人的眼光和明智開始一個專案, 並且之後能有效地號召有興趣的志工群來加入他的專案.
也許不只是開放性原始碼的將來, 非封閉性原始碼的發展者也能吸引 Linux 社群 的智庫到他們的問題上, 很少有人付得起 fetchmail 專案中超過兩百位的貢獻者.
也許最後開放性原始碼軟體會贏, 但不是因為合作是善的, 而囤積是惡的, (可能 你相信後者, 但 Linus 和我則否) 而是因為封閉原始碼的世界無法在演化的角力 中勝過開放性原始碼的社群, 開放性原始碼專案投入純熟的人時要比封閉性原始碼 的專案來得多.