微软开源 .NET 一年后，ASP.NET 情况分析
在前一篇文章中，我们了解了微软在开源了 .NET 框架中最大一部分一年以来社区的参与情况。
接下来，我们将继续重复这个分析，但是这次我们将针对 ASP.NET 系列项目进行分析：
- MVC - 通过分成“模型-视图-控制器（MVC）”等不同的概念部分来构建动态网站的框架，包括合并的 MVC、 Web API、 和 Web Pages w/ Razor。
- DNX - DNX（一个 .NET 扩展环境）包含了用于启动和运行应用的代码，包括编译系统、SDK 工具和原生 CLR 宿主。
- EntityFramework - 微软推荐用于新的 .NET 应用的数据访问技术。
- KestrelHttpServer - 一个基于 libuv 的 ASP.NET 5 的 Web 服务器。
方法
在上一篇中，我们首先把 问题 （ issue ） / 拉取请求 （ PR ） 分成 拥有者 （ Owner ） 、 协作者 （ Collaborator ） 或 社区 （ Community 三类。然而这有一些问题，正如在评论中指出的那样，有几个人并非微软雇员，但是由于其在某个项目上的积极贡献也被列为了协作者，比如 @kangaroo 和 @benpye。
为了解决这个问题，我决定分成两类：
- 微软
- 社区
这是可行的，因为（基本上）所有的微软雇员都会在其 GitHub 个人页面上标记其为微软雇员，比如：
这种情况有一些例外，比如 @shanselman 显然是在微软工作，不过这种情况很好解决。
结果
在结束了所有分析之后，我得到了结果。总的来说，超过 60% 的“ 发现的问题 （ Issues Created ） ”和 33% 的“ 合并的 PR （ Merged Pull Requests ） ”来自社区。然而，PR 的占比受到了 Entity Framework 项目中微软雇员超高的 PR 数量的影响，从而有些不能准确反映情况。如果忽略这个项目，社区贡献的 PR 将占到 44%。
发现的问题（2013/11 - 2015/12）
| 项目 | 微软 | 社区 | 合计 |
|---|---|---|---|
| aspnet/MVC | 716 | 1380 | 2096 |
| aspnet/dnx | 897 | 1206 | 2103 |
| aspnet/EntityFramework | 1066 | 1427 | 2493 |
| aspnet/KestrelHttpServer | 89 | 176 | 265 |
| 合计 | 2768 | 4189 | 6957 |
合并的 PR（2013/11 - 2015/12）
| 项目 | 微软 | 社区 | 合计 |
|---|---|---|---|
| aspnet/MVC | 385 | 228 | 613 |
| aspnet/dnx | 406 | 368 | 774 |
| aspnet/EntityFramework | 937 | 225 | 1162 |
| aspnet/KestrelHttpServer | 69 | 88 | 157 |
| 合计 | 1798 | 909 | 2706 |
备注：我包括了 Kestrel Http Server 项目，因为它是一个有趣的例子。当前它的第一号贡献者 Ben Adams 并非微软雇员，他为改善其内存使用做出了很大的贡献，让 Kestrel 可以每秒钟接受更多的请求。
通过观察随时间推移的变化，可以很清楚的看到社区（浅色条）在过去两年（2013/11 - 2015/12）来的参与情况，看起来并不像是趋于停止。
每月发现的问题数 - 按提交者
此外，虽然社区参与情况可以很容易地从每月发现的问题数上看出来，不过从合并的 PR 数上也可以再次印证这两年来的趋势。
每月合并的 PR 数 - 按提交者
贡献总数
每个项目的贡献人数也很有意思。通过这个你可以看到社区贡献者的实际规模，并不是少量的人做了大量的工作，而是这些工作由大量的人分散完成的。
这个表格展示了每个项目中发现问题和提交了被合并的 PR 的人数：
| 项目 | 微软 | 社区 | 合计 |
|---|---|---|---|
| aspnet/MVC | 39 | 395 | 434 |
| aspnet/dnx | 46 | 421 | 467 |
| aspnet/EntityFramework | 31 | 570 | 601 |
| aspnet/KestrelHttpServer | 22 | 95 | 117 |
| 合计 | 138 | 1481 | 1619 |
FSharp
在我的第一篇文章的评论中，Isaac Abraham 指正说:
.NET 的一部分已经开源一年多了，F# 编译器和 FSharp.Core 已经开源一段时间了。
所以，为了解决这个问题，我去了解了一下主要的 FSharp 仓库：
按 Isaac 的解释，他们之间的关系是：
… visualfsharp 是微软自己的 Visual F# 版本仓库。而另外一个是社区管理的一个。前一个是直接作为 Visual Studio 其中的 Visual F# 工具；而后一个则是类似 Xamarin 的东西。这里有个（稍微过时的）解析它们关系的图表，以及另外一个有用的资源：http://fsharp.github.io/ 。
FSharp - 发现的问题（2010/12 - 2015/12）
| 项目 | 微软 | 社区 | 合计 |
|---|---|---|---|
| fsharp/fsharp | 9 | 312 | 321 |
| microsoft/visualfsharp | 161 | 367 | 528 |
| 合计 | 170 | 679 | 849 |
FSharp - 合并的 PR（2011/5 - 2015/12）
| 项目 | 微软 | 社区 | 合计 |
|---|---|---|---|
| fsharp/fsharp | 27 | 134 | 161 |
| microsoft/visualfsharp | 36 | 33 | 69 |
| 合计 | 63 | 167 | 230 |
结论
我认为，公平地说社区已经对微软越来越多地开源其代码的动作做出了回应。在几个项目上社区花费了大量时间，做出了显著的贡献。虽然你可以说微软也花费了大量的时间来开源，但是看起来 .NET 开发人员很喜欢他们做的事情，体现了可观的社区响应。