企業實踐開源的動機

語言: CN / TW / HK

本文首發於個人部落格『夜天之書』

隨著開源軟體全面佔據軟體供應鏈的各個階段,商業公司開發基礎軟體或業務邏輯的時候,已經避不開對軟體的使用了。經過一段時間對開源軟體的使用,以及開源吞噬軟體的趨勢影響,研發能力突出的公司或團隊,也會加入到開發開源軟體的行列中來。

商業模型當中開源軟體位置的不同,體現出企業實踐開源動機的不同,並且會很大程度影響企業實踐開源的行為。本文將討論不同商業模型下,企業實踐開源的動機和行為的差異。

商業模型是銷售開源軟體

第一類商業模型是直接銷售開源軟體。這種型別的企業以 MongoDB Inc.Elastic 為代表,是在 2010 年以後逐漸興起的企業型別。

不過,說它們是“銷售開源軟體”也不準確。雖然在早期它們的商業產品是直接提供當時還是開源軟體的 MongoDBElasticSearch 本身,但是隨後由於原始碼免費可得,包括 AWS 在內的雲廠商直接利用免費的原始碼在平臺上提供同類的服務,這樣的新形勢使得這兩家公司前後把軟體協議改成 Server Side Public License (SSPLv1)Elastic License (ELv2) 來對抗商業競爭。

其中 ELv2 是明確的專有軟體協議,禁止其他人提供同類的服務,也不允許破解付費金鑰鎖定的高階功能。SSPLv1 是對 GPL 系列許可的發展,但是要求與 MongoDB 一同構成服務的所有軟體都需要按照 SSPLv1 協議釋出,即包括開放原始碼,這一點超出了 OSI 推出的開源定義第九條“協議不應該限制其他軟體”的原則。實際執行過程中值得注意的是,MongoDB Inc. 採用 SSPLv1 的動機是對抗商業競爭,它同時鼓勵使用者購買企業提供的以專有軟體協議釋出的 MongoDB 以避免 SSPLv1 的要求。這種行為的動機與自由軟體基金會製造的軟體純粹是為了讓所有人能夠自由地使用高質量的軟體的初衷非常不同。因此,我並不將這樣重新許可後的軟體認為是開源軟體,而是原始碼公開的專有軟體。關於不同開源協議的討論,我在《選擇開源許可證》一文裡有詳細地展開。

無獨有偶,曾經試圖通過銷售開源軟體的公司,最終都走上了重新許可成原始碼公開的專有軟體的路。

另一方面,越來越多的技術創業公司難以抵擋“開放原始碼”的潮流和使用者與開發者心理預期的轉變,又清晰地理解了自己的商業模式就是銷售將要開放原始碼的這個軟體本身,因此它們一開始就選擇了原始碼公開的專有軟體協議來禁止其他廠商直接利用公開的原始碼銷售同類服務開展競爭。

這種商業模式,本質上是 MongoDB Inc. 前任 CEO 所宣稱的“免費增值”策略,即在不產生商業競爭的情況下,或者說對於使用者,可以免費地使用該軟體。等到使用者深度參與之後,產生運維支援的需求,或者定製開發尤其是商業軟體整合的需求,再轉向唯一的供應商 MongoDB Inc. 付費獲得支援。

我認為這種模式是說得通的,是一個好的市場營銷手段。但是它與自由軟體運動和開源運動的理念都是相違背的。

自由軟體運動的理念是所有軟體都應該能夠被所有人自由地用於所有用途,顯然用於提供託管服務就是其中一種用途,而上述軟體協議不允許任何形式地提供同類託管服務。另一方面,自由軟體運動的起源之一是 Richard Stallman 在印表機軟體出現故障時無法取得原始碼修復並重新編譯和使用的痛苦。ElasticSearch 以付費金鑰鎖定的功能,是不是使用者也需要的功能呢?如果我開發了同樣的功能並且釋出了,這裡是否會產生破解的嫌疑呢?

