原文網址：https://opensource.com/article/16/12/yearbook-9-lessons-25-years-linux-kernel-development
註：作者 Greg Kroah-Hartman，曾經來台在 COSCUP 2013 演講，是許多 linux tree 的 maintainer (usb driver core, debugfs, sysfs…etc)，同時也是 staging 的 maintainer (staging 裏面有個地方是給新手練習 submit patch 的，greg kh 也會在 newbie mailing list 上解惑)。
他也是 Linux Device Drivers 跟 Linux Kernel in a Nutshell 的作者，台灣有翻譯前者，不過兩本書都很老了 (2.6的年代吧)，他自己也有說LDD 4rd 近期大概不會出版QQ。
可以說 Greg KH 在 Linux 界中是僅次於 Linus 的存在。
因為 Linux kernel community 在 2016 年慶祝邁入第 25 年的發展，許多人問到是什麼樣的秘密使得整個專案能如此長壽且成功。我通常都笑著戲謔的說，我們其實不知道為什麼我們能發展到現在。這個專案在一路上遇到了許多分歧以及挑戰。但說實在的，我們能夠走到今天這一步，是因為這個社群有能力能夠反省以及改變。
在 16 年前，大多數的 kernel developers 根本沒有見過彼此 ─ 我們只有透過 email 來溝通 ─ 因此 Ted T’so 提出 Kernel Summit 這樣的想法。現在，每年 kernel developers 都會聚在一起解決技術問題，還有，最重要的是，一同檢視過去的一年中什麼事情做對了，什麼事情做錯了。Developers 可以公開和誠實的討論他們如何與其他人交流，以及開發流程如何運作。接著我們做出改變來改善流程。我們也做出新的工具，像是 Git，並且不斷改變我們交互工作的方式。
隨著時間推移，這個演進創造了彈性，使得整個專案得以變得更為壯大，同時避免那些會瓜分資源的競爭項目的分支(avoiding the forks that have split the resources of competing projects.)。我們可能還要好幾年才能完全了解 Linux kernel 成功的關鍵為何，但有幾個教訓是我們現在已經知道的。
1. 短時程的開發週期至關重要
在早期的 Linux 專案中，通常會數年才發表一個新的 major 核心。這意味著一個使用者要用到新功能，中間會有一段很大的延遲，這對使用者與 distributors 來說是很沮喪的事情。更重要的是，這麼長的一個開發周期，代表每個周期要有大量的程式碼要被整合進去，導致即便一段程式碼尚未完成，還是會有要整合進 release 中的壓力。
短時程的開發週期解決了這些問題。現在新的程式碼能夠更快的進入 stable release。在接近常規發佈的狀況下整合新程式碼 (註: 4.9 的每個 rc 幾乎都是 2 weeks 發佈一次) 可以在最小的破壞下做出重要的改變。而 develoeprs 知道就算他們錯失一個 release cycle，在一到兩個月後還會有另一個 cycle，因此降低了過早 merge 程式碼的動機。
2. 流程的可擴展性需要一個分散的、分層的開發模型
很久很久以前，所有的變更都會直經經過 Linux Torvalds，但這很快就被證明是個愚蠢的事情，因為沒有一個人可以跟上像作業系統核心這樣如此多樣化的專案。
3. 工具很重要
幾乎在一夜之間， BitKeeper 原始碼管理系統的出現改變了整個社群的做法，核心開發的 scale 困境至此得以改善; 而遷移到 Git 上則又帶來另一個巨大的躍進。如果沒有正確的工具，像 Linux kernel 這樣的專案很容易因為自身龐雜而被擊垮。
4. 核心的 (kernel’s) 強共識導向模型很重要
作為一個通用規則，如果一個改變的提出被一個被敬重的 developer 給反對，那程式碼就不會被 merged。當 developers 發現他們的程式碼在 mailing list 上被阻擋了許多個月，對於那些閉門苦幹的 developers 而言可能會感到極度的沮喪。不過這也確保了核心可以適當的使用於廣泛的用途。沒有特定的使用群可以改變其他群的付出。結果是，我們有一個可規模化 (從小系統到超級電腦) 且合於廣泛用途的單一程式碼庫。
(本段翻譯不好，故附上原文供參照。舉例而言，可以看到 pluggable scheduler 那時候的狀況)
As a general rule, a proposed change will not be merged if a respected developer is opposed to it. This can be intensely frustrating to developers who find code they have put months into blocked on the mailing list. But it also ensures that the kernel remains suited to a wide ranges of users and problems. No particular user community is able to make changes at the expense of other groups. As a result, we have a single codebase that scales from tiny systems to supercomputers and that is suitable for a huge range of uses.
5. 核心的強 “無回歸” 規則同樣也很重要
早在十年之前，kernel developer community 就做了一個承諾，如果一個給定的核心可以運行在一個特定的設定下，那其後出現的 kernel 也應該要能運行。如果社群發現一個改變引發 regression，他們會迅速的搞定這個問題。這個規則給予使用者一個保證，保證核心升級後不會毀了他們的系統；得到的結果是，developers 願意在開發新功能時遵循 kernel (舊有的部份)。
6. 企業參與在過程中非常重要，但沒有一個單一企業能夠支配核心開發
在 2014 年 12 月的 Linux kernel 3.18 release 中，共有接近 500 家企業的 5062 位開發者對核心開發做出了貢獻。大多數的開發者都是有薪工作 – 而他們做出的改變 (changes) 則幫助了他們工作的公司。但是，雖然任何公司都能為自己的特殊需求來加強核心，但這不代表有公司可以將開發的方向導向傷害他人的方向，或是限制核心可以做什麼。
7. 專案中不該存有內在邊界 (internal boundaries)
Kernel developers 需要專注在其開發的單一部份當中，但任何 developer 可以對任何 kernel parts 做出變更，只要這個變更是合理的。其結果是，一個問題的解決不會治標不治本，developers 能夠有對於 kernel 更全面的理解，而就算是最頑固的 maintainer 也無法無限期的在其子系統中暫停一個需要的進展。
8. 核心顯示出一個大型開發可以源自於一個小的開始
原始的 0.01 kernel 僅有約 10, 000 行程式碼；到了今天他成長到每兩天可以產出多於 10, 000 行。一些現在 developer 在開發的基本的，小型的 feature 也有機會在未來成為一個重要的子系統。
9. 最重要的是，25年的核心歷史表明了，持續的、合作的成果能夠帶來沒有一個組織能自己開發完成的公共資源
自從 2005 年，多達 1,300 家不同企業的 14,000 名開發者參與了核心的開發作業。Linux kernel 因此成為了在其他領域中競爭激烈的公司一起共同大規模開發的公共資源。
以上提到有關 Linux kernel development 更進一步的資訊，可以在 2016 Linux Kernel Development Report 中找到，co-written with LWN‘s Jon Corbet. Libby Clark contributed to this article.
Leave a Reply