開源軟體需順暢執行 開源專案要怎樣實施(轉)

開源軟體需順暢執行 開源專案要怎樣實施(轉)[@more@]來自：計算機世界　


開源解決方案在免去了昂貴的軟體採購成本的同時，也缺少了提供商的技術保障，這時的使用者該依靠誰來確保開源軟體順暢執行呢？

　　從多個方面來看，商用軟體都價格不菲。而今，似乎嫌高昂的許可費還不夠嚇人，開發商只對它答應賣給你的產品提供服務支援，而且支援費用很難有討價還價的餘地。除非你能獲得原始碼，否則你永遠無法自己修正軟體錯誤——但軟體開發商通常不會提供這些原始碼。

　　那麼，我們該如何擺脫依賴於開發商的窘境呢？一種流行的選擇就是使用開源方案。這種非專有軟體具有諸多重大優點。比如，它是免費的，或者至少不需要什麼許可費。此外，誰都能獲得其原始碼。結果出現了一批新的支援服務提供商，數量還在穩步增長。

　　雖然企業仍處在採用開源的早期階段，但這類軟體越來越為人們所接受。據Forrester研究公司在2005年對北美100多位IT決策者進行的調查表明，2005年採用開源的公司多達56%，2004年只有46%。調查進一步發現，另外近20%的公司打算在當年使用開源軟體，而前一年只有14%。另外據Gartner公司的一份獨立研究報告表明，全球2000家組織當中有95%將在2008年前實施開源軟體購置及管理策略。

　　誠然，有些公司開放軟體的原始碼，只不過藉機營造聲勢，但不可否認，有關開放原始碼的經營模式在日趨成熟，早期的幾位開拓者已經發展壯大，為軟體行業的發展真正帶來了革命。雖然如今對開放原始碼保持合理的懷疑是合乎常情的、甚至是明智的，但在幾年後，開放原始碼經營模式也許會真正成為標準而不是例外。
　　儘管開源軟體非常流行，但不是每項開源計劃都是從管理層開始施行的。在許多組織，軟體開發隊伍是在獨立於CIO及其他IT領導人的情況下采用開源計劃的，而且往往後者並不知情。有鑑於此，CIO們最好不要逆開源潮流而行。恰恰相反，他們應當肩負開源計劃的責任，並且確保本公司已經落實了合理的支援結構。

　　沒有免費的午餐

　　為什麼軟體提供商會開發原始碼，像IBM或者Oracle這些公司到底有沒有能力免費贈送軟體？回答很簡單: 它們其實沒有這能力——至少從一個比較高的層次上看是這樣。

　　由於許多原因，傳統的套裝軟體拆封許可模式並不適合企業軟體: IT基礎設施變得更龐大、更復雜，按使用者數量或者按CPU數量計費的許可模式變得越來越難以管理，深奧、複雜的定價公式導致費用結構無法準確體現軟體的實際功用，更不用說會促使感到困惑的財務總監們挖空心思，想出種種新穎的記賬手法。

　　由於這些原因，Sun等一些公司已經做出了新的選擇: 棄用套裝軟體的拆封許可模式，改用純粹的訂購定價模式: 軟體本身是免費的，客戶需要花錢購買日常支援、維護及整合幫助等服務。

　　懷疑者可能會說，這只是另一種好萊塢式的記賬方法，裝模作樣而已。確實如此，從長遠來看，免去特定的許可費用未必意味著客戶會節省任何費用。

　　值得一提的是，已決定採用基於訂購的定價模式的公司離按服務收費只有一步之遙了。訂購－支援軟體模式就是開放原始碼軟體模式，剩下的就是開放程式碼—— 這正是Sun等公司正在做的事情。包括MySQL、AB和Red Hat在內的公司透過對免費軟體的企業級支援來收取費用，在生意上大獲成功。隨著這類新興公司不斷髮展、壯大，專有軟體開發商們肯定會問自己: 控制原始碼帶來的商業利益是不是果真大於這種新的軟體生存模式（即開放原始碼軟體）所帶來的其他利益。

