開源產(chǎn)業(yè)白皮書（）前前言言當前開源技術(shù)快速發(fā)展，在云計算、大數(shù)據(jù)、人工智能等領(lǐng)域逐漸形成技術(shù)主流，開源技術(shù)已經(jīng)成為企業(yè)構(gòu)建信息系統(tǒng)的重要選擇，國內(nèi)企業(yè)參與開源生態(tài)的熱情度持續(xù)提升。

開源一方面可以突破技術(shù)壁壘，推動技術(shù)創(chuàng)新，另一方面也面臨知識產(chǎn)權(quán)、安全、技術(shù)運維等一系列與開源相關(guān)的風險問題。

抓住開源技術(shù)的快速發(fā)展機遇，有必要進一步健全開源生態(tài)、樹立開源風險意識、加強開源治理，推動我國開源產(chǎn)業(yè)健康快速發(fā)展。

《開源產(chǎn)業(yè)白皮書》首先通過調(diào)查問卷的形式梳理了開源軟件市場總體規(guī)模及應用現(xiàn)狀，然后從知識產(chǎn)權(quán)及合規(guī)、安全、技術(shù)運維三個角度分別對開源軟件的風險進行調(diào)查分析，進一步總結(jié)開源產(chǎn)業(yè)發(fā)展特點及趨勢，最后結(jié)合當前現(xiàn)狀給出了我國開源產(chǎn)業(yè)發(fā)展建議。

本白皮書采用電話訪談和在線調(diào)查相結(jié)合的方式，共回收有效問卷4,135份，同時利用代碼掃描工具對軟件的組件、許可證、漏洞等情況進行統(tǒng)計。

在數(shù)據(jù)采集、代碼掃描及編寫過程中得到了FOSSID等掃描工具和中國IDC圈的支持。

目目錄錄一、全球開源軟件市場規(guī)模及應用現(xiàn)狀1（一）開源產(chǎn)業(yè)鏈條逐漸形成1（二）全球開源軟件市場現(xiàn)狀2（三）我國開源技術(shù)市場應用現(xiàn)狀31、企業(yè)對開源技術(shù)的接受程度逐年增高.32、開源解決方案是企業(yè)的重要關(guān)注點.43、聯(lián)合開發(fā)成為企業(yè)部署開源的主要選擇.64、企業(yè)應用開源技術(shù)仍面臨眾多挑戰(zhàn).6（四）我國云計算相關(guān)開源技術(shù)應用現(xiàn)狀71、容器技術(shù)應用持續(xù)深化.72、虛擬化技術(shù)走向成熟期103、微服務應用逐步落地124、DevOps進入實踐階段14二、開源軟件風險調(diào)查分析.15（一）知識產(chǎn)權(quán)及合規(guī)風險.161、風險分析162、調(diào)查結(jié)果17（二）安全風險.221、風險分析222、調(diào)查結(jié)果23三、我國開源產(chǎn)業(yè)發(fā)展特點及趨勢.28四、我國開源產(chǎn)業(yè)發(fā)展建議.29附錄：開源軟件風險調(diào)查掃描軟件清單.30一、全球開源軟件市場規(guī)模及應用現(xiàn)狀（一）（一）開源產(chǎn)業(yè)鏈條逐漸形成開源產(chǎn)業(yè)鏈條逐漸形成開源即開放一類技術(shù)或一種產(chǎn)品的源代碼，源數(shù)據(jù)，源資產(chǎn)，可以是各行業(yè)的技術(shù)或產(chǎn)品，其范疇涵蓋文化、產(chǎn)業(yè)、法律、技術(shù)等多個社會維度。

如果開放的是軟件代碼，一般被稱作開源軟件。

開源經(jīng)過形成時期、古典時代、移動時代到云開源時代的不斷發(fā)展，開源產(chǎn)業(yè)鏈條已經(jīng)逐漸形成，其中涉及的企業(yè)類型包括：自發(fā)開源企業(yè)、開源產(chǎn)品企業(yè)和開源用戶企業(yè)。

