引子：开源项目那么多，哪些是值得我们学习的？
这里声明一下，仅仅是学习一下：他们是用哪些工具，来管理自己的项目的？
开源项目多如牛毛，值得分析的项目也很多很多。从哪里入手呢？幸运的是，在开源社区，有一个著名的网站，过去叫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个了。
三个感想
成功的开源项目，真是凤毛麟角
绝大多数开源项目都是少数人开发的小项目
这331个项目，也许可以作为我们的重要参考
第一个问题：他们用什么配置库？
这是331个项目，使用配置库的情况（有些项目，同时使用多种配置库），有两个现象值得注意：
接近92%的项目，已经在使用git——git的统治地位，已经无可动摇
只有53%的项目，在使用Github——那些用git却不用Github的项目，是什么原因？
通过数据来分析：是否使用Github与项目创建时间的关系
通过这个图，可以看出两个现象：
越是新创建的开源项目，hosting在Github上比例越高
越是新创建的开源项目，事实上成功的也越多（当然，2010年以后的数量锐减，我们怀疑是好酒也要陈酿的原因）
通过数据来分析：是否使用Github与项目代码规模的关系
由于不同的开源项目，代码行数差异巨大，因此我们只能以log(col)对数结果，来做区间划分。可以看到一个非常明显的趋势，当然代码行数超过10万行以后，代码部署在Github上的项目，就开始明显下降，直到为0。
总结：是否使用Github，越是新的项目越愿意用；越是大的项目越没法用。
第二个问题：他们用什么来管理issue？
排名前五的工具中，Github：91个项目；Bugzilla：81个项目；JIRA：43个项目；Trac：20个项目；另外还有9个项目，完全是在maillist里“管理”issue的。
一共有39种不同的工具，另外还有6个项目，我们无法了解他究竟是用什么来管理的。
简单的来看：
Github已经占据统治地位
Github的占有率仅仅27%。
Bugzilla也算老而弥坚
有很多项目，在选择自己的工具
通过数据来分析：使用的issue tracking工具与项目创建时间的关系
1990年之前创建的项目，其中有一个已经开始使用Github了。但是，这仅仅算是个案。更加明显的趋势是：越是新的项目，越是倾向于采用Github管理自己的issue。
相对而言，其他各种Issue Tracking工具的比例，都在下降。
通过数据来分析：使用的issue tracking工具与项目规模的关系
随着用户数量的增加，我们猜想：issue的数量与复杂度，也会逐渐增加。可以看到这样的趋势：Github的使用率，也在不断下降。
总结：是否使用Github来管理项目的issue，越是新的项目越愿意用；越是大的项目越没法用。
尚未完成的分析：
开源项目使用的CI工具的情况
开源项目使用的Code Review工具的情况
开源项目使用的文档类工具的情况
......
主要还是工作量太大了。。。对这个分析有兴趣的同学，可以与我联系，咱们可以一块来干。
作者：庄表伟 from 简书
引用来自“慕小怪”的评论
“总结：是否使用Github，越是新的项目越愿意用；越是大的项目越没法用。” 这结论下的有点鲁莽吧。Linux代码就托管在gitbub上，那个代码量也很大啊。引用来自“杭州小明”的评论
不对吧，内核的代码在github上只是个镜像，可以pr，但没有issue引用来自“慕小怪”的评论
“总结：是否使用Github，越是新的项目越愿意用；越是大的项目越没法用。” 这结论下的有点鲁莽吧。Linux代码就托管在gitbub上，那个代码量也很大啊。引用来自“a358003542”的评论
第一 openhub里面的数据是否能够反映全貌还是个问题，又经过了一次抓取，这次抓取细节是否有问题，文中也没有说。这等于是二次数据了。就算是二次数据，假设问题不大，最后一个结论莫名其妙吗。直接把issue和使用率挂钩。。会数据分析不会基本的逻辑推理真的让人很悲哀。更奇葩的是就算是使用率，最后一张图没有看到时间因素，就给我扯减少。
结论就是本文毫无价值。
引用来自“隐形人”的评论
简书上也看到了这篇文章引用来自“a358003542”的评论
第一 openhub里面的数据是否能够反映全貌还是个问题，又经过了一次抓取，这次抓取细节是否有问题，文中也没有说。这等于是二次数据了。就算是二次数据，假设问题不大，最后一个结论莫名其妙吗。直接把issue和使用率挂钩。。会数据分析不会基本的逻辑推理真的让人很悲哀。更奇葩的是就算是使用率，最后一张图没有看到时间因素，就给我扯减少。
结论就是本文毫无价值。