译自:http://mattwarren.org/2015/12/08/open-source-net-1-year-later/
作者: matt
原创:LCTT https://linux.cn/article-6727-1.html
译者: Xingyu.Wang
大约一年前,微软宣布开源了 .NET 框架的大部分。当时,Scott Hanselman 使用微软 Power BI 对代码库做了一个漂亮的分析。 现在一年过去了,我想要试试对以下问题做个解答:
微软开源了 .NET 框架的大部分之后,社区参与贡献了多少?
我着眼于以下三个项目做了分析,它们是 .NET 生态系统中最主要部分之一,也是 .NET 基金会内 最活跃/收藏/分支的项目之一:
GitHub 自身已经内建了很多漂亮的图表了,你可以看看这一年来每月提交数的图表:
还可以看看每月动态:
但是要回答上面的问题,我需要更多的数据。幸运的是, GitHub 提供了非常全面的 API, 再配合上出色的 Octokit.net 库以及 brilliant LINQPad,我就很容易的得到了我所需的全部数据。如果你想要自己试试这些 API ,这儿有个示例的 LINQPad 脚本。
然而,仅仅知道它的每月 “问题数量” 或 “接受的PR( 拉取请求)”并没有太大用处,这并不能告诉我们是谁提交了这些问题或 PR。 幸运的是, GitHub 典型的用户是有分类的,比如下图来自 Roslyn 第 670 号问题 ,我们可以看到是哪种类型的用户提交的备注:“拥有者”、 “协作者” 或者为空——这就是“社区”成员,比如下面的某人(我觉得)并没有在微软工作。
现在我们可以得到我们所需的数据,也就可以生成结果了。
项目 | 拥有者 | 协作者 | 社区 | 全部 |
---|---|---|---|---|
Roslyn | 481 | 1867 | 1596 | 3944 |
CoreCLR | 86 | 298 | 487 | 871 |
CoreFX | 334 | 911 | 735 | 1980 |
全部 | 901 | 3076 | 2818 |
这里你可以看到拥有者和协作者在某些情况下占有主导地位,比如,在 Roslyn 项目中 60% 的问题是他们汇报的。但是在另外的例子中社区非常活跃,特别是在 CoreCLR 项目中社区成员汇报的问题超过了拥有者/协作者之和。造成这种情况的部分原因是项目的不同, CoreCLR 是 .NET 框架中最引人注目的部分,因为它包含了 .NET 开发者日常使用的大部分库,所以并不用对社区提交了很多改进建议和错误修复的事情感到惊奇。 另外, CoreCLR 已经出现了较长时间,社区已经使用了一段时间,也能找到它的一些不足的部分。而 Roslyn 则相对较新一些,还没有被太多的使用过,而且找到一个编译器的 bug 显然会更难。
项目 | 拥有者 | 协作者 | 社区 | 全部 |
---|---|---|---|---|
Roslyn | 465 | 2093 | 118 | 2676 |
CoreCLR | 378 | 567 | 201 | 1146 |
CoreFX | 516 | 1409 | 464 | 2389 |
全部 | 1359 | 4069 | 783 |
但是,如果我们来看一下已接受的 PR ,可以看到在这三个项目中社区的贡献量非常低,仅仅只有 12% 左右。不过,这并不令人吃惊,因为 PR 需要达到相当高的水准才能被接受。如果项目采用这种机制,首先你必须找到一个 “需要解决”的问题,然后如果你要改变 API 就必须通过代码审查,最后你必须在代码审查中符合可比性/性能提升/正确性等。所以,实际上 12% 是个相当不错的结果,接受的 PR 解决了不少的问题,特别是考虑到大部分贡献都是社区成员在工作之余完成的。
更新:关于对“需要解决”的要求,参见 David Kean 的这个评论,以及这条推来了解更多信息。“需要解决”是一个准则,旨在帮助新手,但是并不是必需的,你可以提交一个解决问题的 PR 而不打上这个标签。
最后,如果你看一下每月的数量(参见下面的两张图,点击放大),很难找到特定的趋势,或者说,社区肯定会随着时间的变化或多或少的做出贡献。不过,你也可以说,过去一年来社区一直在做贡献,而且看起来还会继续贡献下去。这不是仅仅出现在项目刚刚开源后的一次性喷发,而是一整年以来的贡献的持续水平。
最后一件我想对我拥有的这些数据所做的事情是找到那些最流行的问题标签,这可以揭示从三个项目开源以来哪种类型的工作不断出现。
以下是关于这些结果的一些看法: