軟件時代|開源 希冀還是噩夢？

對于開發(fā)者社區(qū)以及開源模式的缺乏重視，正在成為阻礙傳統(tǒng)車企加速軟件化和智能化轉型的攔路虎之一。

文丨錢伯彥

“抱歉，該網(wǎng)頁無法訪問。”

“Proxy訪問被拒絕，錯誤碼403。”

“您訪問的頁面不在信任名單內，請聯(lián)系您的系統(tǒng)管理員。”

隨著軟件定義汽車概念的大火，無論是汽車廠商的高級管理層、汽車產(chǎn)業(yè)的決策制定者還是資本市場的投資基金經(jīng)理們，都對這個代表著汽車業(yè)未來發(fā)展新希望的概念充滿著期冀。但是至少對于傳統(tǒng)汽車企業(yè)的IT部門來說，這卻是一個噩夢。

在這個汽車軟件工程師在車企中變得越來越重要的新時代，員工最常訪問的網(wǎng)頁名單上也出現(xiàn)了諸多新名字：除了傳統(tǒng)機械工程師必備的工標網(wǎng)以及市場部需要的各類經(jīng)濟數(shù)據(jù)網(wǎng)站之外，包括GitHub、CSDN、StackOverflow、DockerHub在內的開發(fā)者社區(qū)都已經(jīng)變成了車企工程師不可或缺的研發(fā)參考工具。

不過，在視開發(fā)者社區(qū)代碼共享為潛在技術外泄漏洞的傳統(tǒng)車企和其IT部門現(xiàn)行框架中，這些開發(fā)者社區(qū)無一例外地都在IT黑名單上。任何想要訪問開發(fā)者社區(qū)以尋求幫助的軟件工程師在瀏覽器中能夠得到的，只有報錯頁面。諷刺的是，即便是在大眾集團特意為汽車軟件化轉型而設立的軟件子公司Car.Software.Org內部也不例外。

全球各行業(yè)代碼中使用開源項目的比例顯示

Car.Software.Org德國因戈施塔特總部的IT部門支持工程師就向智庫君透露，目前部門日常工作中的大約三分之一內容都與開通各種外部開發(fā)者社區(qū)有關，而部門答復的建議也始終如出一轍：原則上予以拒絕，并建議軟件工程師使用私人電腦在開發(fā)者社區(qū)參與活動。

最熟悉的陌生人：開源社區(qū)

事實上，傳統(tǒng)汽車企業(yè)對于開源模式和開發(fā)者社區(qū)的興趣寥寥并不令人意外。

一方面，在大工業(yè)時代成長以來的各大傳統(tǒng)汽車巨頭內部早已制定了詳細的知識產(chǎn)權保護體系。無論是在公司電腦硬件端禁用USB等外接儲存設備接口，還是在電子郵箱中設置敏感詞和代碼過濾機制，在過去數(shù)十年里，制造業(yè)最重要的核心資產(chǎn)始終是濃縮了工程師心血的設計圖紙以及精密的生產(chǎn)工藝。出于對后發(fā)國家復刻設計方案的提防，對技術和專利的共享或開放從未在車企內部扮演過重要角色。

另一方面，正如大眾集團首席執(zhí)行官赫伯特·迪斯(Herbert Diess)所言，傳統(tǒng)汽車企業(yè)自身掌握的整車軟件代碼比例僅有10%。一直以來，出于控制成本以及對穩(wěn)定供應鏈伙伴的考量，傳統(tǒng)車企更習慣于從一級供應商手中直接采購已經(jīng)燒寫好軟件代碼的各類電控單元。而整車廠軟件部門在過去數(shù)十年內的工作重點反而是事務性的，例如為一級供應商制定軟件架構標準和通信標準，以及在整車層面上對來自不同供應商電子設備的適配和整合。越來越多的整車企業(yè)甚至將軟硬件的整合適配工作也外包給工程咨詢公司。

陳舊的硬件思維以及對車載軟件的大量外包都使得傳統(tǒng)車企的工程師確實無需在開發(fā)者社區(qū)中共享其技術經(jīng)驗或基礎軟件包，也缺乏足夠動力透過開發(fā)者社區(qū)和開源社區(qū)進行持續(xù)學習。