開源定義(OSD)下的開源運動也包括了不限制用途和不限制其他軟體的要求。進一步的,以 Apache 軟體基金會為代表的開源世界,努力生產開源軟體的基礎是為了讓所有潛在的參與者和使用者平等地使用開源軟體和參與開發。上述原始碼公開的專有軟體,幾乎只有相應商業公司的成員才能開發核心程式碼,並且解決的需求也是其客戶提交的需求,隨後進行商業交付。如前所述,如果有一個開發者完成了商業公司提供的付費功能並且期望合併到上游釋出,上游會接受嗎?

不過,拋開以專有協議許可的核心部分不談,這些企業共同選擇了在生態連線所需要的介面和模組方面,採用寬容的開源協議例如 Apache 2.0 或者 MIT 來許可。尤其是 Airbyte 提出的核心以 ELv2 許可的軟體及其相應協議的模型,對於 CLI 和 Connector 等部分,都是開源軟體。

Airbyte 的軟體協議模型

如果把原始碼公開的專有協議部分視作商業軟體而非傳統意義上的開源軟體,那麼這種形式與接下來要討論的依託於開源軟體的商業模型就有很大的相似性了。只不過,當下的市場沒能很好地區分開開源軟體和原始碼可得的專有軟體。如果一個企業的商業模型就是銷售“開源”軟體本身的功能,例如前面提到的 MongoDB Inc. 和 Elastic 還有 CockroachLabs 這樣的,那麼他們的核心功能轉向專有軟體只不過是時間問題,或者說只要面臨商業競爭,就是經不起挑戰的。

對於這樣的企業來說,它的核心軟體只能依靠自己開發,是不可能大範圍地藉助開源協同的力量完善和覆蓋儘可能多的場景的。而且由於商業上的排他性,其他得到資本支援的研發團隊也很難直接參與到開發中來。這樣的軟體與過去的專有軟體,都會在開源吞噬軟體的浪潮下最終被取代。關於開源吞噬軟體在工程上的論證,《大教堂與集市》一書當中的 2.12 節《管理與馬奇諾防線》有詳細地論證。

這類商業模型的企業製造的軟體生態當中可能出現的協同,也侷限於使用者在沒有其他開源軟體選擇的時候,根據自己的需要和上游以開源軟體開發的元件的情況,相應的做一些補充。例如 Airbyte 支援其他資料來源的匯入,例如 GitHub 其實是個專有軟體,但是在 toolkitactions runner 以及 gh cli 等方面公開了相應的開源元件,這些元件也能得到開源社群的助力。

商業模型依託於開源軟體

第二類商業模型是依託於開源軟體構建商業產品。其實,在開源軟體佔據軟體供應鏈各個環節的背景下,任何商業模型的依賴路徑上存在計算機軟體的,基本都會部分依賴於開源軟體。當然,我們這裡主要討論的情形,是依賴深度較短的訂閱諮詢和解決方案的模型。這兩者不是互斥的,往往一個企業會同時發展這兩方面的商業產品和技術支援。

側重訂閱諮詢的商業公司裡,有名的包括紅帽、收購紅帽的 IBM 和收購了 Pivotal 的 VMware Tanzu 實驗室。

這三家公司都是 Kubernetes 的重要參與者,提供類似於 Kubernetes 發行版的雲平臺 PaaS 訂閱服務。紅帽還以提供 Linux 發行版和技術支援聞名,VMware 則有 Spring 這個 Java 生態的殺手級開發框架背書。在 IBM 的開源軟體技術支援列表裡,涵蓋了從應用開發棧、資料平臺、雲平臺到 DevSecOps 等領域的一系列知名開源軟體。

開源軟體的原始碼是公開且免費可得的,任何使用者都能夠自由編譯、演繹和使用在任何場景下。但是,經過幾十年軟體行業的發展,以及社會生活數字化的浪潮,現在廣泛被使用的開源軟體已經複雜到沒有經過專門的訓練和經驗積累,很難應對形形色色的業務需求。21 世紀最難得的真的是人才,上面提到的這些企業通過建立起開源社群當中屬於自己的品牌,以及提供良好的工作環境吸引到高水平的軟體開發人員,從而能夠提供這些廣泛存在於其他商業公司軟體供應鏈上的核心開源軟體的支援和訂閱服務。

