jiing's blog (jiing.org)

開放源碼軟體成功之道

作者：Bernard Golden/著
譯者：范綱志
出版社：上奇科技
出版日期：2005 年 09 月 15 日

免費！不代表品質差，開放！不代表難以信任。

書本封面以一句話澄清了開放源碼常被人誤解之處。開放源碼早已成為一股新世代潮流，在《世界是平的》一書中，作者佛里曼（Friedman, L. Thomas）將開放源碼（open source）列為夷平世界的九大推土機之一。可見開放源碼軟體正改變著資訊科技世界。然而，使用開放源碼於企業內部比安裝一片Linux光碟複雜許多。如果你正嚴肅地看待利用開放源碼來削減費用、加速開發流程及減少被廠商綁住的情形，你必須有一套制度化的技巧，並且建立新的工作方式。你必須瞭解為何開放源碼不同於商業軟體，及它帶來什麼責任及風險。

本書作者是位對於使用開放源碼於業界實務有豐富經驗的人，並且對開放源碼的商業模式有一番深入的研究，書中說明了採取開放源碼的整個標準評估程序，提出一個正規的OSMM(Open Source Maturity Model)來評估開放源碼軟體是否能成為適用的解決方案，並以JBOSS這套middleware產品作為範例，套用OSMM模型來做評估。不過其評估的結果整個JBOSS的產品成熟度是78分，同時達到前期採用者及實用主義者可採用的標準門檻值。然而，據說我們公司的結果是不採用JBOSS......。OSMM的用意除了能快速地評估開放源碼產品是否適用之外（書中評估JBoss只用了一個人週的時間），另一個用意便是用來找出產品的哪些部份有不足之處，需要再加以強化的，連帶著便需評估公司內部是否有適當的人選/人力可支援，及是否有公司可提供合適的專業服務。

第一章中說明了open source與freeware的不同：只有open source軟體才會提供原始碼，並介紹了一些開放源碼的基礎概念；本書第二章中，提及了許多開放源碼的商業模式，事實上，開放源碼還是一座金礦，只是開放源碼的開發者蠻難直接從撰寫程式碼這件事上賺取合理的報酬，反倒是由教育訓練、文件、書籍、技術支援上較易獲取報酬。第三章則以學理的方式來簡介開放源碼風險，之後就是介紹開放源碼成熟度模型了及實際的評估給分方式。在書的第九章，也大略地介紹了以Web Service來整合系統的方式，並提及開放源碼與Web service間的關係－－Web Service提供了一個大一統的整合方式。

不過，我一直有個問題：封閉的商用軟體公司看了開放源始碼作者的程式碼之後，而不管其授權為何，將其程式的概念再改寫為自己的程式碼，那麼開放原碼的作者如何發現呢？是否就憑各人自由心證？

當然，開放源碼的作者可能會無私地分享，也絲毫地不在意是否使用者切實有遵守授權條款，但我有時也為質疑，那這樣授權方式不就白寫了？我們總希望用正面的眼光來看待世界，但不得不承認「有光明就有黑暗」的自然定律，是否有需要其它的防治措施呢？＠＠a

我自行整理了一張評估開放源碼軟體時的心智圖如下：

以下是個人筆記：

P4
現在的IT人員如果沒有把開放源碼的程式視為一種可行的替代方案，就等於是在扯公司的後腿。

P1-12
駭客代表的是一種具有高度技術性的個人特質，而非多才多藝的人格特質。

P1-17
「管理」志願者就是要想辦法讓他們對這些任務產生興趣。

P1-23
開放源碼軟體會成為所有IT組織資訊架構中重要的一環，善用社群的各項優勢會是開放源碼成功的致勝關鍵。

P4-9
從市場分佈來看，早期採納者大約佔了科技市場的15%，而實用主義者則佔了其他的85%。如果一間科技公司想要獲得明顯的利潤，就必須滿足實用主義者的需求。

P4-15 ～ P4-22

OSMM/開放源碼成熟度模型（Open Source Maturity Model™）的目的

OSMM的目的很明確，就是要快速地評估開放源碼產品的成熟度。隨著組織日益增加的開放源碼使用量，勢必會遇到有多個產品同時必須滿足單一需求的情況，此時他們該如何找出最好的產品呢？只要套用了OSMM，就能很快地依產品的OSMM分數排出優先順序。

OSMM的設計理念，是要讓一或兩個人員可以在3到5天內就計算出單一產品的總體成熟度分數，換句話說，只要一個小團隊就可在桌上檢驗出一個產品是否夠成熟，組織可否將它應用在軟體架構中。

OSMM的設計目的就是要協助IT組織，克服未來五年會遇到的一大挑戰：如何成功地運用開放源碼軟體。

當然，沒有一個模型可以完全反映任何組織的需求；單在桌上檢驗也不可能一絲不漏地查核整個產品。OSMM的目的是要求出值得再進一步全手動方式（包括實驗性質的安裝和操作練習）進行評估的產品。沒有任何方法可以取代詳盡的技術評估，但如果有一個方法可以先行識別出值得進一步評估的產品，可以大幅提高開放源碼的評估效率。

