軟體開發真的沒有銀彈嗎？淺談世界級軟體開源社群運作

圖片來源：One Piece

無人不知的軟體神書人月神話：軟體專案管理之道(The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition)其中一個章節提到人月神話這個迷思，簡單解釋，以工程學來說，今天我用50個人建一間房子需要100天，那工程上因為可以拆解工作，所以理論值(大量的平均數來看)可以用500個人在10天內建一間房子；這就是一種人月工時結構的估算。

很可惜，軟體並不是工程。軟體開發是一個很殘酷用智商高低決定勝負的領域，以開著同一款車，一個頂尖的賽車手頂多就比普通會開車的人快個2-3倍，但軟體頂尖程序員跟普通程序員可以差到百倍(the measure indicators should be include quality, scalability and stability)。

但今天透過網路無遠弗界的集結，開始有著一絲可以打破人月神話的運作機制存在，這個機制就是開發者社群(Community)。一個好的開放原始碼社群透過制度、標準、流程、規範有效集結世界各地志同道合的夥伴。以OpenStack開源社群為參考說明。

開源社群運作基礎流程：

1. 先有個code base，最小可能就只有幾千、幾萬行程式碼，然後由一個或兩個單位維護研發，eg：NASA, Rackspace。
2. source被open，並且License Agreement被擴張為Apache License，簡單的說就是拿到這個授權的程式碼，你可以無償的使用他，拿來改、賣都沒關係，隨便你搞，但前提是組織不負後續責任。通常這時候就會開始吸引到市場的鯊魚。
3. 忘了說，一定要有個源碼版控系統。
4. 社群建立，會開始進行幾件事情：
• 建置官方網站，繪製個吉祥物mascot感覺比較沒這麼枯燥乏味。
• 釋放Release Note(說明這個版本主要完成哪些功能)、發佈各種進程的版本(alpha, beta, candidate, stable, )、發布版本、定出版號、
• 針對社群貢獻者(contributors)會給幾條較有法律性的規範CLA(Contributors License Agreement)，有點像是社群切割用的次元刀。以OpenStack來說他要分野的是你是不是服務工作於美國政府機關，但個人不知道為什麼要這樣特別分野，知道後再行補充。
5. 版本發佈後，來自世界各地的使用者抓下來用，使用過後發現bug，進行回報，然後社群透過bug tracker追蹤，再由developer認領。
6. 當bug越來越少，版本成熟到一個程度社群會再發佈新版本，而版標號碼有一套不成文的規範。
7. 在 Step.5 ~ Step.6 的過程，社群同時會不斷討論下一個版本的主要研發方向，也就是roadmap，接著不斷成長。

貢獻者工作有很多種，不是只有寫程式才能貢獻：

• Developer(程序員)
• Tester(測試員)
• Security(搞資安)
• Doc(撰寫文件)
• Designer(UX設計者)
• Website(官方網站管理人員)
• Translator(各國語系翻譯)
• Community builder(成功的社群，背後一定要有個優秀的女人；就是協助社群好好運作)
• 其他...

看到上述的工作分類不曉得身為一個資訊開發團隊的老闆、領導者不知道你有沒有什麼感覺，一個好的開發團隊、軟體產品就是需要存在這些角色。

如何確保源碼品質：

1. 關於程式碼的品質，社群具備固定的溝通會議
• 不斷的code review、code review、code review
• 每周一次的小型會議，範圍在系統功能上，主要就在做code review，或是討論一些怎麼設計、解決比較漂亮。
• 每月討論會議，針對模組層級進行討論。
• 每半年一次的大型submit，大家固定聚集在一個地方開會，社群的首腦們也藉此有面對面溝通的機會，這時候就是討論整個計畫的roadmap。這種會議通常都會有大型的廠商贊助，提供研討會場地、準備議程分享、講師費用、機票、住宿，觀察出席的人次、來源國家、參與層級、會議規模大概就可以了解一個技術的火紅程度。
2. Code要能被check in(問我什麼叫做check in? 我寫程式都可以直接check in阿? 拜託你直接洗洗睡吧...)，需要經過vote、code review，很嚴格，程式碼寫得不好的也是洗洗睡。所以傳說中矽谷大公司獵人頭都是直接到開源社群找Contributors一個個打電話，畢竟這些人早就被嚴格篩選過。
3. 光寫code是不夠的，記得還要寫test，沒有test也是過不了關；testing coverage足以衡量專案的品質。

但講到程式碼品質這個就傷感情了，畢竟高手寥寥可數，要是真的檢討下去大家都沒飯吃了。不過依個人的工作經驗看過不少從某些領域(消音)想轉過來的寫程式的，真的就是落差很大，雖然一樣都是資訊領域但邏輯或思考的規模上就是不及格，拜託你們不要在染指軟體這個領域，有機會再來開炮一下...