圖1開源產(chǎn)業(yè)鏈條構(gòu)成自發(fā)開源企業(yè)指對開源社區(qū)做出貢獻的企業(yè)，如將企業(yè)內(nèi)已有代碼形成項目，公開發(fā)布于代碼托管平臺或捐贈給開源基金會，其代碼能夠被公開獲取。

著名的開源項目如Android、Linux、TensorFlow等，背后多為谷歌、微軟等科技公司。

近年來國內(nèi)華為、騰訊、阿里等企業(yè)均積極主動發(fā)起開源項目，主要集中在云計算、大數(shù)據(jù)、存儲、運維等領(lǐng)域，在國際上的影響力逐漸提升。

開源產(chǎn)品企業(yè)指基于社區(qū)版開源軟件提供發(fā)行版售賣給開源用戶企業(yè)，或針對主流社區(qū)版開源軟件提供服務（包括：軟件選型咨詢、軟件運維服務支持等）的企業(yè)。

開源用戶企業(yè)指從開源社區(qū)獲取開源軟件或代碼，用于自身信息系統(tǒng)構(gòu)建以輔助實現(xiàn)企業(yè)前臺業(yè)務功能的機構(gòu)，包括諸多傳統(tǒng)行業(yè)，自發(fā)開源企業(yè)開源社區(qū)開源產(chǎn)品企業(yè)開源用戶企業(yè)1如金融、電力、通信、能源等。

據(jù)Gartner調(diào)查顯示，99%的組織在其IT系統(tǒng)中使用了開源軟件，隨著開源技術(shù)快速形成生態(tài)，企業(yè)用戶引入開源技術(shù)已成大勢所趨。

（（二二））全球全球開源軟件市場開源軟件市場現(xiàn)狀現(xiàn)狀1全球開源熱度持續(xù)攀升。

截至，全球最大的代碼托管平臺GitHub已有3000萬開發(fā)人員，其中的新用戶數(shù)量超過了前六年用戶數(shù)之和；囊括的組織數(shù)目比去年增加了40%；擁有9600萬個代碼庫，超過三分之一的代碼庫是在18年創(chuàng)建的；已提交2億的pullrequest，僅在過去一年就創(chuàng)造了超過6000萬次。

中國貢獻者在開源社區(qū)中持續(xù)活躍。

截至，全球最大的代碼托管平臺GitHub上超過80%的用戶來自美國以外的地區(qū)，其中中國的貢獻者數(shù)目僅次于美國，排名第二；GitHub上的貢獻者數(shù)量是的1.6倍，其中中國的新注冊用戶數(shù)目僅次于美國，排名第二。

熱門領(lǐng)域開源項目涌現(xiàn)，公司成為開源的重要貢獻者。

，JavaScript（前端和后端）、機器學習、移動應用程序開發(fā)和容器是貢獻最多的領(lǐng)域。

其中，微軟VSCode、FacebookReact、谷歌TensorFlow位列項目活躍度前三甲（按貢獻者數(shù)目排序）。

整體來看，微軟、谷歌、紅帽、英特爾等頂級科技公司的員工是開源項目的重要貢獻者。

1數(shù)據(jù)來源：2（（三三））我國我國開源技術(shù)市場應用現(xiàn)狀開源技術(shù)市場應用現(xiàn)狀1、企業(yè)對開源技術(shù)的接受程度逐年增高超過八成的企業(yè)認可開源技術(shù)。

調(diào)查顯示，已經(jīng)應用了開源技術(shù)的企業(yè)占比達到86.7%，有計劃應用開源技術(shù)的企業(yè)占比10.6%，開源技術(shù)已經(jīng)被企業(yè)普遍接受。

圖2開源技術(shù)使用率調(diào)查（N=4135）數(shù)據(jù)來源:中國信息通信研究院技術(shù)成熟程度和功能豐富度是企業(yè)選擇開源技術(shù)時考慮的重要因素。

據(jù)調(diào)查，企業(yè)對技術(shù)成熟度的關(guān)注最高，達到68.7%；其次，46.3%的企業(yè)在選擇開源技術(shù)時會考慮功能豐富程度。

此外，還有43.3%的企業(yè)因縮短應用部署時間而選擇開源技術(shù)。

圖3企業(yè)選擇開源技術(shù)的考慮因素（N=4023）數(shù)據(jù)來源:中國信息通信研究院86.7%10.6%2.7%已經(jīng)應用有計劃應用暫時沒有計劃應用68.7%46.3%43.3%41.9%30.7%27.3%24.8%23.2%6.4%技術(shù)成熟程度功能豐富程度縮短應用部署時間節(jié)約成本生態(tài)完善程度自主性、可控性及可持續(xù)性降低試錯風險人才培養(yǎng)其他3缺少適合的解決方案和出于安全性考慮是企業(yè)尚未應用開源技術(shù)的兩個原因。

在尚未應用開源技術(shù)的企業(yè)中，認為缺少適合的解決方案的企業(yè)占比最高，達到43.4%，與去年相比提高了11.2%；其次，有35.2%的企業(yè)出于安全性考慮尚未使用開源技術(shù)。

其他因素還包括：現(xiàn)有技術(shù)不夠成熟（30.3%）、開源技術(shù)帶來的優(yōu)勢不明顯（16.4%）以及無法滿足合規(guī)要求（9.8%）。

圖4企業(yè)尚未應用開源技術(shù)的原因（N=550）數(shù)據(jù)來源:中國信息通信研究院2、開源解決方案是企業(yè)的重要關(guān)注點規(guī)劃設計和產(chǎn)品選型是最受企業(yè)關(guān)注的解決方案類型。

據(jù)調(diào)查，企業(yè)對于規(guī)劃設計類解決方案的需求最為強烈，占比達到了68.6%，相比上升了1.1個百分點；其次，57.6%的企業(yè)更關(guān)注產(chǎn)品選型，比去年提高了3.4%。

其他開源解決方案還包括實施路徑、運維管理和人才培養(yǎng)等。

43.4%35.2%30.3%16.4%9.8%2.5%32.2%37.4%33.0%13.9%19.1%3.5%缺少適合的解決方案出于安全性考慮現(xiàn)有技術(shù)不夠成熟開源技術(shù)帶來的優(yōu)勢不明顯無法滿足合規(guī)要求其他相比提高了0.9個百分點。

圖8企業(yè)開源技術(shù)實施方式（N=4023）數(shù)據(jù)來源:中國信息通信研究院4、企業(yè)應用開源技術(shù)仍面臨眾多挑戰(zhàn)歷史遺留問題多、異構(gòu)資源池管理平臺難統(tǒng)一、安全監(jiān)管以及合56.7%54.8%48.6%42.4%28.7%1.3%存儲大數(shù)據(jù)分析數(shù)據(jù)庫網(wǎng)絡中間件其他6規(guī)要求較高是企業(yè)應用開源技術(shù)面臨的重要挑戰(zhàn)。

歷史遺留問題多是企業(yè)應用開源技術(shù)面臨的最大困難，占比達到63.7%；其次59.8%的企業(yè)認為異構(gòu)資源池管理平臺難以統(tǒng)一。

此外，分別有42.6%和30.8%的企業(yè)表示安全監(jiān)管以及合規(guī)要求較高、物理設備種類多是其應用開源技術(shù)面臨的挑戰(zhàn)。

圖9企業(yè)應用開源技術(shù)面臨的挑戰(zhàn)（N=4135）數(shù)據(jù)來源:中國信息通信研究院（（四四））我國我國云計算相關(guān)開源技術(shù)應用現(xiàn)狀云計算相關(guān)開源技術(shù)應用現(xiàn)狀1、容器技術(shù)應用持續(xù)深化超過七成的企業(yè)已經(jīng)使用容器技術(shù)或正在測試應用環(huán)境。

據(jù)調(diào)查，36.4%的企業(yè)已經(jīng)使用了容器技術(shù)，相比提高了6.3%；其次，正在測試容器技術(shù)應用環(huán)境的企業(yè)占比達到34.2%，比去年減少了2.1個百分點。

此外，還有21.1%的企業(yè)正在評估容器技術(shù)。

5.4%12.7%30.8%42.6%59.8%63.7%其他人才儲備不足物理設備種類多安全監(jiān)管及合規(guī)要求較高異構(gòu)資源池管理平臺難統(tǒng)一歷史遺留問題多導致原有應用遷移困難7圖10云計算容器技術(shù)使用階段(N=918)數(shù)據(jù)來源:中國信息通信研究院支持快速彈性擴容和移植性強是企業(yè)選擇容器技術(shù)的優(yōu)先考慮因素。

調(diào)查顯示，出于支持快速彈性擴容和能夠?qū)崿F(xiàn)快速部署/移植性強考慮而應用容器技術(shù)的企業(yè)占比分別達到62.3%和61.8%；其次，有44.9%的企業(yè)認為容器技術(shù)有助于微服務框架的實現(xiàn)，相比提高了8.7%。

另外，可用性高（38.4%）以及管理便利（33.6%）也是企業(yè)應用容器技術(shù)的主要推動力。

圖11企業(yè)應用云計算容器技術(shù)的原因(N=648)數(shù)據(jù)來源:中國信息通信研究院缺少成功案例是企業(yè)應用容器技術(shù)面臨的最大挑戰(zhàn)。

調(diào)查顯示，36.4%30.1%34.2%36.3%21.1%24.5%8.3%9.1%上升了7.0%；其次，應用容器技術(shù)實現(xiàn)彈性擴容的企業(yè)占比達到50.6%。

此外，企業(yè)還將容器技術(shù)應用在多環(huán)境一致性管理和開發(fā)測試快速交付等場景中。

圖13企業(yè)云計算容器技術(shù)應用場景(N=648)數(shù)據(jù)來源:中國信息通信研究院47.1%31.2%30.6%24.8%相比增幅最大（4.3%）。

其他容器技術(shù)還包括：LXD、SolarisZones和LXC等。

圖14企業(yè)云對計算容器運行技術(shù)的選擇(N=648)數(shù)據(jù)來源:中國信息通信研究院2、虛擬化技術(shù)走向成熟期超過半數(shù)的企業(yè)選擇購買商業(yè)版OpenStack，并采用供應商的技術(shù)服務支持。

在OpenStack解決方案選擇的調(diào)查中，54.9%的企業(yè)選擇購買商業(yè)版的OpenStack并采用供應商的技術(shù)服務支持，相比上升了6.7%。

此外，還有33.1%的企業(yè)選擇定制化開發(fā)OpenStack，并自己負責技術(shù)支持。

圖15云計算OpenStack解決方案選擇(N=603)數(shù)據(jù)來源:中國信息通信研究院58.6%59.4%12.6%8.3%7.9%6.5%6.7%4.0%10.4%16.7%2.4%3.7%1.4%1.3%云計算年云計算OpenStack版本選擇版本選擇(N=603)數(shù)據(jù)來源:中國信息通信研究院在眾多組件中，Keystone最受企業(yè)歡迎。

使用Keystone組件的企業(yè)占比最高，達到48.4%；其次，分別有40.3%和34.8%的企業(yè)應用了Swift和Glance組件。

其他OpenStack組件還包括：Cinder（29.6%）、Ironic（27.8%）、Ceilometer（24.2%）和Heat（14.3%）等。

23.7%17.8%14.6%12.9%10.8%7.7%5.2%4.1%3.2%KiloIcehouseLibertyNewtonOcataMitakaQueensRocky其他11圖17企業(yè)應用的云計算OpenStack組件(N=603)數(shù)據(jù)來源:中國信息通信研究院3、微服務應用逐步落地超過六成的企業(yè)已經(jīng)應用或正在測試微服務框架。

在對企業(yè)微服務框架使用情況的調(diào)查中發(fā)現(xiàn)，22.8%的企業(yè)已經(jīng)應用了微服務框架；其次，正在測試環(huán)境的企業(yè)占比達到了31.6%；此外，還有28.4%的企業(yè)正在評估微服務框架。

圖18云計算微服務框架使用接受程度(N=918)數(shù)據(jù)來源:中國信息通信研究院超過六成的企業(yè)選擇SpringCloud作為其微服務框架。