例如,紅帽工程師耗費兩年的時間打造了 Vert.x 反應式應用開發框架,並捐贈到 Eclipse 軟體基金會共同創造出一個新的應用開發生態。厚積薄發,經過兩年的設計開發和紅帽客戶資源增益的打磨,一個全新的開源軟體和基於這個開源軟體提供技術支援和訂閱服務的商業模型正式成功上線。又例如,Pivotal 早在 2003 年就開始基於 PostgreSQL 開發 Greenplum 大規模並行處理系統,這個系統在經受 Impala 和 ClickHouse 等等後起之秀在十年之後的挑戰之前一直代表相關領域的先進生產力。IBM 和 VMware 則是以收購見長,將這些已經成功走出訂閱諮詢路線的商業公司併入自己的企業服務版圖,從而提供像上面 IBM 的開源技術支援那樣全方位的服務。

阿里雲、騰訊雲和 AWS 等雲廠商在其公有云平臺上提供的開源軟體託管服務,則是介於訂閱和解決方案之間的商業模型。它們既有利用自己公有云平臺和機器資源的優勢,提供分毫未改的與開源軟體相同的 API 的託管服務,例如 RDS 和 Redis 服務,也有發揮基礎軟體團隊研發能力進行二次開發,產品能力升級或場景化定製的商業軟體,例如 Ververica Platform 和 Tair 等等。

當然,售賣開源軟體託管服務不是大型雲廠商一家的專利。UpstashDatastax 都捕捉到了關係型資料庫以外,資料平臺對 NoSQL 資料庫在 KV 型別和訊息系統型別的需求,分別基於 Redis + Apache Kafka 和 Apache Cassandra + Apache Pulsar 搭建了自己的託管服務。由於依賴的軟體屬於 Apache 軟體基金會或其他第三方組織,即使這些企業接近於直接銷售開源軟體,但是也無法重新以專有協議許可,因此這些企業被迫會轉向上面提到的訂閱模型,或者這兩家企業選擇提供上述開源軟體全球可用和高效治理的服務,以此來產生自己的附加值。

這種附加值可以認為是一個企業級的解決方案,選擇了 Upstash 的 Redis 服務,就可以獲得在歐洲、北美、南美和東南亞都符合當地合規要求的開箱即用的 Redis 介面。另一方面,可以認為是企業基於自己對企業軟體生態的理解,提供的一套方法論。例如上一段提到這兩家公司是組合了 KV + Messaging 的介面提供服務,認為這兩者合作就能解決業務在邊緣場景下的資料儲存和上報消費的需求。

基於 Trino 分散式 SQL 查詢引擎的公司 Starbrust Data, Inc. 全力推廣 Data Mesh 的概念,基於 Apache ShardingSphere 的公司 SphereEx 則全力推廣 Database Plus 和 Database Mesh 的概念。這都是商業公司以開源軟體為核心,打造出的一套有商業差異化的企業軟體生態最佳實踐或者叫方法論。只要你信了這套方法論,以同樣的架構,同樣的開源軟體為核心搭建企業的軟體生態,那麼進一步產生付費,支援這一生態的順利和高效運轉,就是順理成章的了。

徹底以產品化的解決方案來封裝開源軟體提供商業價值的模式,典型的企業包括 DatabricksTetrate 以及 Firebolt 等等。

說起 Databricks 這家公司,很容易想到的是他們的早期核心團隊製造的 Apache Spark 開源軟體。不過,Spark 早在核心團隊還在大學實驗室的時候就捐贈給了 Apache 軟體基金會,因此同樣改變軟體協議來排他的銷售軟體是行不通的。Databricks 首先提供了具有明顯效能優勢的 Databricks Runtimes 產品,為對效能有極致追求的客戶提供一個商業選擇。然而,這樣的使用者畢竟是少的。於是 Databricks 開始了場景化的嘗試,包括面向機器學習場景的 MLlib 和一系列的商業產品,包括面向一站式資料處理的 Delta Live Table 等元件,以及類似於上面提到的 Data Mesh 這樣方法論的 LakeHouse 方法論與它的 DeltaLake 核心軟體。