　　社群很重要

　　與決定購買某一個商業軟體的決策時主要關注這家開發商信譽如何不同，在評估開放原始碼專案時，相關因素卻要複雜得多。對於軟體開發商和客戶而言，社群是開源軟體的重要組成部分，圍繞開放原始碼專案而建的社群是開源專案能否成功的關鍵所在。如果缺乏活躍的開發社群的支援，再好的程式碼也會慢慢老化、逐步消亡。
　　對於使用者而言，評估這些社群可能是軟體採購過程中面臨的比較困難的挑戰之一。在公司決定部署任何開放原始碼專案之前，經驗豐富的IT人員對專案進行全面調查很重要。開發社群是如何組織的？採用了什麼管理模式？哪些是最活躍的參與者？誰可以改動程式碼？改動頻率如何？內部爭議是如何解決的？程式碼的許可方式如何？

　　得到主要軟體開發商的支援，這可以為開放原始碼專案向企業使用者進一步證明可靠性，不過這也會帶來另外的問題。譬如說，商業軟體開發商對待社群組建的態度各不相同。有的認為組建社群純粹是自由放任的，而有的可能懷著這種希望: 利用自己的社群作為服務部門的銷售渠道。作為客戶，最好選擇這樣的公司: 不但宣傳開放原始碼，還明確劃分了開放原始碼專案和商業軟體專案的界限。

　　最終，每個IT決策都始於業務問題。解決這些問題仍是每個IT組織的首要任務。正因為如此，在評估開放原始碼軟體時應當著眼於以下幾方面: 特性、穩定性、擴充套件性、安全性以及專有軟體遵守的所有其他標準。

　　不過，開放原始碼數量激增自然的結果就是選擇更多了。最有能力權衡這些選擇的人就是最熟悉專案的人——他們知道社群的所有詳情，而且對專案的發展瞭如指掌。正因為如此，對最成功的公司而言，深入瞭解技術、技能嫻熟的IT人員無疑是重要資產。

　　開源軟體成熟嗎?

　　人們發現，開源軟體專案越成熟，使用者獲得的支援方案也就越成熟。譬如說，許多組織可以獲得JBoss的支援服務——JBoss是JBoss公司的一款開源應用伺服器; Covalent Technologies公司為流行的開源Web伺服器Apache提供支援。另外，成功的開源專案背後有龐大、活躍的使用者社群可提供技術幫助。

　　不過，並非所有的開源專案都擁有充足的支援——這對CIO們來說是個不足。在開源託管站點SourceForge.net上所列的10多萬專案當中，只有一小部分既有成熟的支援方案，又有活躍的使用者社群，實際上，這些專案當中只有1.7%被認為是成熟的。

　　確定哪些開源支援方案是最佳方案，這取決於諸多因素，其中包括組織在使用哪種開源軟體、使用方式以及組織本身具有哪些軟體支援能力。為了幫助CIO們做出明智的決策，不妨考慮以下六個技術支援方案:

　　1. 產品支援。一些成熟的專案得到了JBoss和Laszlo等開源開發商的支援，這些開發商透過提供服務來賺錢。開發商支援的這類專案仍被認為是開源產品。

　　根據JBoss的這種“專業開源”模式，使用者組織與眾多開發商簽訂不同協議。協議在所需的具體軟體、可用服務級別以及支援成本等方面各不相同。因而，開源產品組合越複雜，支援服務組合也會變得越複雜。使用者組織負責整合不同元件，並負責解決可能會出現的相容問題。

　　開源開發商提供的支援往往好於商用軟體開發商。與傳統的開發商不同，它們通常為客戶提供可以直接聯絡其開發隊伍的便利，而開發隊伍通常包括原始開發專案的成員。這些隊伍可以按需要改動專案的原始碼。

