http://antkillerfarm.github.io/

前言

自從發現git和github之后，由于git方便的查看版本歷史的功能，使我能夠對一些著名開源項目的發展史有一定的了解。并以此為契機，一定程度的揭開開源項目的運作之謎。

PS：不要提svn的版本歷史，那個在局域網里查看還算方便，對于互聯網的查看來說，即使只看最近1000條，也要耗費非常非常多的時間，而且還是每次查看都是這樣費勁。

從git log看linux的發展史

linux穩定版本的git地址:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

這個版本的提交那叫一個多啊，截止2014年12月25日，已經有482338次提交。這個次數多到什么程度呢？直接讓gitk的內存占用超過2.5G，即使這樣也才加載到40W次左右，還剩下8W次沒有加載呢。。。

所以在萬般無奈的情況下，只好使用原始的git log命令，這才統計出剛才的數字。相關命令如下:

git log --pretty=format:'%h by %an at %cd'

可能是git時間一長，就太大了的緣故吧，所以還有一個更古老的git地址：

git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git

這里面是2002年至2005年期間的代碼，估計以當時的網絡條件，傳這么個165M的龐然大物，也是件浩大的工程了。

（PS：了解BitKeeper和Git的恩恩怨怨的同學，估計看到“2002年至2005年”，應該就能猜出這個git是怎么回事了吧。我好奇的是，在BitKeeper之前，Linus用什么來管理代碼。2015.3.20）

這里有一個發現，Linus早先在Transmeta公司干活，這也是他打工時間最長的公司，有興趣的同學可以自行wiki一下相關的信息。

最后再吐槽一下git，這么大的庫，居然不支持斷點續傳，也不支持object的原子下載。。。相比之下，svn雖然也不能斷點續傳，但是這次下載一個文件，下次就不用再下載了。考慮到代碼文件也不可能太大，這樣也就基本夠用了。

從git log看git的發展史

Linux源代碼由于歷史久遠，最初的版本歷史已不可考證，至少無法從git log考證。但git本身的歷史，則是一筆筆的都記錄在git log中。

網上的說法，git是Linus一個周末的產物。但從log來看，項目開始的時間——2005.4.8，那是個周五。所以這個說法不成立。不過看了下代碼的長度，也就是2000多行吧，理論上的確是一個周末的工作量。

從初始版本還可以看出，最早的git并不是單個可執行文件，而是一個子命令對應一個可執行文件。而且命令的名字也不是clone、pull之類的東西。

git-pull是在2005.4.19添加的，是個bash腳本。實際上，git所采用的設計思路和通常的教科書里的自頂而下的方法相反。它是自底而上，首先設計基本數據結構和算法，然后再在使用中，根據實際的需求，編寫各種腳本，以使之便于使用。這種設計思路在當時看不出有多大的好處。但時至今日，隨著各種項目的進展，版本庫的規模日益增長，某些項目的提交總數甚至達數十萬之巨，而git仍能高效處理。這不得不使人佩服Linus的設計功力。

2005.4.24 添加了網絡傳輸的功能，這樣git才算是個完整的分布式版本控制系統。

2005.6.8 添加cvs到git的工具。

2005.7.11 第一個里程碑版本0.99發布。

2005.12.21 v1.0發布。

從上面的歷程可以看出，即使參與項目的人都是牛人，git也差不多經過了8個多月，近3000次commit，才達到了基本可用的水平。絕不是什么天才人物一周時間的作品。

從git log看svn的發展史

這個標題并沒有錯。眾所周知的，svn查看修改歷史是需要遠程登錄服務器的。而這對于一些歷史悠久的版本庫來說，簡直是是個災難。因此這里的log實際上是從Apache官方的git服務器上git下來的。

svn的開端實際上和git是有區別的。這個項目從2000.3.1開始。但是最先動手的，并非代碼，而是文檔。三個作者足足討論了3個月，才在2000.6.10提交了第一行代碼。而git一開始就是代碼。

這實際上是有原因的。svn的目的是替代cvs，因此它的主要任務是修補cvs設計中不好的地方。因此它在設計階段花費的時間較長。

而git在設計之初，有BitKeeper和Monotone作為參考，且從功能角度而言，BitKeeper并無重大問題，因此設計的任務并不是很大。

反倒是開源社區急需一個產品用以擺脫BitKeeper，因此git一上來就是代碼，也就不難理解了。

順便說一句，Mercurial只比git晚了10天誕生。可見那時候開源社區對于分布式版本控制系統的需求之迫切了。

從git log看sqlite的發展史

第一版發布于2000.5.29，已經有相當多的代碼。

項目的committer只有9人，其中九成以上的代碼出自一個人。

這個項目最初使用CVS管理代碼，2009.8.12開始該用fossil管理代碼。順便提一句fossil使用sqlite作為對象存儲的工具。

從git log看emacs的發展史

很遺憾，早期的歷史在log中，已經殘缺不全了，

按照wiki的說法：

• GNU Emacs最早廣泛發布的版本是15.34，出現于1985年。

而現有代碼庫的第一個可用的版本是從大約1990年開始的，之前的歷史版本雖然有，但是根本不可編譯使用。

當時這個項目使用RCS管理代碼，這也是發展至今的諸多開源軟件中很少見的一例。因為同時期大部分的軟件，都已經成為了歷史。而像emacs這樣，至今仍然相當活躍的項目實在是鳳毛麟角。