今天開啟 Databricks 的官網,可以看到它早已在 Apache Spark 的基礎上,長出了豐富的面向不同領域場景,面向不同使用者案例和麵向不同客戶畫像提供的一系列豐富的解決方案。構成這些解決方案的基礎是 Apache Spark 豐富的生態,以及與開源的 DeltaLake 一脈相承的資料湖系統。在 Apache Spark 的名義下,在捐贈給 Linux Foundation 的 DeltaLake 的名義下,在 Databricks 官方 GitHub 組織的名義下,有著上百個連線資料平臺開源共同體的開源軟體。Databricks 在此之上又開發了面向不同場景不同解決方案需求的專有軟體和商用程式碼,從而支撐起了自己的商業模型。

同樣的,Tetrate 旨在提供雲原生應用的網路治理方案。Tetrate 重度參與了 Istio 和 Envoy 以及 Apache SkyWalking 等開源專案的開發,僱員當中不乏相應社群的維護者乃至創始人。然而這家公司從未以相關開源社群所謂“背後的商業公司”自居,而是清晰地認識到自己的商業模式是依託於這些開源軟體,提供自己定位在雲原生應用的網路治理方案上所需的專有軟體和企業級解決方案。Tetrate 有自己的 Istio 發行版,以在上游激進的釋出模型之外為商業使用者提供穩定、經過測試、高度相容且 Tetrate 提供技術支援的 Istio 版本。此外,Tetrate 提供了 Tetrate Service Bridge 一攬子解決方案,在 Service Mesh 的方法論體系下支援客戶將應用部署起來並完整監控和高效治理。

上面兩個例子當中,Databricks 的工程師還有相當部分投入到 Apache Spark 和 DeltaLake 以及其他公司釋出的開源軟體的開發迭代,Tetrate 更是鼓勵乃至促使重度參與提到的三個開源社群當中。Firebolt 的例子會有所不同,它很大程度上是作為 ClickHouse 的下游存在,極少參與上游開發。

Firebolt 僅將 ClickHouse 作為自己的計算執行引擎,在這一選型之外,完全專有化的實現了前臺管控、叢集管理和元資料管理、查詢優化、資料索引和麵向雲端儲存的訪問層。這樣的商業模型也是依託於開源軟體的,但是其依賴深度已經處於臨界值。例如某些完全閉源的 Java 開發的專有軟體,其中的網路模組也有可能使用開源軟體 Netty 來實現,但是這種情形下,恐怕就不是我們這裡所想討論的企業實踐開源的商業模式了。

Query Engine 起初完全就是 ClickHouse

Firebolt 這樣的選型也算是自然的。如果你回顧 Databricks 的發展歷程,它實際上可以被認為是選擇了 Apache Spark 作為自己的計算執行引擎,逐漸發展出場景化的解決方案和 LakeHouse 一站式資料處理平臺。不過,Databricks 的方向是逐漸走向開源。利用自己的先發優勢,賺到行業內唯一提供商的收益以後,逐漸將自己的能力開源出來,以形成強凝聚力和活力的生態。這在下一節“開源標準以保護現有軟體”會展開討論。

反過來看 Firebolt 的做法,ClickHouse 在 fork 以後已經經歷過閉源魔改,我相信時至今日它還是不是 ClickHouse 已經不好說了。Firebolt 也沒有任何參與開源社群的徵兆。因此我認為它會成為一個傳統的商業軟體公司,並在資料處理領域的開源浪潮下被吞噬。或許另一個世界當中的 Firebolt 走的是積極與上游協同的路線,共同發展 ClickHouse 的計算模組,並且在逐漸擴大自己商業版圖的過程中把訪問雲端儲存的技術開源,查詢優化和叢集管理也開源,成為另一個行業標準的制定者。

