class="topic_img" alt=""/>
文/庄表伟
引子：开源项目那么多，哪些是值得我们学习的？
这里声明一下，仅仅是学习一下：他们是用哪些工具，来管理自己的项目的？
开源项目多如牛毛，值得分析的项目也很多很多。从哪里入手呢？幸运的是，在开源社区，有一个著名的网站，过去叫 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 个项目，使用配置库的情况（有些项目，同时使用多种配置库），有两个现象值得注意：
通过数据来分析：是否使用 Github 与项目创建时间的关系
imageView2/2/w/1240" alt="" width="560" height="605" />
通过这个图，可以看出两个现象：
通过数据来分析：是否使用 Github 与项目代码规模的关系
由于不同的开源项目，代码行数差异巨大，因此我们只能以 log (col)对数结果，来做区间划分。可以看到一个非常明显的趋势，当然代码行数超过 10 万行以后，代码部署在 Github 上的项目，就开始明显下降，直到为0。
总结：是否使用 Github，越是新的项目越愿意用；越是大的项目越没法用。
第二个问题：他们用什么来管理 issue？
排名前五的工具中，Github：91 个项目；Bugzilla：81 个项目；JIRA：43 个项目；Trac：20 个项目；另外还有 9 个项目，完全是在 maillist 里“管理”issue 的。
一共有 39 种不同的工具，另外还有 6 个项目，我们无法了解他究竟是用什么来管理的。
简单的来看：
通过数据来分析：使用的 issue tracking 工具与项目创建时间的关系
1990 年之前创建的项目，其中有一个已经开始使用 Github 了。但是，这仅仅算是个案。更加明显的趋势是：越是新的项目，越是倾向于采用 Github 管理自己的 issue。
相对而言，其他各种 Issue Tracking 工具的比例，都在下降。
通过数据来分析：使用的 issue tracking 工具与项目规模的关系
随着用户数量的增加，我们猜想：issue 的数量与复杂度，也会逐渐增加。可以看到这样的趋势：Github 的使用率，也在不断下降。
总结：是否使用 Github 来管理项目的 issue，越是新的项目越愿意用；越是大的项目越没法用。
尚未完成的分析：
主要还是工作量太大了。。。对这个分析有兴趣的同学，可以与我联系，咱们可以一块来干。
相关文章