從git log看SDL的發展史

SDL盡管使用廣泛，但從代碼來看基本上是Sam Lantinga的個人作品。

Sam Lantinga早年創建了Loki Software，專門將Windows游戲移植到Linux平臺上，SDL正是這個時期的產物。著名的《英雄無敵3》Linux版就是Loki Software制作的。

后來他先后供職于Blizzard Entertainment和Valve Software，是暴雪的主力程序員之一。

MiniGUI

MiniGUI雖然是開源項目，但是并沒有提供版本庫，也就沒有版本歷史了。

作為一個曾經輝煌的國產開源項目，MiniGUI在00年代曾與LVS、SCIM并稱為三大國產開源軟件。更是當時嵌入式GUI開發方面不多的幾個選擇之一，江湖地位也很高。

但是自從Android橫空出世之后，MiniGUI的日子就不太好過了。其主線版本停在了v3.0.12（2012年），距離它的配套開發工具產品mStudio的推出不過3年時間。等于是辛辛苦苦將產品的版圖擴充完整，卻發現產品本身已經沒有市場前途了……

出現這種情況的原因，其實與MiniGUI本身沒有太大關系。當年的主要競爭對手Qt和GTK在嵌入式領域同樣一敗涂地。這一方面是由于Android實在是太強太好了，另一方面更重要的是硬件的進步，導致原先的這些資源消耗較小的GUI系統，變得不是那么非用它不可了。而比較功能的話，一個單純的GUI和一個全功能的框架之間根本就沒有可比性，就連最重量級的Qt也一樣不行。

MiniGUI的作者魏永明所創建的飛漫公司，我曾經在2009年的時候，去那里面試過。當時的考官是個中年人，也不知道是不是魏老師本人。應該說筆試面試的情況還是很好的。這家公司的筆試題比較基礎細致，在那次找工作的筆試中算比較難的，超過了騰訊。但給的薪水卻非常低，甚至比我畢業時的第一份工作還低。可見在國內，以開源軟件開發為主業的公司，日子過的還是很困難的。

MiniGUI慘淡之后，飛漫公司轉戰移動APP領域，但從網站上的版本更新狀態來看，這次的轉型似乎并不成功。

由此延伸開去，Android興起前后，一大堆公司的命運都被隨之改變。

1.博望科技。我所關注的牛人李先靜之前所在的公司。當初為了開發彩信相關的功能，找到了牛人李的博客，于是也就持續關注了這個公司好幾年。博望科技早先的目標是基于GTK搭建一個智能手機平臺。

可惜直到Android出來的時候，完工度也不高。后來及時掉頭，研究Android技術，成為最早的一批國產Android手機制造商和解決方案提供商。可惜從根本來說，Android的目的是降低智能手機的門檻。隨著會的人越來越多，這類解決方案商就變得可有可無了。

同樣的例子還有德信無線。

牛人李由于過度勞累，大病一場，大概3年前離開了該公司，至今仍處于半修養狀態。

應該說，Android最開始的思路，實際上就和博望不同。Android盯著的是未來的硬件，或者說是硬件期貨，所以一開始硬件的規格就比較高。尤其在最初的時候，不是頂級配置根本跑不了Android。而飛漫、博望的思路是如何利用現有的硬件做出好的產品，或者說是用盡可能少的錢（這通常意味著硬件的規格是向下的，或者至少是維持原狀的）做出產品來。

但硬件的規格總是向上發展的，于是最初頂配才能跑的Android，現在隨便什么硬件都能跑的了。這個時候，飛漫、博望之類的產品也就無人問津了。畢竟GUI應用，在嵌入式中還算是重量級的，真的低端設備，如傳感器之類的，也用不上這個。

我之前的公司，早先還曾經有個單核跑雙系統的AP+BP融合方案，目標是造出千元級別的Android手機。可惜也是逆了技術潮流，后來的AP都已經是雙核的了，根本不需要你這樣的方案來節省內核數。而最終，千元或以下的Android手機被造了出來，但根本就和這個方案無關，完全得益于硬件制造成本的下降。

但單核跑雙系統的虛擬化方案本身還是很有技術含量的，國內當時根本沒人會。這個項目主要是法國的團隊主導的。

2.播思通信。中移動為了搞OMS成立的公司，我有同事在那里工作，本人也曾經去那里面試過。可惜由于技術實力太差，縱有中移動在背后站臺，也還是爛泥扶不上墻。很快就被Google半年一次的更新甩在了身后。當然這也是Google的江湖地位使然。雖然播思也做出了輸入法框架，但不是你主導的項目，你的再好，我也不用，很快就讓你的勞動成了無用功。總的來說，這些Android改的系統，越深度定制越死的快，反倒是換皮的MIUI之類的，活的挺好的。

3.魅族。魅族在Wince時代，曾有一款深度定制的M8，當初曾寄望于成為國產的iPhone。事實上，如果沒有Android的話，這個目標差不多就實現了。并不是說達到iPhone的水平，而是說除了iPhone之外，別人都沒有我的好。

可惜Android的出現，使得一般的手機廠商也能造出現代的智能手機，于是魅族的這番努力，其實并沒有得到多少的回報。總算魅族并不是手機解決方案商，而是制造商，沒辦法標新立異，卻也不至于被別人甩下來。因此，魅族現在的日子，也還說的過去。

總結

以上是生活随笔為你收集整理的从版本库看开源项目的发展史的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。