現狀和問題
軟件項目開發中，爲了不重複發明輪子，不可避免的會用到不少第三方類庫、框架等開源技術實現，而面對同一種需求場景，往往有多種開源技術實現可供選擇，即便同一種實現，也有很多種版本。這些實現間存在功能上的重合點，同時也存在其獨有的特性，面對多種選擇，如何才能選到最適合的是需要仔細考慮的。
在一些企業中，開源技術選型方面尚沒有統一的標準和指導原則，衆多項目組獨立選型，系統開發所用的開源技術五花八門，版本也千差萬別。選型質量的好壞不但直接影響着軟件的質量，同時，也會給應用的維護帶來了不小的麻煩。
開源技術選型和管理意義重大，本文在開源技術的選型上提供一些參考，並就如何使用提出建議。
開源技術選型原則
開源技術選型需要遵循以下4個原則：
技術特性優秀
選型都是在功能特性有極大重合度的開源技術實現間來做，若只有少部分功能特性重合，則說明開源技術實現的定位不同，不具備可比性，優先選擇與我們定位需求一致的開源實現。
面對功能特性大面積重合的兩個開源實現，則再比較其實現方式。實現方式包含編程語言、技術架構等。不同實現方式帶來的差別是非功能特性不同，這些非功能特性包括可用性、可靠性、伸縮性、可維護性、可擴展性等多個方面，其中前4個是重點，可擴展性在某些可預見未來不需要擴展的場景下可不考慮。
優先採用技術成熟的產品，技術成熟表現在有發佈GA版本，版本號不小於1.0，發佈時間不短於1年，有比較多的使用案例，尤其是在大企業中被使用過。若沒有成熟技術實現或者面對多種成熟技術實現時，則比較其軟件發佈的RoadMap（路線圖/藍圖），優先選擇未來有企業級特性的更新計劃，版本更新較快速的產品，那些超過半年不更新的、未來沒有明確的升級更新計劃的不予考慮。
運作模式穩定
運作模式包括License模式、開發模式、測試模式、決策模式四個方面。
有些開源技術實現其實是部分開源，其軟件分爲社區版、企業版，一些高級特性只在企業版中才有，而企業版並不是開源的，是需要License的，若非必要，這種開源實現不予考慮。例如：大家都以爲Java是免費的，其中Java SE 包括免費的是JDK 和 JRE，但是 Advanced Desktop、Java SE Advanced 和 Java SE Suite 具備額外的功能，比如 Java Mission Control 和 Flight Recorder （也叫 JRockit Mission Control 和 JRockit Flight Recorder），這幾個版本都是付費的。對用任何一個開源軟件，都要考慮如果收費了怎麼辦,要有替換方案。
不同開源技術實現的開發模式不盡相同，有些開源技術實現有專門的團隊負責更新維護，有的則是純依賴社區力量，相比較而言，社區力量具備不確定性。
與開發模式相應的，測試模式也不同，大企業貢獻出的開源軟件往往是內部正在使用的，每一個版本的更新都是經過內部測試的，有獨立的測試團隊。而社區力量爲主的開源軟件測試往往不夠嚴謹，測試的成本轉移到使用者身上，所以大企業負責維護的開源技術更具優勢。
項目運作是被一家公司掌控還是鬆散的社區決策，以前都說大教堂不如集市，那是因爲以前大教堂基本上不搞開源，搞開源的大教堂和集市，就難說哪個好了。
提供者背景強大
考量開源軟件實現的提供者背景，需要從三個方面考慮。第一，是否在某行業有長期耕耘的經驗，這個行業與我們所屬行業有什麼區別嗎，比如用戶體量。第二，開源項目的需求來源是什麼，當初主要是爲了解決什麼問題才上馬的，這類問題是我們要解決的主要問題嗎。第三，該開源軟件是否在提供者內部使用，若正在內部使用，則軟件的質量、後續的軟件更新維護就有很大保證，否則難以保證。例如，Google發佈的開源產品大部分都是自己內部使用並測試過的，質量都非常好。
生態環境良好
生態環境是考量軟件未來發展前景的十分重要的因素，有些開源軟件得到了社區的極大關注，並且得到了很多IT巨頭的大力支持，未來發展前景一片光明，典型的例子如OpenStack。現在已表示支持OpenStack項目的大型硬件廠商包括：IBM、AMD、Intel和戴爾等。微軟在2010年10月表示支持OpenStack與Windows Server 2008 R2的整合。2011年2月，思科系統正式加入OpenStack項目，重點研製OpenStack的網絡服務。OpenStack成爲Ubuntu未來在堆棧方面的雲網絡化方案。2012年4月，IBM宣佈加入OpenStack項目，並作爲主要贊助商。2012年10月，Viacloud互聯雲平臺加入OpenStack項目，研製OpenStack公有云平臺和私有云平臺。IBM在2013年舉行的 IBM Pulse大會宣佈將基於OpenStack提供私有云服務以及相關應用。像OpenStack這種具有良好生態的開源實現是我們的優先選擇。
生態環境還包括社區的活躍度，使用者就越多，活躍度就越高，整個生態環境會非常的完整。
一項技術是否擁有廣泛的“朋友圈”也是我們需要重點考慮的，而這點往往又容易被忽視。短時間內不會有大的問題，關鍵是能否長期的可持續發展，和生態環境就有着密切的關係。
原則的原則
以上四個原則沒有優先級關係，每個原則的權重都是一致的，各佔25%。一個開源技術或產品要從不同的維度和視角去考量，並持續的進行總結和經驗的積累。
開源技術使用策略
建立統一的技術基線
建立統一的技術基線的意義在於，在同一個基線內的三方庫之間是有穩定兼容保證的。比如commons-logging、slf4j和log4j這幾個常用的日誌記錄開源庫，常常組合在一起使用，若沒有統一的技術基線，升級其中一個版本可能帶來Jar包衝突，相反，採用統一的技術基線，同一個基線下的這三個Jar肯定是穩定兼容的。當基線內有類庫存在重大升級或者滿足一定數量的更新時，經過仔細的兼容性和穩定性測試後，將基線版本提升後統一發布。就像Spring Cloud一樣，可以把Spring Cloud的大版本當做技術基線，在這個基線內Spring Cloud的各個組件如Eureka、Zuul、Rebon、Sleuth等都具有自己的版本，版本號並不一致，但是全部相互穩定兼容，當這些組件有較大的升級後，Spring Cloud相應提升一下大版本即可。
技術基線內不應僅包含開源類庫、框架等，還要包含內部自己開發的組件，這些組件具備複用價值，有擴展或改進的可能就有版本管理的需求，作爲二方庫，與三方庫同樣納入基線。
技術基線的管理在行內應有專門的團隊統籌管理，這個團隊負責技術基線的日常維護，包括基線內容擴充、版本升級、穩定性測試、兼容性測試、變更影響評估等工作。
功能驗證及測試
爲了避免一些開源軟件本身存在安全漏洞，首先應使用安全掃描工具進行排查。針對該軟件的核心功能進行功能驗證和測試，是否和宣稱的功能一致。例如：Mycat官方說支持prepare預編譯指令，但實際情況是傳遞給Mycat的數據準備發往客戶端時，僅做一個協議包轉換，將普通文本結果集協議包轉換成二進制結果集協議包併發往客戶端。就是這樣，讓客戶端看起來Mycat是真正地實現了預處理。其實Mycat宣稱的預處理並不是真正的預處理，最後發往後端（數據庫）時還是利用了普通協議，而不是真正的預處理協議。這一點可以從分析數據庫的預編譯性能指標（parse time elapsed和hard parse elapsed time）上看出來。
最後，建議有必要查看開源軟件的源碼，優秀開源軟件的代碼是非常規範的，例如：spring的源碼，從代碼規範、設計模式、軟件架構等多方面都是非常優秀的，完全可以當做模板進行參考。而有些開源軟件的代碼良莠不齊，開發者既有在校的大學生，也有經驗豐富的程序員。當然分析源碼雖然不是衡量的標準，但需要關注，因爲代碼是不會騙人的。
技術框架考覈
技術框架需從用戶和系統兩方面進行考量。第一，站在用戶的角度，第二，從系統的屬性看。如上圖，正代表不矛盾的，可以放在一起。負代表有衝突的，例如，平臺是高效的，那一定和操作性是衝突的。
基於開源項目做二次開發
二次開發過程需要先確定開源軟件跟隨策略，再設計編碼，測試發佈。開源軟件跟隨策略一般分爲兩種。一種是“私有分支”策略，一種是“社區先行”（Upstream First）策略。
私有分支策略即在公司內建立基於開源社區某個版本的私有的產品版本分支，並在其上增加定製功能，經測試後發佈給用戶使用。後續私有分支的版本隨開源社區版本發展而發展。私有分支版本前進一個版本時，選擇社區的一個新版本（不一定跟隨每個社區版本），然後合入以前開發的定製功能。這種策略爲國內外很多廠家採用。其主要優點是可以比較迅速的反應用戶的需求，及時的提供可用的解決方案和軟件給用戶使用。同時，作爲差異化競爭力的私有定製功能可以不開源，增強產品功能方面的競爭力。缺點是由於存在私有定製功能，導致跟隨社區版本發展時每次都需要進行功能整合並進行大量測試。這會消耗很多的工作量。而且存在未來社區中也出現了類似功能，導致私有功能與社區實現不兼容的問題。
社區先行策略指商用產品中所需的所有功能均首先在開源社區中進行開發，並貢獻到開源社區。商用版本直接繼承開源社區版本的功能，並根據產品需要進行模塊和功能裁剪。同時進行商用標準的測試工作。在測試中發現的故障，經修改後也及時貢獻到社區。這種策略的主要應用廠商是紅帽(Red Hat)。此策略的優點是，可以快速的跟隨開源社區版本。防止每次版本跟隨時需要額外合入大量自行開發的私有功能，消耗大量工作量。缺點是因爲社區版本節奏相對比較慢，從而導致商用版本在響應用戶需求方面有時會滯後。另一方面講，這也保證了企業用戶可以使用到更成熟穩定的開源技術產品。