在前一篇文章中，我们了解了微软在开源了 .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）

合并的 PR（2013/11 - 2015/12）

备注：我包括了 Kestrel Http Server 项目，因为它是一个有趣的例子。当前它的第一号贡献者 Ben Adams 并非微软雇员，他为改善其内存使用做出了很大的贡献，让 Kestrel 可以每秒钟接受更多的请求。

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

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

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

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

贡献总数

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

这个表格展示了每个项目中发现问题和提交了被合并的 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 - 发现的问题（2010/12 - 2015/12）

FSharp - 合并的 PR（2011/5 - 2015/12）

结论

我认为，公平地说社区已经对微软越来越多地开源其代码的动作做出了回应。在几个项目上社区花费了大量时间，做出了显著的贡献。虽然你可以说微软也花费了大量的时间来开源，但是看起来 .NET 开发人员很喜欢他们做的事情，体现了可观的社区响应。

在开源和 Linux 方面，2015年的微软有许多惊人的举动！让我们来盘点一下这一年来微软都做了些什么。

• 微软在其 Edge 浏览器中支持了 VP9 解码器，这是 Google 推出的免费视频解码器
• 在浏览器前端，微软宣布他们将开源其名为 Chakra 的 JavaScript 引擎
• 微软会通过 PowerShell 支持 OpenSSH。为了在 Windows 上更好地支持 OpenSSH，微软还捐赠了 OpenBSD
• 微软开源了其 .NET 的主要部分，将 .NET 带到了 Linux 和 BSD 上
• MS Build Engine 也开源了
• 微软发布了其第一个 Linux 发行版 Azure Cloud Switch，它运行在他们的 SDN 数据中心内
• 作为其 Azure 战略的一部分，微软继续为 Linux 贡献 Hyper-V 代码
• Visual Studio 2015 支持构建 Linux 平台上的应用，虽然现在还不能在 Linux 系统上运行 VS2015
• 不过其集成开发环境 Visual Studio Code 支持运行在 Linux 上 ，而且开源了
• 微软在 Clang 编译器上做了很多工作，他们对 Clang 做了改进、开源了其调试引擎
• 和 Clang 方面的工作相关，微软开始开发一个称之为 LLILC 的基于 LLVM 的 .NET 编译器，这个新的编译器的进展很快
• 开发了 Android 上的 Office 软件，为手机/平板提供了微软 Office 套件的基本功能
• 以上这些都放在了 GitHub 上，而不是他们自己的 CodePlex 上
• 此外，微软开放技术公司被合并回了微软公司

这一年对于微软来说是不寻常的一年，不管你喜欢不喜欢微软，都让我们对这个 Windows 的缔造者在开源和 Linux 方面 2016 年的表现拭目以待吧！

大约一年前，微软宣布开源了 .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!! ）

微软于今日（2015/5/20）宣布了针对 .NET Core 的重大开源：WCF（Windows Communication Foundation）。

如MSDN中的描述:“WCF是一个构建面向服务应用的框架。使用WCF，你可以从一个服务终端给另一个发送异步消息。服务终端可以是托管在IIS中连续可用的服务的一部分，也可以是托管在某个程序上的服务。服务终端可以是请求服务端数据的客户端。消息可以是一个字符或者XML，也可以是复杂的二进制流。”

它的代码放在GitHub，“包含了Window桌面中完整WCF框架的一部分，它支持已经可用于构建Window Store上的WCF应用的库。这些主要是基于客户端，方便移动设备和中间层服务器使用WCF进行通信。”

更多的关于微软开源 WCF 的细节查看dotNETFoundation.org blog的公告。

WCF听上去有点像Linux中用于进程/服务之间的进程间通讯的D-BUS。

via: http://www.phoronix.com/scan.php?page=news_item&px=Microsoft-Open-Source-WCF

作者：Michael Larabel 译者：geekpi 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

微软令人意外地发布了Visual Studio Code，并支持主要的桌面平台，当然包括linux。如果你是一名需要在ubuntu工作的web开发人员，你可以非常轻松的安装Visual Studio Code。

我将要使用Ubuntu Make来安装Visual Studio Code。Ubuntu Make，就是以前的Ubuntu开发者工具中心，是一个命令行工具，帮助用户快速安装各种开发工具、语言和IDE。也可以使用Ubuntu Make轻松安装Android Studio 和其他IDE，如Eclipse。本文将展示如何在Ubuntu中使用Ubuntu Make安装Visual Studio Code。（译注：也可以直接去微软官网下载安装包）

安装微软Visual Studio Code

开始之前，首先需要安装Ubuntu Make。虽然Ubuntu Make存在Ubuntu15.04官方库中，但是需要Ubuntu Make 0.7以上版本才能安装Visual Studio。所以，需要通过官方PPA更新到最新的Ubuntu Make。此PPA支持Ubuntu 14.04, 14.10 和 15.04。

注意，仅支持64位版本。

打开终端，使用下列命令，通过官方PPA来安装Ubuntu Make：

sudo add-apt-repository ppa:ubuntu-desktop/ubuntu-make
sudo apt-get update
sudo apt-get install ubuntu-make

安装Ubuntu Make完后，接着使用下列命令安装Visual Studio Code：

umake web visual-studio-code

安装过程中，将会询问安装路径，如下图：

在抛出一堆要求和条件后，它会询问你是否确认安装Visual Studio Code。输入‘a’来确定：