如今，隨著車載軟件在整車研發(fā)中占據(jù)越來越大的比重，對于開發(fā)者社區(qū)以及開源模式的缺乏重視，正在成為阻礙傳統(tǒng)車企加速軟件化和智能化轉型的攔路虎之一。

總部位于慕尼黑的寶馬集團一級軟件服務解決方案提供商itk的軟件工程師就告訴智庫君，為了加速進行軟件研發(fā)和標準化測試，軟件工程師們發(fā)揮主觀能動性變得越來越重要，而靈活使用開發(fā)者社區(qū)中的各類現(xiàn)有代碼和工具就是捷徑之一。遺憾的是，公司法務部卻對GPL、LGPL、MPL、MIT等各種開源項目的許可證類型缺乏了解，對于開源項目在何種條件下能夠進行商用和盈利也欠缺相關法律知識。這最終都導致許多汽車行業(yè)參與企業(yè)不得不耗時耗力地進行浪費時間的重復開發(fā)。

缺乏開發(fā)者社區(qū)共享思維的劣勢，還不僅僅體現(xiàn)在傳統(tǒng)整車企業(yè)對待外部開源項目的態(tài)度上，即便是在企業(yè)內部，碎片化分散式的部門領地意識也導致了大型車企不同部門存在著大量的軟件重復開發(fā)。

根據(jù)智庫君了解，不僅在例如奧迪和大眾品牌這種平行子品牌之間缺少類似GitHub的軟件托管平臺，即便是在博世集團的不同業(yè)務單元之間也缺乏泛集團的統(tǒng)一社區(qū)平臺。

“攪局者”特斯拉

不過，就如同特斯拉的馬斯克幾乎以一己之力重新定義了電動汽車一樣，將開源模式和開發(fā)者社區(qū)思維首次大規(guī)模注入保守的傳統(tǒng)汽車產(chǎn)業(yè)的“攪局者”依然是來自硅谷的特斯拉。

早在2014年6月，馬斯克就在其個人社交媒體賬戶上宣布將免費公開特斯拉的所有專利：“特斯拉不會對那些善意使用我們技術的人提起訴訟，特斯拉的專利都是開源的。”

雖然說馬斯克六年前的表態(tài)多少有些“嘩眾取寵”之嫌，畢竟當時特斯拉僅開放了車身技術相關的專利，而包括電池管理系統(tǒng)和Autopilot在內的代碼并不在開源范圍內，關于馬斯克希望通過開源模式做大電動汽車蛋糕、甚至形成技術標準壟斷“陽謀”的質疑也一直不絕于耳。但是自此以后特斯拉逐步將部分Autopilot以及內部開發(fā)工具進行開源化的努力卻實實在在地被推進著。2017年春季以后，特斯拉就開始在全球最大的軟件托管平臺GitHub上設立了官方賬號并開始逐步放開了超過40個軟件項目的權限。

特斯拉在GitHub上的官方賬號

2018年，特斯拉甚至還在GitHub上共享了Autopilot的系統(tǒng)鏡像以及Coreboot代碼庫。雖然這些核心代碼庫之后被特斯拉官方大幅精簡過，但是至今特斯拉仍持續(xù)不斷地維護著GitHub賬號。

除了不吝嗇于共享自家公司部分軟件代碼之外，打著科技企業(yè)名頭的特斯拉也極其擅長利用各類開源項目以壓縮項目開發(fā)時間。無論是buildroot、busybox等操作系統(tǒng)相關工具，還是類似QT的實用開發(fā)工具都在特斯拉內部得到了廣泛應用。為此，特斯拉與這些開源項目的開發(fā)者就是否遵守了許可證協(xié)議而屢次爆發(fā)矛盾沖突。

傳統(tǒng)車企擁抱開源

特斯拉對于開源項目運用得爐火純青的案例無疑便是基于開源Linux系統(tǒng)內核開發(fā)而成的特斯拉Version車載操作系統(tǒng)。

車載操作系統(tǒng)作為整車企業(yè)與科技企業(yè)爭奪未來產(chǎn)業(yè)鏈附加價值和用戶數(shù)據(jù)的主要戰(zhàn)場，一直以來大致可以分為三大陣營：傳統(tǒng)、安全性最佳、也是最為封閉的黑莓QNX系統(tǒng);開源且生態(tài)系統(tǒng)完善、安全性有待提升、谷歌與造車新勢力主打的安卓汽車操作系統(tǒng)(AndroidAutomotive OS);以及同為開源項目、特斯拉Version系統(tǒng)使用的Linux內核。

相比于正在垂垂老矣的QNX系統(tǒng)以及目前僅有以極星(Polestar)為代表的小眾廠商使用的安卓汽車操作系統(tǒng)，特斯拉選擇的開源Linux內核路線已經(jīng)吸引了幾乎所有全球車企巨頭的加入。

2014年，由Linux基金會管理的開源項目AGL(AutomotiveGrade Linux)成立，設立的初衷便是加速開放式的網(wǎng)聯(lián)化汽車軟件堆棧。2019年4月，決心設立獨立軟件子公司Car.Software.Org的大眾集團正式加入AGL。如果加上AGL的發(fā)起企業(yè)之一的豐田集團，年產(chǎn)量超過2000萬輛的全球最大的兩家汽車集團都已經(jīng)開始主動地選擇了開源項目模式加速車載操作系統(tǒng)的研發(fā)。Linux基金會給出的數(shù)據(jù)顯示，AGL聯(lián)盟成員根據(jù)Linux內核定制的車載操作系統(tǒng)中大約30%的代碼為車企獨有的排他性代碼，剩余部分均為開源框架下的通用代碼。

除了時間緊、任務重的車載操作系統(tǒng)研發(fā)之外，開源模式也開始在傳統(tǒng)車企的各個研發(fā)項目中扮演重要角色。

豐田集團此前就于2018年由豐田研究院牽頭投資1億美元開發(fā)開源的自動駕駛模擬器，2019年豐田又對外開放了2.4萬項包括電機、燃料電池在內的技術專利。而大眾集團早在加入AGL之前就已經(jīng)于2008年開始嘗試在CAN網(wǎng)關中使用Linux內核(即日后的SocketCAN)，該開源項目的成果如今依然在例如歐洲核子研究中心CERN等科研機構中得到應用。

根據(jù)大眾集團開源項目專家奧利佛·哈特科普(OliverHartkopp)給出的數(shù)據(jù)，使用開源SocketCAN之后的工作配比是2500萬行開源代碼加上2000行大眾工程師自己書寫的代碼。

不過，硬幣永遠存在著另一面。

開源項目困擾汽車企業(yè)最大的問題依然是安全。根據(jù)新思科技(Synopsys)發(fā)布的《2020年開源安全和風險報告》顯示，超過60%的開源代碼庫存在漏洞。相比于付費的專有軟件開發(fā)商會定期發(fā)布補丁并進行修復，開源項目對使用者的軟件技術能力提出了更高的要求。其中最著名的案例莫過于2014年網(wǎng)景公司旗下的OpenSSL開源庫安全漏洞事件，其最終影響了全球超過50萬臺網(wǎng)絡服務器。

此外，使用即用性的開源軟件，在享受著互聯(lián)網(wǎng)共享文化便利的同時，也意味著略顯古板的傳統(tǒng)整車制造商也必須接受與源代碼捆綁的許可證協(xié)議。除了較為嚴苛、難以商用化的GPL協(xié)議以及慷慨大方的MIT協(xié)議之外，開源的世界中還存在著至少千余種許可證協(xié)議。這其中甚至還包括詭異的“鴨子舞”許可證協(xié)議，即如果整車企業(yè)在車載軟件中使用過該開源項目的成果，那么車企的首席執(zhí)行官必須將自己跳鴨子舞的視頻上傳至社交媒體——對于馬斯克而言，尬舞或許早已經(jīng)輕車熟路，但是人們或許很難想象赫伯特·迪斯或者豐田章男的鴨子舞舞姿。