據(jù)調(diào)查，48.4%40.3%34.8%29.6%27.8%24.2%14.3%5.3%KeystoneSwiftGlanceCinderlronicCeilometerHeat其他22.8%31.6%28.4%17.2%已經(jīng)投入生產(chǎn)環(huán)境正在測試環(huán)境正在評估暫不使用或不了解12選擇SpringCloud作為微服務框架的企業(yè)比例最高，達到61.2%；其次，有33.7%的企業(yè)認為ServiceComb更適合作為其微服務框架。

其他受關(guān)注的微服務框架還包括：Dubbo（26.6%）、ServiceMesh（12.9%）和Tars（8.6%）。

圖19企業(yè)對云計算微服務框架的選擇(N=499)數(shù)據(jù)來源:中國信息通信研究院缺乏運維人員和改造成本較高是企業(yè)未使用微服務框架的兩個重要原因。

調(diào)查發(fā)現(xiàn)，因缺乏運維人員而未使用微服務框架的企業(yè)占比達到39.3%；其次，有33.5%的企業(yè)認為改造成本較高是其未使用微服務框架的主要原因。

此外，分別有31.8%和26.9%的企業(yè)未使用微服務框架的原因是業(yè)務暫時不需要和技術(shù)人員缺乏了解。

圖相比提高了5.8%；其次，36.3%的企業(yè)表示正在測試環(huán)境。

此外，尚未考慮使用DevOps的企業(yè)僅有7.7%。

圖21企業(yè)云計算DevOps實現(xiàn)情況（N=918）數(shù)據(jù)來源:中國信息通信研究院Jenkins是目前企業(yè)使用最廣泛的開源集成工具。

調(diào)查發(fā)現(xiàn)，在諸多開源集成工具中，Jenkins的使用比例最高，達到39.3%；其次，分別有31.2%和以來多個開源軟件開發(fā)商（Redis、MongoDB、Kafka等）已經(jīng)對其過去使用的開源許可證進行了修改，Oracle宣布1月以后發(fā)布的OracleJavaSE8公開更新將不向沒有商用許可證的業(yè)務、商用或生產(chǎn)用途提供。

2、調(diào)查結(jié)果本白皮書利用工具對軟件源代碼進行掃描，設置規(guī)則為：若被掃描軟件中有超過5個文件與開源組件庫中的組件匹配，即認定可能包含該開源組件。

然而，受開源組件庫完整度和更新頻率限制，且算法匹配過程中可能存在誤差，本白皮書調(diào)查結(jié)果僅供參考。

2/licenses/license-list.en.html#GPLIncompatibleLicenses17熱門開源容器運行技術(shù)存在隱含風險，RKT和LXC均發(fā)現(xiàn)少量使用傳染性許可證的開源組件。

本白皮書對企業(yè)選擇最多的三個開源容器運行技術(shù)（Docker、RKT和LXC）進行掃描，結(jié)果顯示：Docker暫未發(fā)現(xiàn)使用傳染性許可證的開源組件，RKT和LXC中發(fā)現(xiàn)少量使用傳染性許可證的開源組件。

其中，RKT包含1個使用GPL許可證的開源組件，LXC包含1個使用GPL許可證的開源組件和1個使用LGPL許可證的開源組件。

圖24熱門開源容器技術(shù)許可證情況調(diào)查軟件名稱許可證類型組件名稱（帶有傳染性的許可證名稱）DockerApache-2.0/RKTApache-2.0go(GPL-2.0)LXCLGPL-2.1jdk(GPL-2.0)lxc(LGPL-2.1)數(shù)據(jù)來源:中國信息通信研究院熱門開源容器編排技術(shù)中，Kubernetes發(fā)現(xiàn)少量使用傳染性許可證的開源組件。

本白皮書對企業(yè)選擇最多的三個開源容器編排技術(shù)（Kubernetes、Mesos和Swarm）進行掃描，結(jié)果顯示：Mesos和Swarm0246810121416DockerRKTLXC開源組件數(shù)量GPLLGPLApacheBSDMIT18暫未發(fā)現(xiàn)使用傳染性許可證的開源組件，Kubernetes中發(fā)現(xiàn)3個使用GPL許可證的開源組件。

