自由軟體的故事：結語（上）

日前(https://www.openfoundry.org/index.php?option=com_content&task=view&id=1263&Itemid=335)我指出 Stallman 的堅持和自由軟體的原則是值得我們深思，究竟是什麼的意思？之前談到 Rebel Code 一書出版之後，開碼運動還繼續發展，其中一件事就是 BitKeeper。我可以由這件事件談起。

Rebel Code 中提到 Linus Torvalds 不能應付日益繁重的開發工作，甚至 Linux 企劃有被分支的危險。原來 Linus 由開始一直沒有使用版本控制系統去處理由社群貢獻而來的源碼，在開發社群中已有人自行採用 CVS 版本控制系統來增加效率，不過 Linus 始終不願意使用(註 1)。CVS 的單一中央儲存庫的架構的確不能完美地配合 Linux 企劃的分散式開發，但 Andrew Morton 等認為先採用 CVS，然後再開發新的版本控制系統是上策(註 2)。大家如果去 Internet Archive 找一找 Linux 企劃開發網站的歷史(https://web.archive.org/web/*/https://www.kernel.org)，2002 年 10 月在站上只有 FTP 和 HTTP 下載和電子郵件通信論壇。那時誰去 SourceForge 登記，都可免費使用版本控制和待辦事項等開發工具。不少其他的開碼企劃的開發網站都設計得比 https://www.kernel.org 好。如果不是局內人，只看網站，根本不會相信這就是那個最出名最厲害 Linux 企劃的家。Linux 企劃在使用開發工具上真的是落後。

Linus 為了改善效率，使用了源碼不開放的 BitKeeper 版本控制系統。這個版本控制系統採用了分散式儲存庫，十分適合 Linux 企劃。不過除了源碼不開放外，BitKeeper 作者 Larry McVoy 更加入了好幾條特別條款，最受爭議的是 BitKeeper 用戶不能參與 BitKeeper 以外任何版本控制系統的開發，也不能做 BitKeeper 的逆向工程(註 3)。Stallman 當然對 Linus 的決定作出嚴厲的批評(註 4)，有一些開碼運動熱心人士亦不同意(註 5&6)。不過以實務為考慮的 Linus 繼續使用 BitKeeper。

在 2005 年 Samba 開發領袖 Andrew Tridgell 開發了一個連接 BitKeeper 儲存庫的簡單程序(註 7)，被 McVoy 指控為逆向工程。McVoy 因此停止 BitKeeper 對 Linux 企劃的支援，開發社群結果還是要自行開發 Git 版本控制系統。批評者之前的論點結果成為了事實：

1. Linux 企劃的開發工具被他人控制了
2. 開發社群因為特別條款，好幾年也不能開發如 Git 合適社群使用的版本控制系統
3. 開發社群因為沒有 BitKeeper 的源碼而不能增強這個版本系統的功能

而且 McVoy 也不是容易跟人合作，他也有很強的控制欲，連已付錢的用戶也不可以參加開發其他版本控制系統(註 8)。Linus 小看了軟體自由的重要性，結果作出了錯誤決定，而且社群討論 BitKeeper 時常引起爭論，增加了內耗。

看過故事，得到的結論可以是就算 Stallman 再沒有以前的地位，他建立的自由軟體理論還是有實際的意義，需要堅持。就算我們不像 Stallman 般勉強所有人開放源碼，也必需推廣自由軟體的理想。不過論到平衡版權人和社會利益，Lawrence Lessig 在 The Future of Ideas一書中以法律和經濟的角度來分析問題(註 9)，比我只用幾個故事拼湊出來的結論嚴謹得多，大家可以參考一下。

自由軟體的故事中的一個更重要的啟示，是在這個日新月異的科技社會，我們其實不知成功會由哪兒鑽出來。當初誰會想到 Stallman 的哲學、GNU Project 和 GPL 授權條款真的會對軟體產業有影響。Linus 開始 Linux 企劃時還是個 Unix 初學者，也是發夢也想不到會如此成功。我們可以回顧一下黑客倫理（或作駭客倫理）中的幾條：

◎ 必須以實戰經驗為依歸。
◎ 所有資訊也要自由分享。
◎ 不信任權威，鼓勵分散的管理模式。
◎ 評價黑客只應以其技術水平出發。

讀 Rebel Code 時，發覺運動的參與者由各種各樣的地方鑽出來，例如 Perl 語言的作者 Larry Wall 是個虔誠的基督徒，本來讀了語言學想去國外傳教，結果把語言學的模糊性加入了 Perl，令它成為了很多開發者愛用的語言(註 10)。參與者之所以可以由各種背景出來，是因為黑客倫理不信任權威，也不要求參與者拿出證照。這樣的環境，可以鼓勵多元，增加溝通。在上面的 BitKeeper 故事中，Andrew Morton 可以始終如一地表達他的意見，而且結果不幸被他言中了，他也不用改口來挽回 Linus 的面子(註 11)。有一個多元的環境就是讓真相有生存的空間。

我們可以比較一下微軟的情況。有一個微軟開發部門的中層管理在網誌上寫了一篇有關 Vista 為何延遲的分析。我翻譯其中兩句：「深深體會在視窗的開發團隊中，還殘留了舊文化中的那種輕蔑和迫害。在開發團隊中，令人害怕說真話。」(註 12)這篇文章因為引起了不少關注曾經被封，不過因為微軟是在美國的，結果還是原原本本地再重新開放。一個組織失去效率，失去回應外來挑戰的能力，其中一個問題，就是真相再沒有生存的空間。

在開放源碼企劃中，最重要的源碼是公開的。如果企劃領袖時常做錯決定、偏愛某些參加者，另一班有心人可以下載源碼，另起爐灶，這個現象叫分支。前一篇也談到 GNU 企劃中的 Emacs、GCC 和 glibc 都有分支，GCC 的分支企劃 EGCS 結果勝出了，GCC 的源碼和團隊由 EGCS 取代。分支可以保存社群的多元性，平衡企劃領袖的權力(註 13)。封閉軟體當然也可以透過市場自行調節，不過如果是市場佔有率大公司的，反蝕的過程會很慢，效率也會降低，上面的視窗故事就是一個例子。

所以如果我們不知什麼會成功，與其為如何平衡版權人和社會利益下定論，不如開拓一個多元的空間，讓大家去實踐自己對版權的理念。如果我們能建立一個鼓勵多元和溝通的空間，真相自然會浮現出來。大家可能發現版權人和社會利益對立的分析方法並非最好；有一天可會鑽出了一個新的模式，新的天地。

這篇文章完結前我想再強調一下，原則這種虛無縹緲的事，很容易被實際的環境所淹蓋。Stallman 這樣頑固的麻煩人，更容易被人有意無意地排擠。有一次網上流傳 Stallman 反對 Miguel de Icaza 開始一個可以替代微軟 .Net 的 Mono 企劃。因為 Stallman 的形象對抗性強，有人信以為真。Stallman 結果出來推翻這個流言，他支持開發更多各式各樣編程有關的自由軟體，包括 Mono(註 14)。這種事情實在沒有須要發生。伏爾泰名言「雖然我不同意你說的話，但是我誓死維護你說話的權利」中所談及的包容，實在得我們去深思。在下一篇文章，我會談一下如何建立一個鼓勵多元化的溝通空間。

如果大家對我的文章有什麼的意見，都可以到以下網址討論一番：https://littleblackrabit.mysinablog.com/

(註 1) Shaikh, M & Cornford, T 2003, 'Version Management Tools: CVS to BK in the Linux Kernel', paper presented to 3rd Workshop on Open Source Software Engineering, Portland, Oregon, USA, 3-10 May, viewed 24 Jun 2003, <https://opensource.ucc.ie/icse2003/3rd-WS-on-OSS-Engineering.pdf>.
(註 2) Barr, J 2004, Bitkeeper after the storm - Part 1, <https://www.linux.com/articles/35954>.
(註 3) BitMover, BitKeeper license, <https://lwn.net/Articles/130758/>.
(註 4) Andrews, J 2002, Linux: Richard Stallman On GNU/Linux And BitKeeper, <https://kerneltrap.org/node/204>.
(註 5) chromatic 2002, The Problem with "Pragmatism", <https://www.oreillynet.com/onlamp/blog/2002/10/the_problem_with_pragmatism.html>.
(註 6) Fish, S, Better SCM on BitKeeper, <https://better-scm.berlios.de/bk/>.
(註 7) corbet 2005, How Tridge reverse engineered BitKeeper, <https://lwn.net/Articles/132938/>.
(註 8) O'Sullivan, B 2005, Why I am no longer working on Mercurial, <https://www.selenic.com/pipermail/mercurial/2005-September/004745.html>.
(註 9) Lessig, L, The Future of Ideas, <https://www.the-future-of-ideas.com/>.
(註 10) Wall, L 1999, 'Diligence, Patience, and Humility', in C DiBona, S Ockman & M Stone (eds), Open Sources: Voices from the Open Source Revolution, O'Reilly & Associates, Sebastopol, California, viewed 7 Nov 2000, <https://www.oreilly.com/catalog/opensources/book/larry.html>.
(註 11) Odium 2005, Andrew Morton on kernel development, <https://www.linuxformat.co.uk/modules.php?op=modload&name=News&file=article&sid=159>.
(註 12) philipsu 2006, Broken Windows Theory, <https://blogs.msdn.com/philipsu/archive/2006/06/14/Broken-Windows-Theory.aspx>.
(註 13) Raymond, E 2000, Homesteading the Noosphere, viewed 22 Dec 2000, <https://www.tuxedo.org/~esr/writings/homesteading/homesteading/>.
(註 14) Orlowski, A 2002, Stallman issues Porto Alegre clarification, The Register, <https://www.theregister.co.uk/2002/02/07/stallman_issues_porto_alegre_clarification/>.

You may be interested in the following articles:

• 自由軟體的故事：結語（下） - 2008-01-25
• 自由軟體的故事：Richard Stallman － 自由軟體之父 - 2007-10-26
• 自由軟體的故事：Linus Torvalds－Just for Fun - 2007-09-29
• 自由軟體的故事：Rebel Code - 2007-08-26
• 自由軟體的故事： Hackers（下）－駭客倫理的沒落 - 2007-08-10
• 自由軟體的故事： Hackers （上）－吃甜酸苦瓜的真駭客 - 2007-07-29
• 自由軟體的故事：序 - 2007-07-13