确定之后，安装程序会开始下载并安装。安装完成后，你可以发现Visual Studio Code 图标已经出现在了Unity启动器上。点击图标开始运行！下图是Ubuntu 15.04 Unity的截图：

卸载Visual Studio Code

卸载Visual Studio Code，同样使用Ubuntu Make命令。如下：

umake web visual-studio-code --remove

如果你不打算使用Ubuntu Make，也可以通过微软官方下载安装文件。

• 下载Visual Studio Code Linux版

怎样！是不是超级简单就可以安装Visual Studio Code，这都归功于Ubuntu Make。我希望这篇文章能帮助到你。如果您有任何问题或建议，欢迎给我留言。

via: http://itsfoss.com/install-visual-studio-code-ubuntu/

作者：Abhishek 译者：Vic020/VicYu 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

微软IE即将寿终正寝。一系列的浏览器技术改进、一系列的广告营销活动，一切都未能挽救已有20多年历史的IE的命运。运行卡顿、网页显示Bug多多、进程不时崩溃，IE的负面形象已成为微软背负的枷锁。不堪重负的微软终于决定，放弃这一伴随许多年轻人长大的浏览器品牌。

对于IE自身存在的问题，业内已有许多讨论。确实，IE需要承担得太多。为了兼容性，微软需要让IE去支持互联网发展早期的许多网页技术。原因很简单：很多企业内网中仍有不少基于过时技术开发的服务，而说服这些企业投资升级这些服务，使其支持最新的网页技术，这难度很大。而为了确保后向兼容，IE只能变得更复杂，当然也就更容易出现问题。

技术只是因素之一，而导致IE最终无法跟上网页技术的发展潮流，原因更多地在于微软的策略问题。

IE诞生于互联网发展的早期。彼时，网页浏览器的开发成本很高，软件公司需要自行开发浏览器内核和脚本引擎，同时也要自行设计各种人机互动功能和界面。这样的工作非微软和网景等大公司无以完成。在90年代与网景的撕逼战中，IE是最终胜出者。这意味着，IE所采用的一系列微软私有技术都获得了温和的生存土壤，而微软可以优哉游哉地慢慢改进浏览器技术，享受着垄断（或者更委婉的说法，“市场主导地位”）带来的红利。

与其他任何垄断一样，IE的创新速度非常缓慢。毕竟，在“创新者困境”中，没有任何领先的公司会去主动变革自己。2005年左右，继承自网景的火狐浏览器开始与微软展开新一轮争夺。微软面对这一竞争仍然游刃有余，牢牢把握着主流用户群体，将火狐压缩在极客和技术工作者这一市场。不过，火狐赖以成功的重要因素：开源，正是IE随后逐渐失去竞争优势的一半原因。

那么另一半原因是什么？简单地说，这就是其他巨头的到来。行业巨头+开源模式，这带来了另一种“市场主导地位”。

谷歌于2008年推出了Chrome浏览器。从一开始，Chrome浏览器就基于开源的WebKit引擎。随后，谷歌对浏览器的优化也包括对WebKit引擎的优化。在谷歌的大力投资之下，变得更好的不只是Chrome浏览器，也包括了WebKit。

随着开源的浏览器内核、JavaScript引擎，以及其他浏览器模块的发展，当代浏览器的开发呈现出模块化的趋势。这意味着，只要遵守开源协议，任何开发者都可以使用这些模块。开发者甚至只需设计自己的界面和标志，并拿出一些独创的小功能，即可推出一款新的浏览器产品。

在这样的情况下，浏览器开发的时间周期从90年代的按年计算下降至目前的按月计算，甚至按天计算。而对于浏览器基本的功能和性能，例如网页渲染速度和JavaScript脚本运行速度，开发者毫无疑问会倾向于选择市面上最优秀的产品。在这种情况下，WebKit成为了当然的选择。

大大小小的软件公司和互联网公司也有动机去开发自主品牌浏览器。浏览器是普通用户的上网入口，可以衍生出多种商业模式，并带来不菲的收益。例如，浏览器的默认登录页面可以提供上网导航服务，而默认搜索引擎既可以推动自主搜索引擎产品的发展，也可以通过为主流搜索引擎导入流量来获得收入。实际上，浏览器是互联网生态系统的重要一环。

市场环境如此，而谷歌不失时机地投资WebKit恰好满足了市场需求。开源的WebKit聚集了一批浏览器开发商。例如，国内常见的360、搜狗和遨游等浏览器都集成了WebKit内核。而在国外，Opera也于2013年放弃了自主内核，倒向了WebKit阵营。通过控制浏览器内核，谷歌实际上已经主导了当代浏览器技术的发展。

近期美国科技圈的一种论调是，谷歌正在成为新的微软。但同样是“市场主导地位”，谷歌的做法要比微软高出几个段位。浏览器内核开发耗费的时间、精力和资金巨大，因此即使已经开源，独立开发者和小公司仍然很难对这样的产品做出突破。通过这种开源产品去主导市场，充分调动市场各方的参与热情为己所用，远比通过私有技术去主导市场更高明。

毫无疑问谷歌已经谙熟此道，而移动操作系统市场的Android就是另一个很好的案例。微软正在开发新的浏览器Project Spartan。而在缺乏生态圈配合的情况下，这款浏览器能取得什么样的成绩仍值得怀疑。或许，这款浏览器未来的命运可能会类似叫好不叫座的Windows Phone，在Android的重压下步履艰难。