从28万个开源项目中,我们能够学到一些什么?

引子:开源项目那么多,哪些是值得我们学习的?

这里声明一下,仅仅是学习一下:他们是用哪些工具,来管理自己的项目的?

开源项目多如牛毛,值得分析的项目也很多很多。从哪里入手呢?幸运的是,在开源社区,有一个著名的网站,过去叫oloho,现在改名叫openhub。在他的网站首页,有这么四行字,以表明他们的数据库是多么的全面、丰富:

Indexing 669,008 open source projects
Connecting 3,742,793 open source contributors
Tracking 679,761 source control repositories
Counting 31,158,335,454 lines of code

这么说来,事情就变得比较“简单”了,我需要把openhub的数据,都抓回来。


数据的筛选过程

具体的数据抓取过程,简直不忍详述(我的内心,几乎是崩溃的)。总而言之,我只抓到了289,631个项目。openhub虽然号称自己索引了66万的开源项目,其实这仅仅是他的数据库里的最大ID号!当我顺着这个ID一个一个的去抓的时候,有很多ID,都已经被删除了。

在抓取到的项目数据中,有两个数值,特别值得参考:contributors(参与开发者的数量);users(该软件的用户数量)。相对而言,users的数据,可以认为是一个样本,即该开源项目的所有用户中,愿意并且知道该如何来openhub点击I use this的人。因此,即使是排名第一的Firefox,在openhub也只有13158个用户。考虑到Firefox的用户数,已经超过5亿(来源于维基百科英文版),因此,我们相信这个数据仅仅是一个4万分之一的采样结果。

随后,我观察了这28万多个项目的users数据与contributors数据,顿时惊讶的发现,绝大多数项目,都小的可怜,用户也少得可怜。

当我以“select count(*) from projects where contributors>30”查询时,只搜到了  1662个项目...
当我以“select count(*) from projects where users>30”查询时,只搜到了1260个项目...
当我合并以上两个条件查询时,只搜到了335个项目。
再从这335个项目中,排除掉最近一年已经不再有活动的项目,于是只剩下了331个了。

三个感想

  1. 成功的开源项目,真是凤毛麟角
  2. 绝大多数开源项目都是少数人开发的小项目
  3. 这331个项目,也许可以作为我们的重要参考

第一个问题:他们用什么配置库?


这是331个项目,使用配置库的情况(有些项目,同时使用多种配置库),有两个现象值得注意:

  1. 接近92%的项目,已经在使用git——git的统治地位,已经无可动摇
  2. 只有53%的项目,在使用Github——那些用git却不用Github的项目,是什么原因?

通过数据来分析:是否使用Github与项目创建时间的关系



通过这个图,可以看出两个现象:

  1. 越是新创建的开源项目,hosting在Github上比例越高
  2. 越是新创建的开源项目,事实上成功的也越多(当然,2010年以后的数量锐减,我们怀疑是好酒也要陈酿的原因)

通过数据来分析:是否使用Github与项目代码规模的关系



由于不同的开源项目,代码行数差异巨大,因此我们只能以log(col)对数结果,来做区间划分。可以看到一个非常明显的趋势,当然代码行数超过10万行以后,代码部署在Github上的项目,就开始明显下降,直到为0。

总结:是否使用Github,越是新的项目越愿意用;越是大的项目越没法用。


第二个问题:他们用什么来管理issue?


排名前五的工具中,Github:91个项目;Bugzilla:81个项目;JIRA:43个项目;Trac:20个项目;另外还有9个项目,完全是在maillist里“管理”issue的。

一共有39种不同的工具,另外还有6个项目,我们无法了解他究竟是用什么来管理的。

简单的来看:

  1. Github已经占据统治地位
  2. Github的占有率仅仅27%。
  3. Bugzilla也算老而弥坚
  4. 有很多项目,在选择自己的工具

通过数据来分析:使用的issue tracking工具与项目创建时间的关系


1990年之前创建的项目,其中有一个已经开始使用Github了。但是,这仅仅算是个案。更加明显的趋势是:越是新的项目,越是倾向于采用Github管理自己的issue。

相对而言,其他各种Issue Tracking工具的比例,都在下降。

通过数据来分析:使用的issue tracking工具与项目规模的关系


随着用户数量的增加,我们猜想:issue的数量与复杂度,也会逐渐增加。可以看到这样的趋势:Github的使用率,也在不断下降。

总结:是否使用Github来管理项目的issue,越是新的项目越愿意用;越是大的项目越没法用。


尚未完成的分析:

  • 开源项目使用的CI工具的情况
  • 开源项目使用的Code Review工具的情况
  • 开源项目使用的文档类工具的情况
  • ......

主要还是工作量太大了。。。对这个分析有兴趣的同学,可以与我联系,咱们可以一块来干。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,390评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,821评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,632评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,170评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,033评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,098评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,511评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,204评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,479评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,572评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,341评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,213评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,576评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,893评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,171评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,486评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,676评论 2 335

推荐阅读更多精彩内容