回顧上一節當中我提到如果把原始碼公開的專有軟體這一部分就明確認知成專有軟體,上一節當中提到的商業公司也有形如 Databricks 和 Firebolt 這樣不同的傾向性。雖然我相信開源運動持續下去,開源理念深入人心,因為高校研究突破也好,因為面向消費者的企業開源基礎架構元件也好,因為下一節中要討論的保護現有軟體因此開源搶佔標準也好,目前存在的所有專有軟體,都會被開源軟體所替代。

但是到那個時候,又會有新的商業需求產生,這些需求被開源運動的創造力滿足的時間差,是存在提供解決方案的視窗的。世界之大,無奇不有,各種定製化的需求可以是非常特殊或小眾的,而開源軟體往往只解決主要問題和部分場景。另一方面,數字化程序大跨步前進,哪怕開源軟體理論上能夠解決好一個問題,但是實際實施的時候,仍然需要專家技術支援,並且維護後續迭代當中可能出現的問題。訂閱諮詢和解決方案這樣依託於開源軟體的商業模式,是能夠長期存在的。

開源標準以保護現存業務

這種動機只有當企業成長到一定規模的時候才會產生,到這個時候,企業的商業模型往往已經非常複雜,甚至並不只是依靠軟體服務來盈利。這種情形可以認為是上一節“商業模型依託於開源軟體”的變體,即企業軟體生態當中錯綜複雜地依賴了一系列開源軟體,繼而主要出於保護現存業務,順帶擴大技術影響力,來以開源軟體協議公開企業內部的關鍵軟體,以奪取開源世界對應業務領域的標準。

出於這一動機實踐開源的典型企業就是谷歌。無論是 Kubernetes 還是 Istio 的開源,谷歌從中獲得的直接商業利潤都是不足以促成它做這樣的動作的。然而,谷歌通過對自己內部業務應用的分析,看出容器技術和雲原生應用是未來業務發展的方向。為了保護公司內部所有基於 Kubernetes 同類雲平臺的業務能夠持續得到新生代工程師的認同和維護,谷歌需要佔領雲原生標準的話語權。

這裡有段逸聞想必同行也耳熟能詳,說當初谷歌找上 Docker 希望合作開發容器排程平臺,但是 Docker 認為自己單獨開發 Docker Swarm 也能贏下容器戰爭。結局大家也都知道了,Kubernetes 贏下了容器戰爭,Docker Swarm / Apache Mesos / Open Stack / Cloud Foundry 等等當初的對手則黯然退場乃至徹底死亡。

相關技術被潮流所拋棄對採用這些技術的企業和團隊帶來的打擊是非常嚴重的。不僅僅是押寶相應技術的團隊被市場所否定,就業前景黯淡,對於公司來說,這意味著可能幾十萬行、上百萬行乃至更多的業務程式碼都成了技術債務。站在今天的角度能夠看到的例子,就是歐美國家銀行當中海量的 COBOL 語言寫成的業務系統,如今能找到的有維護能力的工程師最年輕的也有六十歲以上。如果這個世界上能夠維護這些系統的工程師已經絕跡,那麼企業的業務就暴露在巨大的風險之下。顯然,當初選擇了 Docker Swarm 和 Apache Mesos 的企業也將面臨越來越招不到人維護的處境。在這種情況下,唯一能做的就是及時將遺留系統遷移到上游標準,但是這樣的工作往往需要更加精通被淘汰的技術的工程師才能牽頭完成,並且相應的時間精力成本不可估量。如果遷移這麼簡單,那些 COBOL 程式碼又是怎麼歷經幾十年都無人能夠“遷移”的呢?

不僅僅是容器戰爭這樣出圈的開源標準之爭,Yahoo! 開源 Apache ZooKeeper 和 Apache Pulsar 等軟體,阿里開源 Apache RocketMQ 和全面投入 Apache Flink 的開發,Netflix 開源 Apache Curator 和 Apache Iceberg 以及 Uber 開源 Apache Hudi 等等,都有保護自己線上業務的動機在裡面。當然,如果能夠藉此機會樹立公司的技術品牌,吸納高水平的技術人才,乃至主導行業未來的發展方向,那就是意外之喜了。

