【編者按】從閉源走向開源，.NET 背后都發生了哪些有趣的故事。本文采訪了 6 位微軟 .NET 團隊成員，分享他們在 GitHub 以及建立 .NET 開源項目的經歷。

作者 | Richard Lander? ? ? ?

譯者?| 彎月

出品 | CSDN（ID：CSDNnews）

當第一次考慮在 GitHub 上共享 .NET Core 時，我們覺得開源是一個富有吸引力且令人興奮的想法。同時，我們很多人都不太了解 GitHub，只知道這是一個很大的平臺，至于如何利用這個平臺，我們都有很多疑問?！叭绻谝惶炀陀腥嗽谖覀兊倪\行時上建立分叉，該怎么辦？是不是說我們的項目就完了？”我們知道應該虛心學習開發人員建立的模式，并了解他們對我們的期望。話雖如此，我們還是建立了項目和組織，而且項目的發展速度超出了我們的預期。截止到目前，我們已經度過了數個春秋，而且已經擁有了多個版本，而其他的都已成為歷史。這是一段有趣的旅程，我們將與各方工作人員一起分享。

此次，我們將通過談話的形式，與以下幾位 .NET 工程師一起分享他們嘗試 GitHub 以及建立 .NET 開源項目的經歷。

• Claire Novotny：.NET 基金會執行董事，?.NET 團隊的 PM

• Dan Moseley：.NET 庫團隊的項目經理

• Immo Landswerth：.NET 團隊的項目經理

• Kevin Pilch：ASP.NET Core、Entity Framework 和 Winforms 的工程經理

• Matt Mitchell：.NET 工程師
  

• Stephen Toub：.NET?工程師

Q：為什么開源對 .NET 項目如此重要？

Immo：現代開發技術棧需要跨平臺。在操作系統和架構不斷變化的大環境中，開源是最具可持續性的、構建一個擁有廣泛支持的技術棧的方式。我們可以通過開源與消費者實時互動，而這從很多方面改變了我們計劃、構建和迭代 .NET 的方式。最后，人們都希望開發技術棧這類的基礎技術能夠在開源許可下開放。

Claire：開源之后，任何人都可以查看和調試用于構建應用程序的運行時，甚至為之做貢獻。以前有些問題對他們來說很重要，但不會被優先考慮，而如今他們可以自行解決這些難題了。開源之后， .NET 項目已不再由微軟一家提供。

Kevin：我認為開源對 .NET很重要，原因如下：

• 開源語言和運行時的實現很常見，所以如果不開源的話，倒顯得我們格格不入。

• .NET 涉及的范圍很廣，盡管我們盡了最大的努力來編寫文檔，但還不如讓人們來親眼看一看這些實現，甚至動手調試。

• 我們可以通過開源，與個人和其他公司展開合作，這種合作比在閉源系統上進行的一次性協議更直接。

Stephen：原因有很多，但最讓我心動的是任何人都可以找到對他們很重要的東西，并加以改進。在 .NET Core 出現之前，任何改進請求都要與其他請求一起經過整理和分類后，才會到達合適的微軟工作人員手中，然后再安排開發人員處理改進要求，可能需要經過幾年的時間才能發布出來。如今，如果有人發現希望修復的問題，他們只需提出 PR，然后經過審查、迭代、合并，通過每晚的構建，第二天就可以上線了。這是一個完全不同的世界。

Dan：開源是實現跨平臺的最佳方式，尤其在面向 Linux 時，開源是最自然的做法。

Matt：我認為，微軟必須通過某種方式表現對開源軟件社區的投入，這一點很重要。我們采用了開源軟件的開發方式，并將開源作為產品的一部分發布出去。如今，開源軟件是整個軟件生態系統的重要組成部分。微軟的參與和回饋也非常重要。

Dan：由于有更多的人關注我們的工作，因此可以幫助我們在產品發布之前確保產品的正確性。此外，社區的規模意味著其中有許多來自各個領域的專家，其規模遠遠超過了我們的工程團隊，這也可以幫助我們更好地完成工作。

Q：.NET團隊直接在 GitHub 上開展工作，是嗎？早先有一些代碼炸彈（JIT 和 GC）。現在沒有了，是嗎？

Immo：只有 StephenToub 長期休假就沒問題。

Matt：我們幾乎全部轉移到了GitHub 上。安全補丁的確會先在代碼庫中構建，但等到代碼發布的時候就會合并到開源庫中。除此之外，我們的開發、討論和議題跟蹤幾乎都在 GitHub 上。