　　2. 開源中介軟體支援。如今已出現了統稱為開源中介軟體提供商（stack provider）的一批新公司，它們旨在解決: 整合及支援一家組織裡面的多個開源軟體元件。開源中介軟體提供商把通常使用的一套套開源軟體元件組合起來，併為這些元件提供服務，包括支援和整合測試。

　　幾個知名的商用軟體開發商包括惠普和Novell正在開發類似的開源產品。如果公司計劃使用一套常用的開源軟體元件，與開源中介軟體提供商合作也許能滿足需要。不過要注意: 大多數開源中介軟體提供商只支援最流行的元件。

　　此外，開源中介軟體提供商本身對軟體的瞭解程度通常不如開源開發商。正因為如此，一些組織選擇與能為客戶提供更高技能的開發商合作。這是個很好的折衷辦法。

　　開源中介軟體提供商的另一個不足就是，它們沒法僱用所有開源專案隊伍的成員。因而，一旦發現問題，它們只好與眾多隊伍協調可能改動程式碼的事宜，而不是直接改動程式碼。諸如此類的考慮因素可能會讓一些CIO不敢選擇“只有一個責任物件”的開源支援方案。

　　3. 社群支援。成功的開源計劃帶來了活躍的網上社群，這類社群可提供多種支援方式，包括郵件列表、討論論壇、甚至直接透過電子郵件與開源專案開發人員通訊。不過社群支援想獲得成效，組織要有強烈的主人翁感覺。
　　CIO千萬不要把社群支援與免費支援混為一談。完全依賴社群支援的任何一家公司實際上都是把支援問題交給自己來處理。比較明智的公司也會有內部專家: 一旦出現問題，他們就負責系統維護和尋求其他幫助。這些內部專家應當成為加入相應軟體的龐大網上社群的使用者。

　　與商用軟體開發商不同，開源社群不會根據企業的規模大小來優先對待使用者。也就是說，一家《財富》100強公司的CIO得到的支援級別與一家小型非營利性組織的CIO所得到的支援級別相同。同樣，一家大公司的開發隊伍所發的帖子不會自動得到優先處理權，哪怕這帖子是有關生產過程中的重大故障。要提醒的是，如果你向開源社群尋求支援，就要有一定的耐心。

　　4. 培訓現有技術人員。雖然開源軟體要求企業在很大程度上依靠自己，但未必需要新招技術人員。相反，企業可以對現有技術人員進行培訓，以便熟悉使用相關軟體。由於IT預算縮減、培訓機會漸少，這種舉措有望透過發掘新的增長點來提升員工們計程車氣。可以從越來越多的公司獲得培訓，其中包括Covalent、 JBoss和LearningPatterns。

　　5. 僱用專案開發人員。依賴開源軟體的一些組織僱用專職的開源專案開發顧問作為開發隊伍成員。增加專業人員幫助組織自身提升了技術實力，並且增強了自我支援能力。另外，擁有這些專案開發人員讓組織可以直接改動原始碼。

　　不過這種方案也有其侷限性。首先，必須慎重處理好客戶對開源專案會產生影響的這個問題，因為社群可能會覺得參與者是在為自己謀利，而不是有益於整個專案。其次，僱用開源專案開發人員需要財力資源，而擁有這筆資源的公司比較少。最後，一旦開源計劃規模迅速增加，這種模式不具備良好的擴充套件性，對專案開發人員的需求會超過現有人才的數量。

　　6. 藉助顧問。如果組織無力僱用開源專家、沒有時間進行內部培訓，或者不需要專業支援協議，那麼藉助顧問不失為一種切實可行的選擇。很容易透過開源專案郵件列表和開發隊伍名冊物色到專家。一些網上資源也有所幫助，譬如著名的FindOpenSourceSupport.com網站。2004年設立的這個網站列出了500多個開源顧問和提供商。

