微软开源 .NET 一年后……

大约一年前，微软宣布开源了 .NET 框架的大部分。当时，Scott Hanselman 使用微软 Power BI 对代码库做了一个漂亮的分析。 现在一年过去了，我想要试试对以下问题做个解答：

微软开源了 .NET 框架的大部分之后，社区参与贡献了多少？

我着眼于以下三个项目做了分析，它们是 .NET 生态系统中最主要部分之一，也是 .NET 基金会内 最活跃/收藏/分支的项目之一：

• Roslyn – .NET 编译器平台，提供了开源的 C# 和 Visual Basic 编译器，以及丰富的代码分析 API。
• CoreCLR – .NET Core 运行时环境和底层库（mscorlib），它包括垃圾回收、JIT 编译器、基本的 .NET 数据类型和许多底层类。
• CoreFX – .NET Core 基础库，包括 collections、文件系统、console、XML、异步以及其它方面的类。

数据来自哪里？

GitHub 自身已经内建了很多漂亮的图表了，你可以看看这一年来每月提交数的图表：

还可以看看每月动态：

但是要回答上面的问题，我需要更多的数据。幸运的是， GitHub 提供了非常全面的 API， 再配合上出色的 Octokit.net 库以及 brilliant LINQPad，我就很容易的得到了我所需的全部数据。如果你想要自己试试这些 API ，这儿有个示例的 LINQPad 脚本。

然而，仅仅知道它的每月 “ 问题 （ issue ） 数量” 或 “接受的PR（ 拉取请求 （ Pull Request ） ）”并没有太大用处，这并不能告诉我们是谁提交了这些问题或 PR。 幸运的是， GitHub 典型的用户是有分类的，比如下图来自 Roslyn 第 670 号问题 ，我们可以看到是哪种类型的用户提交的备注：“ 拥有者 （ Owner ） ”、 “ 协作者 （ Collaborator ） ” 或者为空——这就是“社区”成员，比如下面的某人（我觉得）并没有在微软工作。

结果呢？

现在我们可以得到我们所需的数据，也就可以生成结果了。

全部问题 - 按提交者分组

这里你可以看到拥有者和协作者在某些情况下占有主导地位，比如，在 Roslyn 项目中 60% 的问题是他们汇报的。但是在另外的例子中社区非常活跃，特别是在 CoreCLR 项目中社区成员汇报的问题超过了拥有者/协作者之和。造成这种情况的部分原因是项目的不同， CoreCLR 是 .NET 框架中最引人注目的部分，因为它包含了 .NET 开发者日常使用的大部分库，所以并不用对社区提交了很多改进建议和错误修复的事情感到惊奇。 另外， CoreCLR 已经出现了较长时间，社区已经使用了一段时间，也能找到它的一些不足的部分。而 Roslyn 则相对较新一些，还没有被太多的使用过，而且找到一个编译器的 bug 显然会更难。

全部已接受的 PR - 按提交者分组

但是，如果我们来看一下已接受的 PR ，可以看到在这三个项目中社区的贡献量非常低，仅仅只有 12% 左右。不过，这并不令人吃惊，因为 PR 需要达到相当高的水准才能被接受。如果项目采用这种机制，首先你必须找到一个 “需要解决” （ up for grabs ） 的问题，然后如果你要改变 API 就必须通过代码审查，最后你必须在代码审查中符合可比性/性能提升/正确性等。所以，实际上 12% 是个相当不错的结果，接受的 PR 解决了不少的问题，特别是考虑到大部分贡献都是社区成员在工作之余完成的。

更新：关于对“需要解决”的要求，参见 David Kean 的这个评论，以及这条推来了解更多信息。“需要解决”是一个准则，旨在帮助新手，但是并不是必需的，你可以提交一个解决问题的 PR 而不打上这个标签。

最后，如果你看一下每月的数量（参见下面的两张图，点击放大），很难找到特定的趋势，或者说，社区肯定会随着时间的变化或多或少的做出贡献。不过，你也可以说，过去一年来社区一直在做贡献，而且看起来还会继续贡献下去。这不是仅仅出现在项目刚刚开源后的一次性喷发，而是一整年以来的贡献的持续水平。

每月的问题数 - 按提交者分组

每月接受的 PR - 按提交者分组

前 20 的问题标签

最后一件我想对我拥有的这些数据所做的事情是找到那些最流行的问题标签，这可以揭示从三个项目开源以来哪种类型的工作不断出现。

以下是关于这些结果的一些看法：

• 列表中 CodeGen 排名如此之高没有什么好惊奇的，下一代的 .NET JIT 编译器 RyuJIT 才发布了仅仅两年而已。然而如此多的问题还是让人有一点点担心，特别是考虑到它们中的一些会带来严重的后果，就如 Stack Overflow 的开发人员发现的那样！题外话，如果你想要了解 JIT 的许多底层细节，可以看看 @MikeDN 评论过的这个问题，令人难以置信的是，有些掌握了很多知识的人却自己并不从事这方面工作，甚至是微软的另外团队的！
• 这三个项目都有许多“需要解决”的问题： Roslyn、 CoreCLR 和 CoreFX，而且社区似乎也在添加需要解决的问题！
• 最后，我很高兴的看到 性能 和 优化 日益得到了重视，毕竟 性能是王道！ （ Performance is a Feature!! ）

本文转载来自 Linux 中国: https://github.com/Linux-CN/archive