程式碼與戰爭：從“新軟體危機”到開發工具自主化

1968年，著名的北大西洋公約組織在聯邦德國組織了一次學術會議，前來參會的是50多名北約各國的計算機專家、軟體工程師、工業界代表。會議只有一個主題：應對“軟體危機”。

在當時，大型計算機還沒有普及，但軟體開發帶來的巨大成本已經讓各國開始恐慌。歐美國家普遍發現，如果每個軟體都採取高度定製化的開發方式，那麼隨著軟體數量增加，開發成本和維護難度會拖垮產業鏈，甚至危及社會經濟安全。

最終，會議形成的應對共識，是國家必須發展軟體工程(software engineering)，確保自身掌握從開發語言、作業系統，再到軟體開發工具的一系列基座。用系統化、數量化的工程原則來實現軟體開發的低成本與高可控，從而避免產業經濟被軟體拖垮。

這一結論影響了此後數十年的全球軟體發展史。美國、歐洲、日本紛紛在基礎軟體與開發工具上重兵集結，一決雌雄。由此不僅在市場層面產生了一系列基礎軟體巨頭，在國家競爭層面，以美國為代表的已開發國家，可以透過基礎軟體與開發工具優勢牢牢掌控全球軟體發展，確保自身的領先地位。至此，軟體工程已經不再是一個技術問題，而是成為國家戰略安全問題。它帶來了很多結果，比如在基礎軟體中競爭失敗的歐洲、日本，喪失了後續資訊革命的主導權;又比如東南亞、印度等地，只能淪為美國的軟體外包商，喪失了底層創新機會。

軟體工程，從來都是一場發生在程式碼中的無聲戰爭。

時間來到21世紀，伴隨著全球化的大的發展，開源軟體與開源社群已經成為了主流的基礎軟體(尤其是軟體開發工具)獲取形式。中國、韓國、新加坡等國家的軟體產業，充分利用了開源機遇，用最低成本的方式獲得了成熟的軟體開發基座。但這種模式真的牢不可破嗎?甜蜜的軟體開發工具開源，真的會始終美好嗎?

當逆全球化與地緣紛爭的鐘聲敲響，我們驚覺風險從未消散，新“軟體危機”正在醞釀。

軟體，從來不只是個技術問題，而是企業乃至社會的命運問題。

討論“缺芯少魂”，不能忘記開發工具

這些年來，“缺芯少魂”“卡脖子”成為全民熱議的話題。誠然，晶片和作業系統是軟硬體兩大體系的核心。但要看到的是，我們缺和少的絕不僅僅是這兩樣東西。事實上，走向科技自立要補的課非常多，比如硬體層面的儲存、數控元件;軟體層面的開發框架、中介軟體、資料庫。其中不能忽略的一點，就是軟體開發工具。

軟體開發工具，是基礎軟體中的基礎軟體，也是應對“軟體危機”的關鍵。所謂軟體開發工具，是指軟體開發從創意到需求分解，再到設計、編碼、生成檔案，最終部署到對應環境中，各個步驟、流程所需要的必備工具支援。其內涵十分豐富，體系十分龐雜。

從開發流程上看，軟體開發工具一般涉及專案管理、程式碼託管、程式碼檢查、編譯、部署、測試、釋出等等，每個流程環節都有不同的工具。對於軟體企業來說，軟體開發工具需要儘量形成完整的工具鏈，這樣才能協同各個部門，管理整個軟體開發專案的流程與進度。而對於開發者來說，軟體開發工具需要儘量整合化、一體化，從而降低使用不相容工具開發帶來的綜合成本，實現敏捷、高效率地開發。

在這些動力的加持下，軟體開發工具不斷走向現代化，其價值也水漲船高，行業影響力隨之而來。

數字化時代裡有句名言，“軟體定義一切”，可以說，每家企業都將是軟體企業，每位研發人員都將是軟體開發者，每個基礎研發流程都離不開軟體開發工具。如果我們做一個逆向假設：大量軟體開發工具不能用了，會發生什麼?

就像缺了光刻機不能造晶片一樣，缺了軟體開發工具首先無法實現軟體開發。同時，大量軟體還將無法進行創新迭代，已有軟體很難進行維護和運營。這種情況，不僅直接威脅大眾生活中的APP與軟體應用，更會直接打擊依賴軟體的工業數字化體系與民生數字化基礎設施，這是任何人都無法承受的代價。

如今，軟體工具已經大量使用全球化的開源工具與開源平臺。那麼，我們不禁需要提出一個問題：這種模式，真的安全嗎?

後開源時代，新“軟體危機”來臨

隨著20世紀80、90年代資訊全球化的開展，頭部企業意識到開源是最有效形成生態、構建產業優勢的方式，於是基礎軟體開源成為全球化過程中一道亮眼的風景。到了21世紀，新進的軟體開發者、從業者，從開始就習慣了開源開發工具，將使用開源工具，加入開源社群作為一種常識。

當時間指標轉到今天，我們卻猛然間發現，開源的美好原來是那麼可貴與脆弱。它並非一成不變的真理，而僅僅是黃金時代的饋贈。

2022年3月，隨著俄烏衝突爆發，谷歌、蘋果、亞馬遜、微軟、Meta等軟體巨頭，以及SAP、Oracle等軟體公司都快速停止了面向俄羅斯的業務。大量程式碼託管平臺以及開源社群，紛紛在第一時間宣佈封鎖俄羅斯開發者賬號。俄羅斯方面也在3月底宣佈，禁止所有國家機構與半政府實體在關鍵基礎設施專案購買外國軟體。

可以說，在短短不到一個月時間裡，歐美就對俄羅斯，以及這個國家的軟體企業、開發者、數字化專案落下了軟體鐵幕。名義上開源開放的工具，在關鍵時刻沒有一個秉持固有原則，紛紛在地緣紛爭中站隊。

比如說，今天全球軟體開發者許多已經習慣在Github進行程式碼託管，甚至認為GitHub已經變成了一種開發者之間的“預設準則”。然而就在俄烏衝突開始不久，GitHub就對受到美國製裁俄羅斯實體的相關軟體開發者進行了個人賬戶禁用、內容清空等限制。Sberbank科技、SberbankAI實驗室、阿爾法資料庫實驗室等俄著名俄羅斯科技企業先是遭到了專案禁用，緊接著託管程式碼被整個刪除。甚至有俄羅斯開發者稱，他們只是先前與相關企業有過合作，目前合作關係早已結束，但依舊遭到了GitHub在沒有預先警示的情況下封禁賬戶。

這種情景，不禁讓全世界更多國家開始反思，開源工具真的萬無一失嗎?它真的獨立於政治和地緣之外，是一種純粹技術的第三方價值嗎?

答案顯然是否定的。一旦底線被打破，那麼它就會一次次被打破。一次次國際紛爭，讓我們看到了“後開源時代”已經到來。開源工具與開源平臺，根本不獨立於國際局勢，甚至可以在必要的時候作為國際紛爭中的工具、砝碼，甚至是武器。

這也在某種程度上預示著，新的“軟體危機”已經到來——20世紀60年代的軟體危機，是缺乏軟體工程基礎會面臨危險;今天的軟體危機，是當你習慣了被他人控制的軟體工程基礎，那麼危險也如影隨形。

應對軟體工具失控，中國準備好了嗎?

開放與發展無疑是全球化的共同目標，我們當然不希望開源軟體工具被封鎖。但《三體》裡的情節告訴我們，當你不準備應對危機，危機就已經不遠了。

事實上，中國的軟體生態，尤其是生產軟體的工具箱，還是非常脆弱的。工信部資料顯示，從2000年至2020年，中國軟體市場整體規模實現了135倍增長，美國為3.2倍;2020年，中國軟體產業規模佔全球軟體產業的24%，佔GDP比重約7.9%。中國軟體產業在20年中實現了舉世矚目的騰飛。但這種經濟奇蹟，其實是建立在他人提供的基礎和底座上的。

根據中國軟體協會的調研資料，2020年，在全球作業系統、基礎軟體領域，美國業務收入約0.81萬億美元，佔全球比例五分之四。而中國基礎軟體份額較少，國產軟體的國內市場份額僅為5%，國產作業系統的國內市場佔有率僅4%。

國產基礎軟體體系薄弱、市場份額低的軟肋，已經暴露在了國際格局中。從2019年至今，已有超過600家中國企業、機構等被列入美國“實體清單”。而在相關商品與技術的制裁體系中，基礎軟體是當之無愧的“利器”。大量優秀的企業、科研院校，都被美國禁止使用主流的基礎軟體與軟體開發工具，嚴重限制了中國產學各界的創新能力。應對這種局面，似乎只有自己掌握軟體開發工具，才是保障創新安全底線的最優解。

值得注意的是，“新軟體危機”並非只有開源工具斷供一個選項。很多國內企業都會選擇購買商業版、定製版的軟體。但這些軟體看似離開了開源工具，實質上很大程度是將開源工具進行封裝與定製化，再進行打包轉賣。這種情況下，主動權依舊受制於人。一旦出現開源工具失控，那麼這些投資巨大的商業軟體將面臨著無法更新、漏洞無法修補等嚴重問題。

另一方面，軟體開發工具的危機也不僅僅透過斷供來發生。隨著越來越多的軟體採用雲上開發模式，大量資料、開發程式碼需要存在工具背後的國外企業伺服器中。這也就意味著敏感資料理論上可以被其他國家檢視、分析甚至複製的，其風險意義不言而喻。

而一旦出現類似的軟體危機，中國會有哪些企業深受其害呢?首當其衝是數字化程度高、軟體使用規模龐大、軟體開發需求複雜的大型政企;接下來是掌握關鍵資料，同時肩負創新責任的科研機構與院校;緊接著是有著充分數字化、智慧化需求的實體企業;接下來則是科技產業，尤其是軟體開發企業與軟體開發者群落。

這樣的烈性事件一旦出現，就不是技術能夠解決的問題。它不以任何企業、機構的技術努力而轉移，而會直接導致命運出現分叉。當千百家企業受到影響，產生供應鏈的多米諾效應。社會面的影響是難以估量的。

所以說，軟體開發工具的受制於人，根本不是一個技術問題，而是命運掌握在他人手中的問題。

至此，我們也可以得出一個結論：中國確實還沒有準備好應對“新軟體危機”。但必須從此刻開始準備。要有意識、有方法地在國計民生行業、關鍵科研領域、重大科技產業中排除基礎風險，實現自主創新。

2019-2020年之後，中國各界關於軟體自主可控的共識提高到了空前的水平。大量政企使用者在採購軟體過程中，將國產化和資料安全納為關鍵考量因素。也由此衍生了巨大的機遇視窗。比如說，各大網際網路雲公司，都在以國產資料庫為切口進入政企市場。幾年來，在稅務、醫保、郵政、運營商等領域形成了規模化效應。而國產工業軟體，比如模擬、CAD等領域也高速發展，在製造業、能源產業中實現了突破。

但也要看到，基礎軟體國產化還有很長的路要走，比如“做軟體的軟體”——軟體開發工具。在今天得到的重視就還遠遠不夠。

好在逆全球化暗潮洶湧的幾年後，事情開始出現了轉機。

“永遠不要浪費一場危機”

從政策趨勢與產學共識的宏觀層面看，基礎軟體開發工具的國產化與獨立自主，已經是時代的大勢所趨。

在資訊科技應用創新委員會的定義中，應用軟體開發平臺同雲端計算、作業系統、資料庫一樣被定義為開發支撐基礎軟體，位居“十四五”軟體和資訊科技服務發展規劃中的五大主要任務之首。

另一方面，軟體開發工具的國產+商業版創新，也隨著主要科技公司的進步，進入到新的局面。從中興、華為事件以來，已經有數百家中國科技實體被美國列入實體清單，在各類軟硬體基礎技術的獲取上遭遇全面斷供。危機固然兇險，但也在客觀上加快了科技實體自主創新的程式，同時這批“先行者”們也可以將經驗和方法釋放出來，加快中國技術供應鏈的自主化程式。

以華為為例，華為被美國列入實體名單之後，涉及美國技術的商用軟體開發工具已經無法繼續購買使用許可，無法獲取存量軟體的持續更新，無法及時獲取安全漏洞的修復。為了破局這場典型的“新軟體危機”，華為從2019年開啟了去美國化的軟體自研，範圍涉及作業系統、資料庫、中介軟體、應用軟體等基礎軟體領域。

而面向軟體開發工具，這個容易被忽視，卻又至關重要的領域，華為雲推出了DevCloud開發雲和CodeArts軟體開發生產線，並面向開發者提供一站式、全流程、端到端安全的雲原生DevSecOps雲平臺。在確保使用者擁有高度整合、現代化流水線式開發的同時，解決了“新軟體危機”暴露的開源軟體弊端。

如今，華為雲CodeArts可以支援web開發、移動應用開發、微服務開發、Cloud Native應用開發、嵌入式開發等典型研發場景。覆蓋需求與設計、開發、測試、部署、運維等軟體交付的全生命週期環節。DevCloud、CodeArts已在華為雲、華為電信產品、終端雲消費業務、晶片研發等業界高標準、大規模的軟體研發業務中應用，證明了自身的價值與能力。

提到軟體開發工具的國產化與自主創新，我們經常會發現自研工具能力落後，或者侷限於單個不重要的工具，那些重要性大、考驗嚴苛的開發工具依舊需要使用國外開源工具。

但在華為雲CodeArts中，卻可以看到關鍵能力、關鍵工具的自主創新。比如華為雲CodeArts Req需求管理服務，專項解決了軟體開發管理這個戰略級需求。可以幫助使用者實現軟體開發戰略意圖，進行精準投資。目前，CodeArts Req已經高效支撐華為13萬研發人員的需求協作，月API呼叫量超過15億次，累計管理5000多萬需求，覆蓋華為終端、網路、雲端計算、晶片、汽車等全業務場景。在這條軟體開發的“生產線”上，一點一點的關鍵突破，終將匯聚成整體產業鏈的核心競爭力。

正如二戰時期英國首相丘吉爾的名言，“永遠不要浪費一場危機”。面對新軟體危機，我們應當充分珍惜危機帶來的啟示，並且保有這樣的共識：一家企業可能面對的風險，一定是整個中國可能面對的風險;而一批企業踩過的坑，絕沒有必要讓整個國家重蹈覆轍。

因此，當問題有了轉機和解法，就需要產業各界快速凝結共識，形成戰略合力以對抗風險。

命運只有掌握在自己手中，才叫命運。否則的話，一切都是囚籠。

從軟體開發工具，到智慧時代的軟硬體創新主導權，一切都到了需要改變，也應該改變的時候了。