關鍵字：開源項目
開源解決方案在免去了昂貴的軟件采購成本的同時，也缺少了提供商的技術保障，這時的用戶該依靠誰來確保開源軟件順暢運行呢？ 從多個方面來看，商用軟件都價格不菲。而今，似乎嫌高昂的許可費還不夠嚇人，開發商只對它答應賣給你的產品提供服務支持，而且支持費用很難有討價還價的余地。除非你能獲得源代碼，否則你永遠無法自己修正軟件錯誤——但軟件開發商通常不會提供這些源代碼。
那么，我們該如何擺脫依賴于開發商的窘境呢？一種流行的選擇就是使用開源方案。這種非專有軟件具有諸多重大優點。比如，它是免費的，或者至少不需要什么許可費。此外，誰都能獲得其源代碼。結果出現了一批新的支持服務提供商，數量還在穩步增長。
雖然企業仍處在采用開源的早期階段，但這類軟件越來越為人們所接受。據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供應商以及產品和組件支持專家。讓你的內部開發和業務隊伍也要回復建議書，即把他們當成是外部供應商。
● 關注培訓和雇用能力，以增強內部支持水平。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
