博客水木

微软已经开源 .NET framework 的核心部分一年多了，之前 Scott Hanselman 做了一个 非常好的源代码分析工具，基于微软的 Power BI 实现。本文也是通过这个分析工具得出的结论，.NET 框架核心部分开源一年多了：

自从微软开源之后，究竟社区参与了多少？

这里会以 3 个 .NET 生态系统中最主要的三个部分来说明，这些项目也是 .NET 基金会最活跃/最多 star 和最多 Fork 的项目：

• Roslyn – .NET 编译平台 (“Roslyn”) 提供开源 C# 和 Visual Basic 的编译器，支持富代码分析 APIs。
• CoreCLR – .NET Core 运行时，名为 CoreCLR，包括一个基础库 mscorlib。CoreCLR 包括垃圾收集器，JIT 编译器，基础 .NET 数据类型和大量低级别类。
• CoreFX –  .NET Core 函数库，包括集合，文件系统，工作台，XML，异步等等。

现有数据

GitHub 自身也有一些内置图表，以下就是整一年中的 Commits per Month：

还有一个很清晰的仪表盘可以查看 Monthly Pulse

但是要回答那个问题还需要更多的数据，幸运的是，GitHub 还提供一个非常不错的 API，完美的结合了 Octokit.net library 和 LINQPad，这样可以轻松的获取想要的数据。这里有个示例 LINQPad 脚本。

但是，即使知道每个月的 “# of Issues” 或者 “Merged Pull Requests” 也没有用，因为不能知道是谁创建了 issue 和提交了 PR。但是 GitHub 还有一个功能，可以识别不同的用户。请看 Roslyn Issue #670，可以清楚的识别用户是项目所有者还是协作者，没有任何说明的就是社区参与人员。

结果

数据已经到手，结果就在数据里面：

总 Issues 数 – By Submitter

在这里可以看出，在某些情况下，拥有者和协作者贡献占主导地位。例如：Roslyn 几乎 60% 的 issues 是拥有者和协作者开启的。但是在另一些方面，社区表现会很活跃，特别是在 CoreCLR，这个项目社区成员开启的 issue 比较多。还有一部分原因是不同的项目，CoreCLR 是 .NET 最明显的部分，包括微软的一些网络框架，.NET 开发者日常开发经常用到，所以社区会有比较多的建议，改进和修复，而且 CoreCLR 是比较有历史的一个库。相对来说，Roslyn 是一比较新的项目，平常比较少用，而且在编译器找错误也是比较困难的。

总合并 Merged Pull Requests – By Submitter

但是当我们看合并的 Pull Requests 数，社区成员无疑是参与比较少的，只有大概 12%。但这并不意外，因为不是所有的 pull request 都被接受。首先，项目会使用他自己的机制，“up for grabs“，所以 12% 已经很不错了。

更新： “up for grabs” 并不是必要的。

每个月的 Issues 数 – By Submitter

每个月合并的 Pull Request – By Submitter

issue 标签 Top 20

最常使用的 issue 标签 TOP 20

这是根据结果的一些观察：

• 列表里面的 CodeGen 很高，但也不意外，因为 RyuJIT – 下一代 .NET JIT 编译器才发布了两年。
• 3 个项目都包括大量的 “Up for Grabs” issues，详情请看 Roslyn, CoreCLR 和 CoreFX
• Performance 和 Optimisation 一直都被重视，总而言之 Performance is a Feature!!

继续分析这个问题，但是主要关注的是 ASP.NET 生态圈下的项目：

• MVC -构建动态 Web 网站的 模型-视图-控制器 框架，包括合并 MVC，Web API 和 Web Pages w/ Razor。
• DNX – DNX (一个 .NET 执行环境) 包括启动和运行应用所需要的代码，包括编译系统，SDK 工具和原生 CLR hosts。
• EntityFramework – 微软为 .NET 新应用推荐的数据访问技术
• KestrelHttpServer – ASP.NET 5 基于 libuv 的 Web 服务器

方法论

在上一篇文章把 issues/PRs 创建者分为项目拥有者，协作者和社区成员。但是这会有一些质疑，有一些协作者并不是微软员工。

所以，决定分为以下两种角色：

• 微软
  
• 社区

这是可行的，因为所有微软员工都会在 GitHub 个人信息里面标记为微软员工，比如：

结果

经过这个调查分析，“issues”超过 60% 是社区成员创建的，合并的“Pull Requests”有超过 30% 是社区成员完成的。但是，这个数据平均值已经被 EntityFramework 项目变得有点不真实，因为 EntityFramework 里面微软员工完成合并的 PRs 比社区成员的多太多，如果忽略这个项目，社区成员完成的 PRs 数可以达到 44%。

Issues 创建 (2013 年 11 月 – 2015 年 12 月)

合并的 Pull Requests (2013 年 11 月 – 2015 年 12 月)

注意：这里包括了 Kestrel Http Server 项目，因为这是非常有趣的一个事例，当前 #1 贡献者并不是微软员工，他是 Ben Adams，在改进内存使用做了很大的贡献。

每个月创建的 Issues – By Submitter (点击查看原图)

每个月合并的 Pull Request  – By Submitter (点击查看原图)

人们的贡献总和

不同角色 GitHub 用户对每个项目的总贡献程度，issue 创建和 PR 合并：

FSharp

Isaac Abraham 指出了之前那篇文章的一些问题：

.NET 在一年之间开源的部分不仅仅是这么多，还有  F# 编译器和 FSharp.Core。

为了确认这个，大概浏览了一下 FSharp 库：

• microsoft/visualfsharp
• fsharp/fsharp

就像 Isaac 解释的，他们的关系是：

… visualfsharp 是微软的库 Visual F#，另一个是社区所有。前者是直接集成到 Visual Studio 的 Visual F# 工具链；后者是类似 Xamarin 的工具。这里有一个 (过时) 关系解释图，其他内容请看 http://fsharp.github.io/。

FSharp – Issues 创建数 (2010 年 12 月 – 2015 年 12 月)

FSharp – 合并的 Pull Requests (2011 年 5 月 – 2015 年 12 月)

总结

社区越来越多的响应会促使微软开源更多的项目代码。