圖25熱門開源容器編排技術(shù)許可證情況調(diào)查軟件名稱許可證類型組件名稱（帶有傳染性的許可證名稱）KubernetesApache-2.0heketi(GPL-3.0)duplicatecheck(GPL-3.0)goproxy(GPL-2.0)數(shù)據(jù)來源:中國信息通信研究院OpenStack的7大常用組件未發(fā)現(xiàn)傳染性許可證。

本白皮書對7個OpenStack常用組件進行掃描，結(jié)果顯示：以上組件主要應用的許可證是Apache2.0，其中Swift、Ironic、Cinder等開源組件也包含其他的許可證，如：MIT和ECL-2.0。

051015開源安全現(xiàn)狀調(diào)查報告》顯示，過去兩年內(nèi)應用程序的漏洞數(shù)量增長了88％，僅NPM的漏洞數(shù)量增長了47％。

系統(tǒng)信息泄露、密碼管理、資源注入、跨站請求偽造、跨站腳本、HTTP消息頭注入、SQL注入、越界訪問、命令注入、內(nèi)存泄漏是開源軟件主要的安全風險。

本次調(diào)查對部分熱門開源軟件進行了代碼安全掃描，所用漏洞庫與美國國家漏洞庫（NVD）保持同步。

222、調(diào)查結(jié)果熱門開源容器運行技術(shù)中，LXC存在漏洞問題，Docker和RKT暫未發(fā)現(xiàn)漏洞。

本白皮書對企業(yè)選擇最多的三個開源容器運行技術(shù)（Docker、RKT和LXC）進行安全漏洞掃描，結(jié)果顯示：LXC中包含1個嚴重風險漏洞，1個中風險漏洞以及3個低風險漏洞。

圖29熱門開源容器技術(shù)安全漏洞情況調(diào)查軟件名稱嚴重風險高風險中風險低風險LXCCVE--8649/CVE--1331CVE--5985CVE--1335CVE--1334數(shù)據(jù)來源:中國信息通信研究院熱門開源容器編排技術(shù)中，Swarm漏洞問題突出，Kubernetes和Mesos暫未發(fā)現(xiàn)漏洞。

本白皮書對企業(yè)選擇最多的三個開源容器編排技術(shù)（Kubernetes、Mesos和Swarm）進行安全漏洞掃描，結(jié)果顯示：Swarm中包含1個嚴重風險漏洞，1個高風險漏洞以及1個中風險漏0123LXCRKTDocker安全漏洞數(shù)量低風險中風險高風險嚴重風險23洞。

圖30熱門開源容器編排技術(shù)安全漏洞情況調(diào)查軟件名稱嚴重風險高風險中風險低風險SwarmCVE--1002105CVE--9946CVE--1002100/數(shù)據(jù)來源:中國信息通信研究院OpenStack的7大常用組件中只有Keystone發(fā)現(xiàn)漏洞問題。

本白皮書對7個OpenStack常用組件進行掃描，結(jié)果顯示：Keystone包含2個高風險漏洞，5個中風險漏洞。

其他幾個常用組件暫未發(fā)現(xiàn)漏洞。

圖31OpenStack常用組件安全漏洞情況調(diào)查0123SwarmMesosKubernetes安全漏洞數(shù)量低風險中風險高風險嚴重風險0123456HeatCeilometerIronicCinderGlanceSwiftKeystone安全漏洞數(shù)量組件名稱低風險中風險高風險嚴重風險24軟件名稱嚴重風險高風險中風險低風險Keystone/CVE--5162CVE-2011-3147CVE--0757CVE-2014-7230CVE-2014-7231CVE--2140CVE--16239/數(shù)據(jù)來源:中國信息通信研究院熱門開源微服務框架隱含安全風險，其中Dubbo和SpringCloud存在漏洞問題，ServiceComb暫未發(fā)現(xiàn)漏洞。

本白皮書對企業(yè)選擇最多的三個開源微服務框架技術(shù)（Dubbo、ServiceComb和SpringCloud）進行安全漏