　　但藉助顧問最好是過渡性地，因為從長遠來看，他們的費用比較高，而且不如固定員工忠誠。他們可以逐漸對內部隊伍進行培訓，然後需要時仍可以隨叫隨到。

　　開源支援要講究搭配

　　獲得出眾的開源支援服務並不在於單單選擇其中一個方案，而是找到適合組織的最佳組合。沒有哪個解決方案能滿足所有組織的所有開源需要。CIO們應當先調查一下所有方案，然後在謹記自身需求的情況下，對諸多機會進行評估。

　　企業使用的開源軟體用於非關鍵系統還是生產環境這很有關係。從開發階段進入到生產階段，支援需求也會隨之變化。

　　儘管這道理聽上去很顯然，但許多組織常會犯這個錯誤: 對所有的支援需求一視同仁，不管涉及的風險有多大。這是因為CIO們習慣於同商用軟體開發商合作，這些開發商提供從開發到部署，甚至部署以後的支援。不過如果用的是開源軟體，可以獲得程式碼和網上使用者社群，假如組織內部的技術能力足以勝任的話，在評估或者開發過程中就不需要開發商的支援。這些早期階段的開源支援往往更加註重於學習曲線，這可能會讓一些公司受益。

　　一旦開源軟體從部署階段進入到實際使用階段，其支援需求就會酷似商用軟體。組織希望24×7的全面支援、服務級別協議、問題上報路徑以及明確責任。

　　如果系統涉及風險越大，圍繞軟體構建可靠的支援結構就越重要。雖然沒必要為非生產系統購買支援方面的“保險單”，不過對面向生產環境的系統來說提供可靠保障可能是基本要求。

　　隨著開源開發商竭力滿足企業使用者的需求，支援模式會繼續隨之發展。與此同時，使用者會逐漸接受軟體開發方面新的社群模式。

　　培養開源方面的專長和技能需要藉以時日，同時，還需要CIO們願意嘗試新模式來開展業務、管理資源。不過只要方法得當，開源軟體帶來的好處會遠遠超過風險。

　　連結:三個月部署開源專案

　　不同組織對開源支援的需求各不相同，這取決於組織所用軟體的類別和用途。你在著手擬訂支援策略時，還要把將來的需求考慮進來。下面教你如何開始著手:

　　第一個月: 審查當前及將來使用開源的情況。

　　● 詳細列出當前正在使用或者考慮使用的所有開源軟體。連員工一直未經批准但在使用的軟體也要考慮起來。

　　● 為每個開源元件確定內部負責人，並確定目前的服務如何提供。指定某個人負責確認的每個元件。

　　● 根據軟體對企業的重要性，確定每個開源元件所需的理想的支援級別。譬如說，生產環境中的開源軟體需要的支援級別要高於開發隊伍所使用的開源工具。

　　第二個月: 擬訂開源支援計劃。

　　● 與組織的法律和採購部門商談開源軟體事宜。開源軟體的使用不僅僅是IT開發部門的事，開發隊伍應當與業務隊伍密切合作。

　　● 擬訂開源支援計劃，包括明確定義預期目標。調查分析每個開源元件的所有支援方案。

　　● 檢查資助新計劃的預算。針對現有開源軟體的補充支援需要額外成本。確保新成本已考慮在內，提議把新成本列為下一個預算週期的新新增專案。

　　● 即使你在評估商用軟體，也要評估新的開源元件，並確定了選擇支援服務的標準。

　　第三個月: 開始推廣計劃。

　　● 記下哪些社群支援所有開源元件。

　　● 對現有IT供應商的開源技能級別及支援機會進行調查，評估另外的開源軟體服務商。

　　● 根據審查和支援計劃，為開源支援擬訂需求建議書（RFP）。把建議書發給提供商，包括現有的IT供應商以及產品和元件支援專家。讓你的內部開發和業務隊伍也要回復建議書，即把他們當成是外部供應商。

　　● 關注培訓和僱用能力，以增強內部支援水平。