早先看過這篇論文的書評家和試讀者都提出同樣的問題, 那就是以市集模式發展 軟體, 獲得成功的先決條件為何? 包括專案領導人的資格, 程式碼到什麼樣的 程度, 才對社群發表並開始成立協同發展團隊,
相當明顯的, 任何人無法以市集模式建立軟體基礎, 但是可以用市集模式來測試 , 除錯, 改進軟體, 在一個專案的起始點很難運用市集模式, Linus 沒試過, 我也沒有. 專案初始的協同發展團隊需要有一些東西可以測試, 可以執行.
當你開始召募專案團隊時, 你必須能提出大致合理的保證, 你的程式不需要運作 得很好, 它可以暴力, 有錯, 不完整, 及註解貧乏, 只要它可以使潛在的協同 發展者相信, 這個程式在可預見的未來大有可為.
Linux 和 fetchmail 公開發表時都具有強健及吸引人的設計, 許多人認為這和 我所報告的市集模式有所不同, 並以為這樣的設計很重要, 甚至進一步做出一個 他們的結論 -- 高度的設計直覺和聰明是一個專案領導人不可或缺的特質.
但是 Linus 的設計由 UNIX 而來, 我的設計由原先的 popclient 而來 (雖然 它後來改變甚大, 比例上說來還超過 Linux), 所以市集模式專案的領導人或 協調者真的需要格外的設計技巧? 或者能提昇別人的設計技巧呢?
我想對於專案協調者是否能做出耀眼的設計並不重要, 最重要的是協調者是否能 認知別人在設計上的好點子.
Linux 和 fetchmail 都證明了這件事, Linus 這位仁兄如同之前所討論的, 他並不是偉大的創新設計師, 但他展現了另一種卓越的技巧, 即認同別人好的 設計點子, 且將這些好的設計整合到 Linux 的核心中. 而我之前描述過 fetchmail 最有力的設計 (藉 SMTP 轉送郵件) 也來自他人.
這篇論文的早期讀者指出: 我有低估市集模式專案中創造力的重要性, 因為我自己 本身就已具備了許多的創意, 所以將此視為理所當然. 這真是抬舉我, 也許這說法 有幾分真實, 相對於寫程式及除錯, 設計應該是我最強的本領.
但以聰明和創意來設計軟體的問題在於 ``習慣的養成'' -- 當你應該保持程式的 強健和簡潔時, 反而把它弄得花俏而複雜, 我曾因犯了這個錯以致於把專案搞砸 了, 但我在 fetchmail 這個專案中小心地控制, 避免發生這種錯誤.
所以我相信 fetchmail 專案的成功部分的原因是我防止設計上 ``聰明'' 的傾向 , 這個論點 (至少) 已經反駁了設計上的創意是市集模式專案成功的基本條件. 以 Linux 來說, 假設 Linus Torvalds 在發展程式的過程中, 試圖在作業系統 的基本設計上力求創新, 那麼我們現在已有的 Linux 核心程式會如此穩定和 成功嗎?
當然, 任何想起始一個市集模式專案的人, 應該具備基本程度的設計能力和寫程式 技巧, 但我認為如果他們有認真想過, 那他們的程度應該已在低標之上. 開放性 原始碼社群對於名譽的重視, 給予其中的人們一種微妙的壓力, 如果無法勝任專案 後續的發展, 那麼就不會想去起始, 直到目前, 這種慣例似乎仍運作得很好.
還有一種技巧, 通常與我們不會把它和軟體發展聯想在一起, 但我認為這和市集 模式專案中聰明的設計一樣重要, 也許還更重要, 就是市集模式專案中的協調者 或領導人必須有人緣和好的溝通技巧.
這應該很明顯, 為了召集發展社群, 你需要吸引人們, 讓他們對你所做的有興趣, 並且保持他們加入後工作愉快. 技術上的末節很難達成這樣的目標, 更難以完成 整個專案, 你個人的人格特質也和專案習習相關.
Linus 是一位好人, 令人喜歡並樂於幫助他, 這不是巧合, 我精力旺盛, 活潑 外向, 喜愛為群眾們工作, 並具有喜劇演員的本能, 這也不是巧合, 為了讓 市集模式專案順利運作, 如果能用一點小技巧來吸引人們, 那幫助會很大.