微软开源 .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 的
.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 的
在[前一篇文章](/article-6727-1.html)中，我们了解了微软在开源了 .NET 框架中最大一部分一年以来社区的参与情况。


接下来，我们将继续重复这个分析，但是这次我们将针对 [**ASP.NET**](https://github.com/aspnet) 系列项目进行分析：


* [**MVC**](https://github.com/aspnet/mvc/) - 通过分成“模型-视图-控制器（MVC）”等不同的概念部分来构建动态网站的框架，包括合并的 MVC、 Web API、 和 Web Pages w/ Razor。
* [**DNX**](https://github.com/aspnet/dnx/) - DNX（一个 .NET 扩展环境）包含了用于启动和运行应用的代码，包括编译系统、SDK 工具和原生 CLR 宿主。
* [**EntityFramework**](https://github.com/aspnet/EntityFramework/) - 微软推荐用于新的 .NET 应用的数据访问技术。
* [**KestrelHttpServer**](https://github.com/aspnet/KestrelHttpServer/) - 一个基于 libuv 的 ASP.NET 5 的 Web 服务器。


![](/data/attachment/album/201601/23/004421blb9698l0zli99vb.jpg)


### **方法**


在[上一篇](/article-6727-1.html)中，我们首先把<ruby> 问题 <rp>  （ </rp> <rt>  issue </rt> <rp>  ） </rp></ruby>/<ruby> 拉取请求 <rp>  （ </rp> <rt>  PR </rt> <rp>  ） </rp></ruby>分成<ruby> 拥有者 <rp>  （ </rp> <rt>  Owner </rt> <rp>  ） </rp></ruby>、<ruby> 协作者 <rp>  （ </rp> <rt>  Collaborator </rt> <rp>  ） </rp></ruby>或<ruby> 社区 <rp>  （ </rp> <rt>  Community </rt></ruby>三类。然而这有一些问题，正如在评论中指出的那样，有几个人并非微软雇员，但是由于其在某个项目上的积极贡献也被列为了协作者，比如 [@kangaroo](https://github.com/kangaroo) 和 [@benpye](https://github.com/benpye/)。


为了解决这个问题，我决定分成两类：


* **微软**
* **社区**


这是可行的，因为（基本上）所有的微软雇员都会在其 GitHub 个人页面上标记其为微软雇员，比如：


![David Fowler Profile](/data/attachment/album/201601/23/004423aqme511le9eaab1f.png)


这种情况有一些例外，比如 [@shanselman](https://github.com/shanselman) 显然是在微软工作，不过这种情况很好解决。


### 结果


在结束了所有分析之后，我得到了结果。总的来说，超过 60% 的“<ruby> 发现的问题 <rp>  （ </rp> <rt>  Issues Created </rt> <rp>  ） </rp></ruby>”和 33% 的“<ruby> 合并的 PR <rp>  （ </rp> <rt>  Merged Pull Requests </rt> <rp>  ） </rp></ruby>”来自社区。然而，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](https://github.com/aspnet/KestrelHttpServer) 项目，因为它是一个有趣的例子。当前它的第一号贡献者 [Ben Adams](https://twitter.com/ben_a_adams/status/684503094810525696/photo/1) 并非微软雇员，他为[改善其内存使用](http://www.hanselman.com/blog/WhenDidWeStopCaringAboutMemoryManagement.aspx)做出了很大的贡献，让 Kestrel 可以每秒钟接受更多的请求。


通过观察随时间推移的变化，可以很清楚的看到社区（浅色条）在过去两年（2013/11 - 2015/12）来的参与情况，看起来并不像是趋于停止。


**每月发现的问题数 - 按提交者**


[![每月问题数 - 按提交者（微软或社区）](/data/attachment/album/201601/23/004424l2nqa6c4qqhz6h6z.png)](https://cloud.githubusercontent.com/assets/157298/12142495/6f746e92-b470-11e5-97fd-bf0d59a74875.png)


此外，虽然社区参与情况可以很容易地从每月发现的问题数上看出来，不过从合并的 PR 数上也可以再次印证这两年来的趋势。


**每月合并的 PR 数 - 按提交者**


[![每月合并 PR 数 - 按提交者（微软或社区）](/data/attachment/album/201601/23/004424gfnvffjnru3tn3r7.png)](https://cloud.githubusercontent.com/assets/157298/12142522/9f72726a-b470-11e5-8333-aec772ff9f6b.png)


 


**贡献总数**


每个项目的贡献人数也很有意思。通过这个你可以看到社区贡献者的实际规模，并不是少量的人做了大量的工作，而是这些工作由大量的人分散完成的。


这个表格展示了每个项目中发现问题和提交了被合并的 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 仓库：


* [**microsoft/visualfsharp**](http://mattwarren.github.io/2016/01/15/open-source-net-1-year-later-now-with-aspnet/github.com/microsoft/visualfsharp)
* [**fsharp/fsharp**](https://github.com/fsharp/fsharp)


按 Isaac 的解释，他们之间的关系是：



> 
> ... visualfsharp 是微软自己的 Visual F# 版本仓库。而另外一个是社区管理的一个。前一个是直接作为 Visual Studio 其中的 Visual F# 工具；而后一个则是类似 Xamarin 的东西。这里有个（稍微过时的）[解析它们关系的图表](http://fsharp.github.io/2014/06/18/fsharp-contributions.html)，以及另外一个有用的资源：<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 开发人员很喜欢他们做的事情，体现了可观的社区响应。

