微軟開源 .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