歷史上，從來沒有出現過用於Linux內核的正式的源代碼管理或修正控制系統。實際上，很多開發者實現了他們自己的修正控制器，但是並沒有官方的LinuxCVS檔案庫，讓LinusTorvalds檢查加入代碼，並讓其他人可以由此獲得代碼。修正控制器的缺乏，常常會使發行版本之間存在“代溝”，沒有人真正知道加入了哪些改變，這些改變是否能很好地融合，或者在即將發行的版本中哪些新內容是值得期待的。通常，如果更多的開發者可以像了解他們自己所做的改變壹樣了解到那些變化，某些問題就可以得到避免。
非常有必要使用壹個實時的、集中的檔案庫來保存對Linux內核的最新更新。每壹個被內核接受的改變或者補丁都被作為壹個改變集被追蹤。終端用戶和開發者可以保存他們自己的源文件檔案庫，並根據需要可以通過壹個簡單的命令用最新的改變集進行更新。對開發者來說，這意味著可以始終使用最新的代碼拷貝。測試人員可以使用這些邏輯的改變集合來確定哪些變化導致了問題的產生，縮短調試所需要的時間。甚至那些希望使用最新內核的用戶也可以直接利用實時的、集中的檔案庫，因為壹旦他們所需要的部件或缺陷修復加入到內核中，他們就可以馬上進行更新。當代碼融合到內核時，任何用戶都可以提供關於這些代碼的即時反饋和缺陷報告。 隨著Linux內核的成長，變得更加復雜，而且吸引更多開發者將註意力集中到內核的特定方面的專門開發上來，出現了另壹個開發Linux方法的有趣改變。在2.3內核版本的開發期間，除了由LinusTorvalds發行的主要的壹個內核樹之外，還有壹些其他的內核樹。
在2.5的開發期間，內核樹出現了爆炸式的增長。由於使用源代碼管理工具可以保持開發的同步並行進行，這樣就可能實現開發的部分並行化。為了讓其他人在他們所做的改變被接受之前可以進行測試，有壹些開發需要並行化。那些保持自己的樹的內核維護者致力於特定的組件和目標，比如內存管理、NUMA部件、改進擴展性和用於特定體系結構的代碼，還有壹些樹收集並追蹤對許多小缺陷的糾正。
這種並行開發模型的優點是，它使得需要進行重大改變的開發者，或者針對壹個特定的目標進行大量類似改變的那些開發者可以自由地在壹個受控環境中開發，而並不影響其他人所用內核的穩定性。當開發者完成工作後，他們可以發布針對Linux內核當前版本的補丁，以實現到此為止他們所完成的改變。這樣，社區中的測試人員就可以方便地測試這些改變並提供反饋。當每壹部分都被證明是穩定的之後，那些部分可以單獨地，或者甚至同時全部地，融合到主要Linux內核中。
（內核結構圖相冊部分圖片來源：） 在為將來的2.6Linux內核進行開的過程中，除了這些自動化的信息管理方法之外，開放源代碼社區的不同成員還收集和追蹤了數量驚人的信息。
例如，在KernelNewbies站點上創建了壹個狀態列表，來保持對已經提出的內核新部件的追蹤。這個列表包含了以狀態排序的條目，如果它們已經完成了，則說明它們已經包含在哪個內核中，如果還沒有完成，則指出還需要多長時間。列表上很多條目的鏈接指向大型項目的Web站點，或者當條目較小時，鏈接指向壹個解釋相應部件的電子郵件信息的拷貝。