不完全是軟體行業為了保護現存業務,在開源技術以爭奪行業標準的方向上,還有三個值得一提的案例。

第一個是啟發我從這個方向看待企業實踐開源的動機的例子。Bjarne Stroustrup 在 2020 年總結 C++ 發展歷程的論文 Thriving in a Crowded and Changing World: C++ 2006–2020 當中提到了 C++ 標準委員會當中有許多耳熟能詳的大公司的參與,包括蘋果、谷歌、英特爾、微軟、摩根士丹利、英偉達、高通、紅帽和 IBM 等等。每個提案提出的時候,往往代表了某個公司或科研機構經年的努力、實踐和生產檢驗。論文當中回顧了若干提案導致不同硬體廠商的標準之爭、大學科研機構的方向之爭和軟體公司保護現存業務不受完全不同的標準的影響的爭論。

例如,各家都有自己的協程實現和用例,如果標準庫的實現與自家實現的關鍵設計和介面不同,那麼就意味著以上游的分叉,這將導致上面提到的實現被開源社群所拋棄或者巨大的遷移成本的問題。對於硬體廠商來說,類似於 C/C++ 這樣的系統程式語言是硬體介面接入軟體層面第一個要打交道的層次。如果在併發語義、時鐘介面或者硬體訪問標準上採取了一家硬體廠商的方案,那麼其他硬體廠商的眾多生產流水線就面臨立即被市場淘汰的風險,以及成為相應細分領域追隨者而不是領導者或公平競爭者的劣勢。

第二個是谷歌開源 Android 作業系統的例子。開發和開源 Android 作業系統之前,谷歌內部並沒有大量的現存業務。但是眾所周知,為了避免移動網際網路時代的基礎設施移動裝置的作業系統被 iOS 全面統治,從而在谷歌和蘋果的全面軟體技術競爭上處於劣勢,後發的谷歌選擇開源的方式來開發自己的移動裝置作業系統。谷歌在瀏覽器市場上也採用了類似的模式,谷歌瀏覽器的核心是開源的 Chromium 專案,這一選擇或許受到了世紀初 Firefox 在與 IE 的競爭下贏得巨大成功的啟示。不可否認的是,開源的 Android 作業系統形成的龐大生態,開源的 Chromium 核心衍生的一系列瀏覽器軟體,成為了谷歌在這兩個方向上核心技術極深的護城河,同時也極大地擴張了這兩個領域的市場規模。

第三個例子是跨領域的特斯拉的例子。特斯拉進軍新能源汽車領域時,這個領域的市場規模還很有限。即使特斯拉是行業當中無可爭議的老大,新能源汽車在行業成熟度,全球化分工的可行性和社會認可度都是極其有限的。通過開源核心基礎技術,不追究使用基礎專利侵權,使得全球所有看到機會的人才投入到這個行業當中來。行業成熟度決定特斯拉能夠持續地招聘到什麼水平的人才。如果市場上只有特斯拉一家公司,那麼選擇這個方向的人心裡就要打鼓,現在即使投身這個行業進不去特斯拉,或者特斯拉出現問題要調整或者裁員,也能找到其他崗位繼續自己的職業生涯。如此,加上行業熱情高漲,社會認可度高,人才投入到這一領域的概率和比例就大大增加了。另一個方面,社會認可度還可以增加大眾購買新能源汽車的動力和信心,全球化分工則使得特斯拉的生產製造流水線能夠放置到人力成本最經濟的國家或地區完成。

企業實踐開源的其他收益

前面三段分類討論了不同商業模型下的企業實踐開源的動機和形式的不同,這一段從企業實踐開源的收益的角度出發,討論上面沒有專門點出的動機。

內容生產的原材料