但是和所有工具一樣，OSMM有可能很聰明也可能變得很笨。如果不經過思考就隨意套用OSMM，反而會讓一個組織更快作出不正確的決定。如果抱持著謹慎的態度來用它，就會是很有價值的工具，可以讓組織很有效率地找出正確的選擇，當然，就能更妥善運用他們在開放源碼上的投資。

OSMM可作為決策流程的基礎，但是不能取代全面且詳盡的評估程序。

OSMM會分三個階段來評量產品的成熟度：

• 評估每個產品要素的成熟度並給予比分。
  
• 依組織的需求替每個要素定義權重。
  
• 計算產品的總體成熟度分數。

階段1：評估要素的成熟度

第一個階段會先找出關鍵的產品要素，並評估每個要素的成熟度。關鍵的產品要素，指的是成功運用一個產品不可或缺的因素。
關鍵產品要素有以下幾大項：

• 產品軟體
  
• 支援
  
• 文件
  
• 訓練
  
• 產品整合
  
• 專業服務

每個要素都會加以評估並以四個步驟的流程依序評分：
1. 定義組織需求
2. 找出資源
3. 評估要素成熟度
4. 給予1到10之間的評分

定義組織需求

必須定義該軟體必須具備哪些功能，才能滿足組織的目標（例如：要降低頻寬使用量、縮短反應時間等等...），定義每個產品要素的需求，是評估一個產品對某個組織是否有幫助的關鍵步驟。

找出資源

開放源碼產品的資源會分散在各處，要整合這些資源，相對於商業軟體會比較複雜。大部份產品都沒有所謂的「認證廠商」列表。此時要找出需要的資源會比較困難，但以下每一章都會提供一些識別資源的方法，協助您評估開放源碼軟體。

評估要素的成熟度

評定出要素屬於哪個成熟等級（從完全不存在到充份可實用）

給予要素分數

完成成熟度評估後，我們會給予一個介於0到10之間的分數，表示該要素的成熟度等級。分數愈高代表愈能滿足組織的需求。

成熟度分數也可以作為改進要素成熟度的判斷依據。一旦某個產品的總成熟度可以滿足需求，但其中一個要素成熟度卻過低，組織可以針對這個要素進行強化。

下表是建議的最低OSMM分數

	使用者類型
用途	早期採納者	實用主義者
實驗	25	40
測試	40	60
線上使用	60	70

階段2：設定權重因子

OSMM模型會幫每個要素的成熟度分數設定權重，如此可忠實反應出每個要素在總體成熟度中的重要性。組織可以依照自己的需求修改預設權重的值，舉例來說，如果某個IT組織比較缺乏人力資源，就會認為由專業且有提供服務的廠商開發的產品相對有較大的優勢。此時他可以把權重調大，以反應出專業服務的重要性。調整權重值唯一需要注意的地方，就是權重的總合必須是10.

階段3：計算產品的總體成熟度分數

P5-1
開放源碼最大優點，就是任何使用者都可以自由下載產品的原始碼。評估商業軟體時，可以藉由產品的說明文件得知產品具有哪些功能，產品的品質則可以利用專門的測試工具來檢測。這大概就是一般人評估產品時可以作到的極限了。

開放源碼產品則提供了更高的透明度，讓您可以進行更徹底的評估程序。原始碼可得性讓我們可以對程式碼本身進行檢驗和評估，此外還可以判斷出產品品管（QA）流程的內容和品質。

P5-3
明確的產品需求列表是開放源碼成功的關鍵。

P5-7
開放源碼的主要目標之一就是要善用其他人的經驗。

P5-14
開放源碼世界無法忍受笨蛋，因此你必須很有效率地和研發人員溝通。

P5-15
人們一般都很樂意分享自己的經驗，但不喜歡覺得自己被利用或濫用。

P6-1
務實的組織在真正開始使用開放源碼產品之前，都會先確定他們可以得到哪些支援服務。

p6-15
開放源碼的支援費用一般都相當合理。......，一般都會需要支付每小時100到400美金左右的費用，如此便能概算出一個合理的支援費用。

P9-19
如果你的組織決定繼續使用某個缺少某些整合的開放源碼產品，這一定要是一個很明智的決定才行，在未來不可以出現某些意外，因而傷害了整個專案的成敗。

P9-19
如果組織決定要建立一個整合，新程式碼上線後的表現也是個大問題，等到上線才來尋找這個問題的答案似乎太慢了點！

相關連結：

• 開放源碼軟體成功之道一書作者的email
  
• OSMM(Open Source Maturity Model)
  
• 有OSMM評估的空白樣板可供下載
  
• Open Bar
  
• 自由軟體基金會
  
• 裡有份對開放源碼社群使用者的問卷
  
• Source Forge
  
• 可找到超過20種不同的開放源碼授權
  
• Security Code Review Guidelines Adam Shostack
  
• Code Review Tools
  
• tools for static code analysis
  
• How to Evaluate Open Source Software
  
• Perl : why  review code
  
• Is Open Source Secure?
  
• OWASP