Linux內核社區于2016年迎來了其二十五歲生日,很多朋友詢問我們實現項目長久發展及成功的秘訣。對于這樣的問題,我通常會以笑話回應——因為說實話,我也不知道這一切是怎樣實現的。不過重要的是,我們之所以能夠這樣摸索向前,是因為社區自身擁有著強大的反省與變革能力。
大約十六年前,大多數內核開發者彼此從未謀面——大家只是通過郵件溝通。為了解決這個問題,隨后出現了內核峰會。如今,Linux內核開發者們每年都會齊聚一堂,共同探討技術問題并反思自己過去一年中哪些事做得對、而哪些事做得不夠理想。我們會開發Git這類新型工具,從而不斷改變彼此間協作的方式。
隨著時間推移,這種演變帶來了彈性,使得Linux項目能夠不斷邁上新的臺階,同時避免由fork帶來的力量分散問題。也許其中確實有著一些重要的成功關鍵,下面我將試著闡述其中的9項啟示。
1.保持較短發布周期非常重要。
在Linux項目發展早期,每套新的內核大版本往往需要數年才能發布一次。這意味著用戶需要拿出大量時間等待新功能的加入,這對于使用者以及發行商而言都相當令人沮喪。不過更重要的是,如此漫長的周期意味著我們需要一次性整合大量代碼,甚至不得不將很多尚未就緒的代碼匆匆加入新版本。
較短的發布周期能夠解決此類問題。新代碼可快速被納入穩定版本。以幾乎即時的方式集成新代碼使得最為重大的變更也幾乎不會產生破壞性影響。開發者很清楚,即使他們錯過了一個版本,那么再等兩個月又會有新的版本,因此他們不必急于將不成熟的代碼合并進來。
2.需要利用分布式分層開發模型實現流程可擴展性。
很久以前,一切變更都直接由林納斯-托瓦茲負責,但這種作法很快被證明并不科學——畢竟沒有任何一個人能夠獨力支撐起像操作系統內核這種多樣的項目。因此,我們想到應該將內核中不同領域的事務交由不同且掌握對應專業知識的維護者處理。其中包括網絡、無線網絡、各類驅動程序子系統——例如CPI或USB——乃至ext2或vfat等獨立文件系統。將代碼審查與集成的任務交付至數百名維護者手中,最終使得Linux項目能夠快速實現各個版本中的數萬次變更,而不會影響審查或者成品質量。
沒有正確的工具,內核這樣的項目將隨著自身體積的擴張而崩潰。
3. 工具很重要。
內核開發工作在規模方面一直面臨挑戰,直到BitKeeper源代碼管理系統的出現——其幾乎在一夜之間改變了社區的實踐方式。而Git無疑是另一種飛躍。沒有正確的工具,內核這樣的項目將隨著自身體積的擴張而崩潰。
4.內核的共識性判斷模式非常重要。
作為一項基本原則,如果某位極具份量的開發者表示反對,那么提出的更改建議將不會被納入項目當中。但是,這對于該代碼的貢獻者來說則是一種沉重的打擊,畢竟他們已經耗費了數月時間用于相關工作。但這一舉措亦確保了我們的內核能夠適應廣泛的用戶需求與實際問題。沒有哪個用戶社區能夠犧牲整體利益執行變更。因此,我們利用這種共識性關注保證項目只具備單一代碼庫,其能夠涵蓋由小型系統到超級計算機的各類應用場景。
5.內核的“無退化”原則同樣重要。
十年之前,內核開發者社區曾經承諾如果特定內核可在特定設置下運作,那么全部后續內核也必須契合同樣的條件。如果社區發現某項變更會導致退化,則必須快速解決這一問題。該原則向用戶保證任何升級活動都不致破壞其系統,這樣他們才樂于在開發新功能時采用我們的內核方案。
6.企業參與至關重要,但內核開發不會由任何單一企業所操縱。
自2014年12月發布的3.18版本以來,來自近500家企業的5062名個人開發者為Linux內核作出了貢獻。大多數開發者能夠從相關工作中獲得酬勞,而他們做出的變更則可為其所在企業提供助益。然而,盡管任何企業都能夠參與到內核的改進工作中來,但內核的發展方向絕不會為任何單一企業所操縱。
7.項目之內不應存在內部邊界。
內核開發者必須專注于內核中的特定部分,但任何開發者都能夠對內核的任意部分進行變更——只要這一變更存在合理性。這意味著問題將始終存在于其起源處,而非令人難以定位,而開發者則可對內核擁有更為全面的了解,甚至最為頑固的維護者也無法無限期地阻止任何針對特定子系統的改進。
8. Linux內核項目證明,大規模開發工作完全可以從小處起步。
最初的0.01版本內核僅包含1萬行代碼; 如今其每兩天的代碼增量就已經超過1萬行。開發者目前添加的一些基本甚至微小的功能,未來都有可能發展成重要的子系統。
9. 25年的內核發展歷程表明,持續合作可以帶來任何單一機構都無法實現的輝煌成果。
自2005年以來,來自超過1300家企業的約14000名個人開發者為Linux內核作出貢獻。正因為如此,Linux內核已經成為各類企業進行市場競爭時頻繁使用的重要資源。
原文標題:9 lessons from 25 years of Linux kernel development
原文作者:Greg Kroah-Hartman