从版本库看开源项目的发展史

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的出现,使得一般的手机厂商也能造出现代的智能手机,于是魅族的这番努力,其实并没有得到多少的回报。总算魅族并不是手机解决方案商,而是制造商,没办法标新立异,却也不至于被别人甩下来。因此,魅族现在的日子,也还说的过去。

你可能感兴趣的:(从版本库看开源项目的发展史)