微軟開源 .NET 一年后……
大約一年前，微軟宣布開源了 .NET 框架的大部分。當時，Scott Hanselman 使用微軟 Power BI 對代碼庫做了一個漂亮的分析。 現在一年過去了，我想要試試對以下問題做個解答：
微軟開源了 .NET 框架的大部分之后，社區參與貢獻了多少？
</blockquote>我著眼于以下三個項目做了分析，它們是 .NET 生態系統中最主要部分之一，也是 .NET 基金會內 最活躍/收藏/分支的項目之一：
- Roslyn – .NET 編譯器平臺，提供了開源的 C# 和 Visual Basic 編譯器，以及豐富的代碼分析 API。
- CoreCLR – .NET Core 運行時環境和底層庫（mscorlib），它包括垃圾回收、JIT 編譯器、基本的 .NET 數據類型和許多底層類。
- CoreFX – .NET Core 基礎庫，包括 collections、文件系統、console、XML、異步以及其它方面的類。
</ul>數據來自哪里？
GitHub 自身已經內建了很多漂亮的圖表了，你可以看看這一年來每月提交數的圖表：
Commits Per Month
還可以看看每月動態：
github stats - monthly pulse
但是要回答上面的問題，我需要更多的數據。幸運的是， GitHub 提供了非常全面的 API， 再配合上出色的 Octokit.net 庫以及 brilliant LINQPad，我就很容易的得到了我所需的全部數據。如果你想要自己試試這些 API ，這兒有個示例的 LINQPad 腳本。
然而，僅僅知道它的每月 “問題數量” 或 “接受的PR（ 拉取請求）”并沒有太大用處，這并不能告訴我們是誰提交了這些問題或 PR。 幸運的是， GitHub 典型的用戶是有分類的，比如下圖來自 Roslyn 第 670 號問題 ，我們可以看到是哪種類型的用戶提交的備注：“擁有者”、 “協作者” 或者為空——這就是“社區”成員，比如下面的某人（我覺得）并沒有在微軟工作。
owner collaborator or community
結果呢？
現在我們可以得到我們所需的數據，也就可以生成結果了。
全部問題 - 按提交者分組
項目 擁有者 協作者 社區 全部 </tr> </thead>Roslyn 481 1867 1596 3944 </tr>CoreCLR 86 298 487 871 </tr>CoreFX 334 911 735 1980 </tr></tr> 全部 901 3076 2818 </tr> </tbody> </table> 這里你可以看到擁有者和協作者在某些情況下占有主導地位，比如，在 Roslyn 項目中 60% 的問題是他們匯報的。但是在另外的例子中社區非常活躍，特別是在 CoreCLR 項目中社區成員匯報的問題超過了擁有者/協作者之和。造成這種情況的部分原因是項目的不同， CoreCLR 是 .NET 框架中最引人注目的部分，因為它包含了 .NET 開發者日常使用的大部分庫，所以并不用對社區提交了很多改進建議和錯誤修復的事情感到驚奇。 另外， CoreCLR 已經出現了較長時間，社區已經使用了一段時間，也能找到它的一些不足的部分。而 Roslyn 則相對較新一些，還沒有被太多的使用過，而且找到一個編譯器的 bug 顯然會更難。
全部已接受的 PR - 按提交者分組
項目 擁有者 協作者 社區 全部 </tr> </thead>Roslyn 465 2093 118 2676 </tr>CoreCLR 378 567 201 1146 </tr>CoreFX 516 1409 464 2389 </tr></tr> 全部 1359 4069 783 </tr> </tbody> </table> 但是，如果我們來看一下已接受的 PR ，可以看到在這三個項目中社區的貢獻量非常低，僅僅只有 12% 左右。不過，這并不令人吃驚，因為 PR 需要達到相當高的水準才能被接受。如果項目采用這種機制，首先你必須找到一個 “需要解決”的問題，然后如果你要改變 API 就必須通過代碼審查，最后你必須在代碼審查中符合可比性/性能提升/正確性等。所以，實際上 12% 是個相當不錯的結果，接受的 PR 解決了不少的問題，特別是考慮到大部分貢獻都是社區成員在工作之余完成的。
更新：關于對“需要解決”的要求，參見 David Kean 的這個評論，以及這條推來了解更多信息。“需要解決”是一個準則，旨在幫助新手，但是并不是必需的，你可以提交一個解決問題的 PR 而不打上這個標簽。
最后，如果你看一下每月的數量（參見下面的兩張圖，點擊放大），很難找到特定的趨勢，或者說，社區肯定會隨著時間的變化或多或少的做出貢獻。不過， 你也可以說，過去一年來社區一直在做貢獻，而且看起來還會繼續貢獻下去。這不是僅僅出現在項目剛剛開源后的一次性噴發，而是一整年以來的貢獻的持續水平。
每月的問題數 - 按提交者分組
Issues Per Month - By Submitter (Owner, Collaborator or Community)
每月接受的 PR - 按提交者分組
Merged Pull Requests Per Month - By Submitter (Owner, Collaborator or Community)
前 20 的問題標簽
最后一件我想對我擁有的這些數據所做的事情是找到那些最流行的問題標簽，這可以揭示從三個項目開源以來哪種類型的工作不斷出現。
Top 20 Issue Labels
以下是關于這些結果的一些看法：
- 列表中 CodeGen 排名如此之高沒有什么好驚奇的，下一代的 .NET JIT 編譯器 RyuJIT 才發布了僅僅兩年而已。然而如此多的問題還是讓人有一點點擔心，特別是考慮到它們中的一些會帶來嚴重的后果，就如 Stack Overflow 的開發人員發現的那樣！題外話，如果你想要了解 JIT 的許多底層細節，可以看看 @MikeDN 評論過的這個問題，令人難以置信的是，有些掌握了很多知識的人卻自己并不從事這方面工作，甚至是微軟的另外團隊的！
- 這三個項目都有許多“需要解決”的問題： Roslyn、 CoreCLR 和 CoreFX，而且社區似乎也在添加需要解決的問題！
- 最后，我很高興的看到 性能 和 優化 日益得到了重視，畢竟性能是王道！
</ul> 參考原文：http://mattwarren.org/2015/12/08/open-source-net-1-year-later/ 作者： matt
編譯文章：LCTT https://linux.cn/article-6727-1.html 譯者： wxy本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！相關資訊
sesese色