由 Linus 行為的研究中, 我們得到了一個能解釋他為什麼成功的理論, 所以我想 要在我的新專案 (當然不如 Linux 核心程式的複雜和雄心勃勃) 中來測試這個理 論.
但我做的第一件事情是大力重組和簡化 popclient 的程式, Carl Harris 的實作 非常紮實, 可是卻像許多的 C 程式師一樣, 含括了一種不必要的複雜, 他以程式 碼為主, 資料結構為輔, 因此程式碼看起來漂亮, 但資料結構卻很特殊, 甚至可 以說是醜陋的 (至少以這位老資格 Lisp 高手的高標準而言).
然而, 我重寫程式除了改良原來程式碼和資料結構的設計外, 還有其他目的, 就是 把它發展到我可以完全瞭解, 否則負責修補你不懂的程式是一件很無趣的事.
專案進行的第一個月, 我簡單地依循著 Carl 原來基本設計的用意, 第一個重大的 改變是我加入 IMAP 協定的支援, 我重組原來處理協定的程式, 改成一個較為通用 的驅動程式再加上三個驅動它的方法表 (即 POP2, POP3 和 IMAP). 這個 改變闡釋了一個廣義的原則, 特別在像 C 這種先天上未提供動態資料型態的 程式語言, 程式師們最好謹記在心:
[格言 9] 聰明的資料結構配上笨拙的程式碼要比相反的組合好.
9. Smart data structures and dumb code works a lot better than the other way around.
[譯注] 相反的組合指笨拙的資料結構配上聰明的程式碼.
Brooks 在 The Mythical Man-Month 的第九章中也說: ``光給我看你的 [程式碼], 而不給我看它用的 [資料結構], 我會一頭霧水. 給我看你程式的 [資料結構] , 我通常不需要再看你的 [程式碼], 因為已經夠明白了.''
事實上, 上述的這段話他是用 ``流程圖''和 ``表格'' 這兩個名詞, 但由於 三十年間專業術語/文化的變遷, 這些名詞的意義幾乎是相同的.
1996 年的九月初, 從零開始工作約過了六週, 我開始在想是否要幫 popclient 取 個新名字, 畢竟 popclient 已不僅僅是單純的 POP 協定客戶端程式, 但我遲疑了 , 因為 popclient 的設計並無真正重大的改變, 我的 popclient 尚須發展出自己 的特色.
當 fetchmail 可以把抓下來的信直接轉送到 SMTP 的接收埠時, 終於和以前不一 樣了, 至於 fetchmail, 我稍待會再說明. 我之前說過要用這個專案來測試關於 Linus 成功的理論, 也許你會問我到底要怎麼做呢? 我用下面幾個辦法:
1) 我儘早並經常發表新版本 (幾乎至少每十天就發表一次, 甚至在發展的高 峰期, 一天一次)
2) 對於每一位與我討論 fetchmail 的人, 我把他們列入 beta 測試者的名單 , 所以名單越來越長.
3) 每當我發展出新版本, 一定發出像聊天般的通知給 beta 測試者名單上的 人, 鼓勵他們一起來參與這個專案.
4) 而我也總是傾聽 beta 測試者的心聲, 詢問他們對於這個程式的設計上有 無意見, 並且回應他們送來對程式的修補和回饋.
在採用上述的辦法後, 立即就得到了報償, 自從這個專案開始以來, 我所收到關於 程式錯誤的回報, 其品質足以令許多的程式發展者羡慕, 這些回報甚至還常常附上 不錯的修補辦法. 因而我做了關鍵性的思考, 我收到了使用者的來信, 得到了關於 新增智慧型功能的建議. 這說明了:
[格言 10] 如果你視 beta 版測試者如同你最珍貴的資源, 那麼他們會以此做為回報.
10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
Fetchmail 達到成功的方法中, 有趣的是一張薄薄的 beta 版測試者名單, 也就是 fetchamil 之友的名單, 當我在寫這支程式時, 有 249 位, 然後每週增加 2 到 3 位.
這張名單中的成員人數最多時幾乎到達三百, 不過, 當我在 1997 年 五月底審訂 這張名單時, 其中的成員已經因為一個有趣的原因而開始減少, 好幾位告訴我他們 要停訂 ``fetchmail 之友'', 因為他們覺得 fetchmail 已能滿足他們的需求, 已經不再需要收到 ``fetchmail 之友''. 也許這是成熟的市集模式專案的 正常生命週期中的一部份.