Stephen：如今代碼炸彈已經很罕見了。有時，有一些額外的已有組件會被移動到 dotnet/* 代碼庫中，但是這種情況很少見。我能想到的過去一年中出現此類情況是一個名叫 System.Speech 的庫。

Kevin：實際上，我認為我有最大的一個代碼炸彈，因為向 roslyn 項目提交代碼的第一個人是我（當初我們還沒有使用機器人來完成此類工作）。如今我們的大部分工作都是直接在 GitHub 上進行的，而且你可以看到這個過程是逐步建立的。但也有可能我們決定發布一些新項目的代碼，或者在我們決定是否開源之前先在原型上進行試驗。

Dan：我們十分關心公開我們的工作，除了作為一種承諾之外，還能讓更多人關注我們的工作。所以一般來說，開發重大的非公開項目有違于微軟的慣例。

Q：分享一個有關 .NET Core 1.0 開源項目的故事

Kevin：在 .NET Core1.0 開發期間，我一直在研究 Roslyn，但讓我們非常高興的一件事是，當 Anders 宣布編譯器發布到了 CodePlex 上之后，我們與運維人員一起觀看服務器上的負載增加狀況。幸運的是，負載一直保持不變，但如果我沒記錯的話，那是他們迄今為止看到過的最高的負載。

Immo：我們創建了一個 .NET 專用賬號（dotnet bot），而且這個賬號還成了第一批代碼的提交者。我們之所以這樣做，是為了表明所有這些提交都是已有的代碼，而不是由某個人編寫的。可以想象，第一批提交包含大量的代碼。時至今日，dotnet bot 收到了大量工作邀請函，因為有人透過 GitHub 的統計數據挖掘到了 dotnet bot。

Stephen：多年前，我在從倫敦起飛的飛機上編寫了一個數獨應用，用于生成游戲和玩游戲。這個應用成為了我嘗試新平臺的媒介，最初是在 Windows Forms 上編寫的。后來，我把它移植到了 WPF。后來在研究并行計算時，我利用這個應用來演示并行計算。等到 Windows 8 發布以后，我將其移植到了 WinRT。后來，我們發布了平板設備，我又一次將其移植了上去。而等到我們在 Linux 上啟動 .NET Core 后，這個應用是除了“Hello, world”之外，在 .NET Core 上運行的第一批 Linux 應用之一（移植后的版本提供了文本界面）。

Matt：早先時候，我們的公共 CI 系統采用了 Jenkins。我們不知道應該使用哪種工具。我們采用了一個舊版的 Jenkins 單體版本，而且它的設計并不適合處理我們的規模（數以萬計的作業，需要大量的編排）。好在一切還算順利，但是很難管理穩定的安裝版本。最終，我們不得不創建了一個又一個越來越大的虛擬機，而且占據的內存也越來越大（數百 GB），但我們仍然需要有人時刻監視，一旦系統崩潰，就按下重啟鍵。

Dan：社區的參與度和專業知識總是讓我感到驚喜。此次開源在很大程度上是一種合作伙伴關系，令人欣慰的是，如此之多的開發人員對 .NET 充滿熱情，他們貢獻的功能和變更如此重要，可以讓 .NET 變得越來越好。

Q：.NET開源項目最令人驚訝的是什么？

Immo：多年來我們一直在談論開源。我非常驚訝的是我們的心態轉變速度之快：前一天我們還在擔心，結果沒過幾天就完全變了：“為什么還沒完成”。整個團隊的文化都發生了變化。從使用 TF VC 的內部 TFS 轉變到使用 Git 的 GitHub，并公開開發工作，我們幾乎只用了幾周的時間。我很震驚，也很自豪能夠成為一支適應速度如此之快、幾乎沒有任何猶豫的團隊的一員。

Kevin：雖然在微軟從事了七年的開源技術工作，.NET 開源的一切在我眼里都很正常，但我仍然對這份工作感到興奮。如果回到 2002年，我很難想象這樣的事情。

Matt：這個項目的發展速度總是讓我感到驚訝，而且如今似乎還在不斷加速。以前，我總是能夠清楚地記住當前正在進行的一系列工作，各個代碼庫的狀況以及它們之間的關系。然而在過去的一年里，我經常會恍惚：“等等，我們現在就要做嗎？”但話說回來，可能只是因為我上了年紀。

Dan：自從 .NET 開源以來，內部團隊已經聯系了我們很多次，希望我們能夠幫助和指導開源他們的項目。而他們又會成為微軟其他團隊的榜樣。令我驚訝的是，人們對我們公開自己的工作非常感興趣，他們希望能夠從我們身上汲取經驗。

Immo：我沒有預料到的一件事是，在與合作伙伴團隊的內部互動中，開源竟然起到了如此大的作用?；叵肫饋?#xff0c;這也不是很意外。微軟是一家大公司，擁有各種各樣的工程系統、發布周期和業務目標。我們希望團隊之外的人員也能夠接觸我們的代碼庫，包括微軟的不同團隊，而在開源的幫助下，這個問題非常容易解決。

Q：.NET開源項目似乎非常受歡迎，而且非?；钴S。你覺得是什么原因？?

Immo：.NET 以高效著稱，尤其是與 C# 結合使用。在開源之前，我聽很多人說，有些人堅持認為“微軟非常邪惡”，雖然 C# 非常棒，但他們仍然拒絕使用 C#，因為它是閉源的，并且只支持 Windows。開源之后，很多人終于有機會在項目中使用了 C#了，即便他們的工作根本不涉及 Windows。

Kevin：我認為這在一定程度上表明 .NET 已深入客戶的日常工作。他們每天都會用到. NET，因此能夠讓工程師和客戶直接接觸我們的項目是非常有價值的。團隊中還有很多人在思考如何與社區展開合作，以及如何讓我們的開源軟件更具包容性，更容易接納別人。在這個問題上，我們都要感謝 Dan 付出的努力。

Matt：多年以來，.NET 的“核心”已得到鞏固。如今，我們有機會進一步擴展，并嘗試新事物和創新。與早些年相比，我們的工程系統越來越好，而我們的發展速度也越來越快。

Stephen：C# 是一門非常容易上手且發展成熟的語言，.NET 的庫非常健壯且龐大，運行時堅如磐石。你可以編寫非常高效且可擴展的應用和服務，而且編寫這種代碼的效率非常高

Claire：在我看來，C#、.NET 和 Visual Studio 一直都是值得信賴的平臺。我可以快速投入工作，快速地編寫代碼，然后開始調試，而無需考慮類路徑等復雜的配置，或手動指定垃圾收集器的設置。

Dan：.NET 開發人員的群體非常龐大，而且由于大多數 .NET 平臺是用 C# 編寫的，因此向這個項目做貢獻相對比較容易，而且很容易出成果。通過開源，我們與所有開發人員建立了聯系，而不僅僅是 Windows 開發人員，無論你使用何種平臺，都可以考慮 .NET。

Q：在你看來，人們對這個項目滿意嗎？開源是明智之舉嗎？

Immo：根據我與 .NET 開源社區其他成員的交談，感覺我們做了許多正確的事情。特別是在剛開始的時候，我們告訴所有人，我們可能會犯錯，我們非常期待誠懇的反饋。我認為，這件事奠定了社區參與的基調。盡管如此，我們也明白，取得開源的成功并不是目標，而是過程。還有許多東西值得我們從其他社區學習。

Dan：從 GitHub 社區的調查問卷中我們了解到，大多數情況下人們都很高興。不同的代碼庫的結果也不一樣，也有許多我們需要改進的地方，我們應當更積極、更加透明地響應，降低貢獻代碼的難度。我們可以學習一些成功的開源項目。我們已取得了進步，但前面還有很長的路要走。

Matt：我認為核心開發人員對 .NET 開源項目基本滿意。至少，我沒有看到任何開源的反對意見。從 .NET 組織的文化來看，這種情況非常自然，也是我們的目標?，F在的反對意見主要集中在如何提高各個部分的工作效率。怎樣才能更好地管理議題？PR 的測試標準是什么？

Kevin：我認為我們一直在嘗試改進。總會有人因為他們的問題沒有得到解決而不滿，但目前來看，在我們的代碼庫中進行構建、調試并運行測試并非易事。有時候，就問題能否解決、何時解決，我們并沒有管理好人們的期望。因此，我認為我們做得還不錯，但依然有可以改進的地方。

Dan：舉一些我們讓 .NET 變得更加包容的例子：我們在Github上公開了 .NET 6 的計劃，并在Github 上管理該計劃；我們還積極利用 dotnet/designs 代碼庫，這樣社區就可以幫忙分享和改進我們的設計和計劃。

Q：項目的維護人員經常討論超負荷的問題，他們都是在業余時間維護開源項目。但 .NET 開源項目是你們的本職工作，所以你們的感受可能不一樣。你們經歷的最大難題是什么？

Dan：由于代碼庫一直都非常活躍，我們不得不放棄事必躬親的想法，也不能逼迫自己在業余時間隨時做出響應。相反，對于喜歡靈活工作的人，這種情況反而很好，例如，無論何時都會有人執行代碼審查。

Kevin：對于我來說，關注一切會讓人感覺不堪重負。我管理的幾個代碼庫每個月都有幾百甚至幾千個議題，更不用說 PR 和評論了。就算是全職工作，給予一切方面應有的關注，時間也遠遠不夠。我看到有人通過延長自己的工作時間來解決這個問題，但最終還是會面臨精力耗盡的局面。

Stephen：我的時間根本不夠，無法完成所有的工作。例如，我很希望能審查 dotnet/runtime 中的大部分PR，但量太大，最后我只能優先處理一部分。

Matt：挑戰之一就是避免讓自己成為救火隊員。由于 .NET 的發展速度非?？?#xff0c;光是回復 PR 審查請求、幫助受阻的開發人員或修改基礎設施的錯誤，就占據了我所有的時間。困難就在于專心解決根本問題，并從戰略層面上思考怎樣解決一類問題，而不是一整天都為個人服務。

Dan：團隊中有許多人非常善于保持工作的邊界。我們認為這樣完全沒問題，甚至可以說這是最理想的做法。

提交者人數是固定的，但潛在的貢獻者是無限的。因此，我們不可能關注所有的議題和 PR 審查。我們會盡可能關注一切，但同時也會嘗試找出一個正確的模型來管理這項工作。我們希望社區能幫我們解決這個問題。

Claire：由于項目是全球性的，貢獻者也來自五湖四海，因此新的議題永無止境。工作之外的時間里，我會想盡各種“請勿打擾”的方法，來保持工作和生活的平衡。

Q：很顯然，該項目的開源已經遠遠超出了授權的范圍，其中社區的因素更多。團隊為了提高社區參與度做了哪些努力？

Clarie：我們一直在努力確保團隊與社區的友好交流，讓每個人都能參與進來。

Dan：有很多例子。我們主導了“社區分類”行動，好幾個代碼庫都由社區成員負責給議題添加標簽，或者關閉重復的議題。在代碼方面，有時我們會讓社區貢獻者參加我們的每日會議。去年我們在網絡性能問題上也嘗試過同樣的實踐，而且非常成功。只要有可能，只要社區成員愿意實現某個功能，我們非常愿意放手。例如，Web 套接字壓縮和 PriorityQueue 就是這樣實現的。

Kevin：Dan 等人的調查已經持續了一段時間，我們在嘗試從調查中汲取經驗。如上所述，我們在努力給議題的狀態設置更為清晰的期望，方便大家訪問代碼庫，降低構建的難度，確保社區PR得到更快的審查，等等。

Immo：以前，我們曾嘗試過“代碼開放”，就是將代碼扔給開源社區，而我們躲在門后繼續制造代碼炸彈。從 .NET Core1.0 開始，我們的工作全部轉移到了 GitHub 上。這樣人們就可以看到團隊的代碼審查，也能看到問題的跟蹤。我們中的許多人都加入了社交網絡，更積極地宣傳 .NET 和我們的 GitHub 項目。我們還在 YouTube 上直播了設計討論會議?，F在我們有好幾個網站可以與社區分享更多信息，比如issuesof.net、apisof.net、apireview.net和 themesof.net 等。

Matt：在基礎設施方面，我們的理念一直是為微軟之外的 .NET 貢獻者提供與微軟開發人員相同的工具和流程，以及同樣的 PR 檢查工具，并公開檢查結果，同樣的編程工具，等等。

Dan：補充一句，這樣做也為團隊中不在辦公室辦公的成員提供了方便，他們不需要VPN就能工作。

Q：想象一下，你決定跳槽到一個新項目（或工作）。開源會成為你的選擇標準之一嗎？在你看來，開源有多重要？

Stephen：這個想法太悲觀了，我為什么要跳槽？但是，沒錯，開源非常重要。

Dan：縱觀整個職業生涯，我一直在從事閉源項目，直到遇到 .NET。如今的我無法想象在一個非開源或注定會開源的項目上工作。開源的工作更有意思，我們能獲得更多的能量，接觸到更多的觀點，而且還可以認識更多人。而且開源非常高效。

Claire：能夠參加開源項目，并為開源做出貢獻，對我來說非常重要。能夠與社區互動、獲取新想法的反饋，并公開迭代過程，這一點至關重要。

Immo：作為項目經理，我非常重視與客戶實時互動的能力，包括讓他們直接接觸工程團隊的工作成果。我很難接受失去這一切。即便將來離開微軟也沒有關系，因為所有的工作都公開了。

Kevin：我從事開源項目已經七年多了，我從大學開始就想從事開源項目。我很難想象自己加入一個非開源團隊。

Matt：我認為，對我來說開源并不是一個硬性要求。但是某些開源的“思維方式”很重要。例如透明度、多樣性、完整性、社區、公共標準和辯論，還有開源工具，這些對我來說都很重要。

Q：.NET 的采用率會不會因為開源而增加？

Claire：毋庸置疑。在開源之前，.NET 僅限于 Windows。如今 .NET 開源了，可以在更多地方運行了。

Immo：我相信答案是肯定的，但我認為跨平臺支持（包括設備）給 .NET Core 帶來了很多變化。很難說這些成功的主要因素是什么，但我認為開源軟件是我們成功構建 .NET 的關鍵。

Dan：在開源的幫助下，我們更容易地實現了跨平臺，因為我們可以與 Linux 的社區合作。而支持 Linux（以及 Mac）讓我們成為了 Linux 開發人員的備選之一。當然，也有一些開發人員單純因為喜歡開源技術棧。此外，開源還讓人們更容易信賴 .NET，因為每個人都可以閱讀源代碼。

Matt：我覺得應該會。我認為，我們很難將 .NET的采用率與開源直接聯系起來，但我認為在某些方面開源增加了項目的可見性，而且還讓.NET 在原本不可能的地方（例如紅帽）得到了應用。

Q：縱觀歷史，微軟提供的產品主要以閉源為主。長期使用 .NET 的微軟客戶是否愿意接納開源？

Kevin：肯定有一些客戶不太愿意。在我看來，這個問題主要在于支持。雖然大多數人都知道，微軟發布的產品都提供支持，比如 gRPC-dotnet，雖然絕大多數代碼是微軟編寫的，但是實際上該項目由 CNCF 負責，也由他們負責發布。那么，我們提供支持嗎？（答案是這個問題剛剛得到了解決，我們提供支持）。但是我們推薦或貢獻了代碼的第三方庫也經常出現這個問題。

Dan：以前許多 .NET 客戶構建應用都會使用微軟提供的庫（以前都是閉源代碼），再結合自己編寫的代碼，他們不太習慣依賴微軟之外的庫，而這些庫通常是開源的。我們希望讓他們明白，他們也可以信任來自 .NET 團隊之外的庫，而開源更容易讓他們信任這些庫。

Matt：至少在內部，經常有人不太了解開源項目的開發方式，開源項目之間的關系以及開源項目如何才能滿足需求（服務、新功能等）。有時，他們有點不太習慣 .NET 之類的微軟傳統項目中包含微軟以外的開發人員編寫的代碼。但我認為這主要是因為.NET 的發展歷史，而不是他們真的不喜歡開源。

Q：介紹一下微軟對開源的承諾

Immo：我覺得打從第一天起，我們對此就非常透明。微軟整個公司都在向云遷移。許多微軟的客戶都在使用 .NET，我們認為 .NET 與云計算的結合至關重要。而且我們相信開源是 .NET 向云轉變的最佳方式。

Dan：為了回答這個問題，我們可以看一看近年來發生的事情。微軟維護的開源項目數量持續增長，包括幾個頂流的 Github 代碼庫。這些都是最有力的證據。

Q：.NET項目 與 .NET 基金會有什么關系？

Claire：人們經常將 .NET 項目與 .NET 基金會混為一談。該項目的知識產權歸 .NET 基金會所有，但 .NET 基金會沒有項目控制權。.NET 項目的控制權在微軟手中。作為 .NET 基金會的執行董事和 .NET 團隊的項目經理，我同時擔任兩項職務，我清楚什么場合下應該承擔起哪項職務。我認為，剛開始的時候 .NET 項目和 .NET 基金會之間的界限很模糊，在過去的幾年里，我們一直在努力更清晰地區分二者。

結束語?

在 GitHub 上公開辦公，徹底改變了團隊和產品。雖然我們從事 .NET 的開發已經很多年了，但項目和產品本身仍在不斷增長。這是一個振奮人心且令人滿意的結果。很明顯，開源是開發應用程序平臺的最佳方式，而且也更有趣。感謝所有為該項目做出貢獻的人。

感謝Stephen、Matt、Kevin、Immo、Dan 和 Claire 與我們分享 .NET 開源項目的情況，以及參與其中的感受。

原文鏈接:?https://devblogs.microsoft.com/dotnet/conversation-about-the-net-open-source-project/

聲明：本文由CSDN翻譯，轉載請注明來源。?

總結

以上是生活随笔為你收集整理的.NET基金会讨论 .NET 开源事业之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。