定位自己為技術公司的企業,需要解決的一個問題就是如何建立和持續強化技術品牌。技術品牌打造的一個關鍵支柱是技術內容運營,內容運營最大的挑戰是沒有內容。巧婦難為無米之炊,如果企業的技術人才、研發部門的日常工作當中沒有生產出有利於打造品牌的技術內容原材料,期待運營部門自己憑空創造出內容是非常困難的。

企業以開源文化或者開源辦公室為支點,系統地採集員工在上游開源社群或者企業開源的軟體社群當中的活動,就能為內容生產提供優質的原材料。例如許多開源社群都會有自己的 Weekly 新聞,記錄最近一週開發團隊和周邊生態發生的要聞,包括實現了什麼新功能,修復了什麼問題,有哪些新成員加入,軟體生態有什麼新元件或者老元件的重大變更,社交媒體上有什麼與本社群相關的熱點。企業鼓勵員工積極參與上游開源社群,積極地以開源協同的方式執行企業開源的軟體社群,在這個從業者都有旺盛的求知慾和參與熱情的行業當中,不難積累出值得宣傳的內容。

這些內容都是 WORKING IN PUBLIC 的行為,因此也就不存在是企業“內部”的動作,從而出現茫茫多內容稽核的問題。此外,內容運營最能激發參與熱情和建立技術品牌的點,在於其他人也能方便地加入進來,驗證你釋出的內容當中提到的事情是真的,參與到釋出的招募事項裡面來,親力親為與其他社群成員形成聯絡。

實踐軟體工程理論

要想從 Apache 軟體基金會的孵化器中畢業,成為 Apache 頂級專案,需要在 Apache 成熟度模型的指導下實踐一系列軟體工程的理論。

對於其他開源社群的建設來說,要想發揮開源協同的最大價值,同樣需要在這個遠遠超出一個公司員工總數量級的開放式環境當中高效地協同不同的參與者。從程式碼到文件,從開發到測試再到釋出,從協議合規到軟體安全,從技術社群到開源生態,每一個方面都是對一個新生的開源社群的考驗。

尤其是國內短於軟體工程理論的交流和實踐的環境下,企業鼓勵員工參與開源社群,將自己所依賴的不構成明顯商業競爭優勢的專有軟體開源並嘗試建設一個開源社群,是一個很好的與全球同行切磋“高質量軟體應該怎麼製造”的路線。企業需要懂得軟體工程的員工來做好自己需要的業務軟體和基礎軟體,而缺乏現成可參考的案例和可以試手的物件,不僅對於學生是個問題,對於不像谷歌那樣有一套完整的軟體工程體系和大量可供參考和參與的軟體的公司的員工來說,也是個巨大的問題。

許多程式設計師不知道文件應該怎麼寫,許多程式設計師沒見過複雜的併發問題,許多程式設計師不瞭解軟體構建的過程,對軟體整體的交付流水線知之甚少,更有許多程式設計師不知道如何與其他成員溝通協作、合作開發。對這些全域性視角和具體細節把握的不足,軟實力的缺失,就是程式設計師能力的短板,雖然不是每個人都要是全面的人才,但是這應該是每一個從業者追求的目標。這些問題,只要你深入參與到開源社群當中去,或者自己執行一個開源社群,其實就有機會積累到寶貴的經驗。

至於前文已經提過的建立技術品牌以後,帶來的招聘上和客戶取信上的收益,贏得開源標準帶來的一系列價值,這裡就不再贅述。

總結

根據企業商業模式與開源軟體之間的關係,其實踐開源的動機與具體實施的行為會有不小的差別。

我認為,直接銷售開源軟體終將被證明是不可行的。基於開源軟體,提供訂閱服務或技術支援,構建企業級的解決方案,是能夠長久存續的商業模式,也因此提供了企業長期實踐開源的源動力。當企業逐漸發展以形成複雜的商業模式以後,開源就不僅僅是技術影響力或者協同開發這麼純粹了。主動參與自己所依賴的開源軟體的上游社群,或者以各種方式支援上游社群的發展,爭奪開源標準,保證自己的現存業務在激烈的市場和技術競爭下能夠長期存在,直到領域的終局,也是這一階段的企業需要考量的動機。