開發(fā)者陣營分化，.NET 開源生態(tài)系統(tǒng)如何走向未來？（net開源項目）
作者 | Aaron Stannard
譯者 | Sambodhi
策劃 | 凌敏
本文深入剖析了 .NET 開發(fā)者對生態(tài)系統(tǒng)的復雜情感。一方面，他們依賴微軟提供的解決方案，認為這最為穩(wěn)妥；另一方面，他們又對第三方工具抱有擔憂，在信任與恐懼之間掙扎。在 .NET 生態(tài)系統(tǒng)中，各種觀點相互碰撞，有的開發(fā)者堅定地支持微軟的首選方案，而有的則強調(diào)多樣性和選擇的重要性。
然而，文章也揭示了單一選擇可能帶來的局限性，以及對第三方工具長期支持和生存能力的疑慮。這讓我們不禁思考，.NET 生態(tài)系統(tǒng)的未來應如何發(fā)展？如何平衡微軟的貢獻與第三方創(chuàng)新之間的關(guān)系，以確保 .NET 能夠持續(xù)進步？這些問題值得我們深入探討。
近日，一則名為 “Epic: Eventing Framework in .NET 9” 的 ASP.NET GitHub 話題在開發(fā)者社區(qū)引起了軒然大波，背后主要原因是微軟在其 .NET 開源生態(tài)系統(tǒng)中展現(xiàn)出的強勢插手態(tài)勢。對于這種現(xiàn)象，如果放在幾年前，我或許還會因此感到憤怒。但如今，這幾乎已經(jīng)成了微軟的慣常做法 —— 對此，我也曾在我的文章中有過類似論述。無論我們怎樣表達憤怒，或是展現(xiàn)開源社區(qū)的精神，似乎都無法撼動微軟那座堅固的象牙塔。要想真正帶來改變，恐怕得從改變對 Azure 的投入開始。
如果你想在 .NET 生態(tài)系統(tǒng)中作為開源項目或工具開發(fā)者參與進來，那么接受這樣的現(xiàn)實或許就是入場的代價。如果你覺得微軟涉足你的領(lǐng)域就意味著要放棄，或者這足以摧毀你的業(yè)務，那么從一開始，或許你就缺乏足夠的創(chuàng)意、決心或熱情。
微軟聲稱他們開發(fā)這個框架主要是為了改進 Azure WebJobs，因此不會對 MassTransit、Wolverine、MediatR 等構(gòu)成真正的威脅。但對此，我持懷疑態(tài)度。如果微軟并不打算讓第三方真正使用它，那又何必將其列為 ASP.NET 的重大工程，更何況 ASP.NET 還是生態(tài)系統(tǒng)中最受歡迎的框架呢？
不過，真正讓我感興趣的并不是這個帖子上開源軟件生產(chǎn)者或微軟的反應，而是 .NET 開源軟件消費者的反應，這實在出乎我的意料。竟然有那么多 .NET 開發(fā)人員歡呼這些流行的第三方框架被摧毀，仿佛擁有多個、維護良好的工具成了一種需要解決的麻煩。
究竟有哪些 .NET 開發(fā)者會要求 .NET 毀掉自己的生態(tài)系統(tǒng)，甚至將 .NET 帶回昔日競爭力不足、智力貧瘠的時代呢？
.NET 開發(fā)者的兩種觀點
在那個帖子中，存在兩種截然不同的 .NET 開發(fā)者群體。
第一種認為供應商多樣化是件好事，他們傾向于擁有多種可行的軟件交付選項，這樣可以根據(jù)自己的需求進行選擇，從而保持生態(tài)系統(tǒng)的健康和競爭力。而第二種觀點則相反，他們認為供應商多樣化并不是好事，主張應該有一個統(tǒng)一的標準來指導我們的工作，包括構(gòu)建復雜的事件驅(qū)動架構(gòu)等任務。他們認為，只要微軟支持這個單一標準，我們就不必擔心其他問題 —— 因為這個標準將比其他任何選擇擁有更完善的文檔、更好的維護和更高的可操作性。他們建議圍繞這個標準整合生態(tài)系統(tǒng)的其他部分。
需要明確的是，這兩種觀點并非同等有效、可以簡單 “同意或不同意” 的。第二種開發(fā)者群體所信奉的這種信念體系，實際上限制了他們的能力和技能，相比第一種開發(fā)者顯得更為不足。這種自我設限的信念，最終可能導致他們成為所謂的 “專家初學者”。
那些認為評估甚至只是擁有工具選項都是浪費時間的人，很可能并不具備構(gòu)建高流量客戶面向的 SaaS 應用、工業(yè)物聯(lián)網(wǎng)、自動交易系統(tǒng)或其他比簡單數(shù)據(jù)表單更復雜項目的能力。我之所以參與 .NET 開源軟件，完全是因為我希望增加能夠利用 .NET 構(gòu)建這些重要系統(tǒng)的開發(fā)者的數(shù)量。
主張摧毀選項并不是我們應當參與的積極討論，因為“讓生態(tài)系統(tǒng)變得更糟、更不具競爭力，以便我無需面對選擇”這種思維過于短視。尤其對于那些從未經(jīng)歷過 .NET Core 之前的 .NET 生態(tài)系統(tǒng)之弊端的開發(fā)者，或是那些“資深”開發(fā)者中未曾關(guān)注過在看似微不足道的應用程序中默默付出的人們，這一點尤為凸顯。
第一類：選項尋求者
競爭是積極的，擁有多種可行的選擇是有益的。微軟進入事件處理領(lǐng)域并不會淘汰現(xiàn)有的解決方案，用于構(gòu)建消息或事件驅(qū)動架構(gòu)；實際上，這可能會增加首次嘗試構(gòu)建它們的 .NET 開發(fā)者的數(shù)量——這是值得欣喜的！
微軟介入事件處理領(lǐng)域，若其影響導致開發(fā)者在構(gòu)建軟件時不再充分考慮其他選擇，則可能產(chǎn)生“負面影響”。一個常見的例子是，越來越多的新手 .NET 開發(fā)者知道 Entity Framework 的工作原理，但不知道如何直接與 SQL 交互——既然 Code First EF“有效”，那他們?yōu)槭裁催€要去尋找其他選擇呢？
第一類選擇者關(guān)注的是選擇和自由——他們了解每個可能選項都涉及技術(shù)和風格上的權(quán)衡，并希望能夠獲得這些選項。選項的減少必然意味著更少的創(chuàng)造自由，可能無法獲得真正需要的工具（這在 .NET 的早期時期就經(jīng)常發(fā)生）。
我經(jīng)常被問到對 Microsoft Orleans 與 Akka.NET 的看法——我通常會回答我也很高興它們都存在，因為在 2013-2014 年，當我需要一個可行的 .NET actor 模型實現(xiàn)時，它們都還沒有出現(xiàn)。Orleans 和 Akka.NET 在使用 actor 構(gòu)建軟件方面有不同的方法，我認為在這個領(lǐng)域有競爭是積極的。Orleans 的存在并沒有對 Akka.NET 的采用率造成任何傷害，因為 Orleans 和 Akka.NET 之間的這些差異對這兩個技術(shù)的用戶都非常重要。
選擇使我們在 .NET 生態(tài)系統(tǒng)中的工作經(jīng)驗對雇主和我們自己都更具經(jīng)濟價值——因此，選擇是積極的。
第二類：恐懼者
我對一些 .NET 開發(fā)者在 https://github.com/dotnet/aspnetcore/issues/53219 上的評論感到驚訝，他們表現(xiàn)出對 .NET 開源項目的恐懼，因此要求微軟提供官方解決方案來解決他們的問題。以下是一些例子：
- “[OSS 工具] 的目的就是為了宣傳其創(chuàng)建者?！?/span>
- “在這個討論中，我看到維護者抱怨這會扼殺他們的產(chǎn)品，而他們那擁有十年歷史卻只有 1k 顆星的項目也難逃厄運。無論微軟是否介入，你們的采用率依然會很低?！?/span>
- “你知道誰從未幫助過我嗎？是開發(fā)者。那么多開發(fā)者如此敵對、保護主義、領(lǐng)土主義，又充滿防御性，真是令人驚訝微軟竟然如此主動地擁抱開源，因為我們當中有太多人充滿敵意。”
- “.NET 仍然需要很多創(chuàng)新，以及歷史上分離的產(chǎn)品線之間的統(tǒng)一。我想要的是一個統(tǒng)一的 .NET，社區(qū)中的分裂程度最小。當你可以擁有一個易于使用并在開箱即用時集成所有最佳實踐的庫時，就沒必要有 5 個基本做同樣事情的不同庫。合并是好事，應該被接受，因為它可以減少 .NET 社區(qū)中的分裂，為新的創(chuàng)新提供更多資源?！?/span>
- “YouTube 效應催生了一代全新的開源項目，這些項目似乎只是為了追求精英地位而存在。一些開源項目所有者如此自私，我真不明白他們?yōu)槭裁匆孀氵@個領(lǐng)域。發(fā)現(xiàn)一些開源社區(qū)中最重要的人物也是最不友好的人物，讓我深感失望?！?/span>
- “我一直擔心 MassTransit 等工具能否長期存在?！?/span>
還有諸如“我們的律師讓我們選擇技術(shù)棧”之類的借口，這簡直就是企業(yè)版的“狗子吃了我的作業(yè)”。
.NET 開發(fā)者常因公司合規(guī)要求，需詳細列出并證明每個第三方庫的引入情況。
對于微軟的庫，一般無需額外審查。然而，第三方庫則必須通過許可證清理，有時還需核查作者，以確保其不來自受限制的國家。
— Ted Anderson (@TedsTechTed) 2024 年 2 月 14 日
這一問題正是 .NET Foundation 旨在明確解決的第三方 .NET 開源項目所面臨的挑戰(zhàn)之一。該基金會致力于確保所有納入其內(nèi)的項目都擁有清晰（無侵權(quán)）的知識產(chǎn)權(quán)和商業(yè)友好的開源許可證 —— 這兩個問題恰好是非工程利益相關(guān)者所關(guān)心的焦點。值得一提的是，我們的項目 Akka.NET 正是 .NET Foundation 的成員之一。
Akka.NET 目前已被美國銀行、美國聯(lián)合航空公司、西門子、美國人力資源管理局、諾斯洛普?格魯曼、戴爾、高通等眾多公司應用于生產(chǎn)環(huán)境。我們已對其中部分公司進行了知識產(chǎn)權(quán)和許可證的審查，但僅限于此。即便在國防承包、司法系統(tǒng)、政府以及《財富》100 強等敏感領(lǐng)域，我也未曾見過法律部門強制規(guī)定必須使用特定庫作者的情況。開放源代碼的核心優(yōu)勢在于其透明性，你可以清楚地了解所獲得的內(nèi)容。如果你希望在技術(shù)供應鏈上做到極度警惕，你完全可以從自己的機器上克隆源代碼，自行構(gòu)建所需的組件。
實際上，只有軟件開發(fā)者自己才會提出如此嚴格的庫供應商規(guī)定，這也是這種說法在很大程度上站不住腳的原因：
然而，這些政策究竟是由誰制定的呢？答案是高級軟件開發(fā)人員！實際上，公司律師等人通常是追隨 IT/R&D 部門的領(lǐng)導，而非相反。
此外，將這種情況視為大公司中不可改變、固有的事實，實際上是開發(fā)人員學會了無助的一種表現(xiàn)。
— Aaron Stannard (@Aaronontheweb) 2024 年 2 月 14 日
我經(jīng)常在我的博客上探討 .NET 開源生態(tài)系統(tǒng)。我們面臨的許多問題，例如開源可持續(xù)性，都是軟件生態(tài)系統(tǒng)中普遍存在的。然而，這些評論揭示了一個 .NET 生態(tài)系統(tǒng)特有的問題：單一供應商主導下的單一文化，在這個案例中即微軟。
這些抱怨實際上反映了部分 .NET 用戶內(nèi)心深處的深深憂慮：
- 主導因素：在面臨多個選項時，若微軟的選項不存在，他們可能會因技術(shù)選擇不當而受到指責。因此，遵循微軟制定的“標準”可以使他們免于承擔個人責任。
- 長期來看，他們擔心第三方項目無法提供持久的支持，因此認為微軟的選項默認是“安全”的。
- 他們認為第三方技術(shù)的質(zhì)量無法達到微軟在該領(lǐng)域的產(chǎn)品水平。
- 他們將第三方開源項目的創(chuàng)建者視為精英主義者，并擔心會遭到虐待，而微軟則會對他們的需求做出迅速響應。
這些用戶正在放棄自己的批判性思維，盲目地信任微軟，這主要是因為流傳著“選擇微軟從未導致人被解雇”的說法。
在其他軟件生態(tài)系統(tǒng)中，這種情況并不常見。如果一個 Java 開發(fā)人員因為害怕使用 Confluent 的工具而要求 Oracle 推出一個官方的 Kafka 替代品，那么出于上述原因，他們可能會受到嘲笑。但在 .NET 領(lǐng)域，我們卻因為某些原因?qū)Υ擞枰钥紤]，這是我們應該停止的行為。
這是情感推理導致的技術(shù)采納現(xiàn)象——人們選擇站在微軟這一邊，并非因為他們的工具最適合工作，而是因為它提供了最強大的責任追究防火墻?！斑x擇微軟從未導致人被解雇”這句話被過度解讀了。
最讓人感到悲哀的是，這些被提出的關(guān)于微軟“安全”的理由中，大部分甚至都不是真實的。
對于那些擔心開源工具持久性的用戶，他們可以問問那些在 2011 年 Silverlight 突然被取消時的用戶的感受?；蛘邌枂?WPF/UWP/MAUI 用戶，他們對微軟在 2024 年桌面 UI 領(lǐng)域的產(chǎn)品有多大的信心。
于我之前引用的評論特別關(guān)注 MassTransit 的持久性：MassTransit 自 2007 年開始開發(fā)，而 Windows Communication Foundation (WCF) 則始于 2006 年。那么，在 2024 年，這兩個框架中哪一個仍在積極維護呢？
對于這種情緒，我不得不佩服其純粹的 “卡夫卡陷阱” （Kafkatrap）能力：
盡管存在一些缺陷和糟糕的決策，但微軟對于那些感到被他人忽視或輕視的數(shù)百萬開發(fā)者來說，仍然是一個積極的因素。.NET SDK 是由一些世界頂尖的工程師開發(fā)的，其文檔內(nèi)容龐大且詳盡。微軟在發(fā)布新版本時始終保持著連貫性和紀律性，并不斷創(chuàng)新。此外，他們的外交手段也非常出色。
盡管我認為微軟對產(chǎn)品質(zhì)量的承諾是毋庸置疑的，但在這個生態(tài)系統(tǒng)中，只有那些極度缺乏經(jīng)驗的開發(fā)者才會相信，與擁有 10 萬名員工、市值 2 萬億美元的公司進行接口交流，會比與一個由 3 人組成的開源項目進行接口交流更容易。微軟開發(fā)的任何項目都有可能在經(jīng)歷 1-2 次企業(yè)重組后就消失無蹤。想想那些可憐的 AppCenter 用戶的遭遇吧：
哇，微軟要關(guān)閉 AppCenter 了！
— Simon Cropp (@SimonCropp) 2024 年 3 月 15 日
在帖子中，有用戶高度贊揚了 ASP.NET 的速率限制功能，認為這體現(xiàn)了微軟無與倫比的天才，為 .NET 開發(fā)者提供了一種便捷的功能，這種功能對于許多所謂的“門外漢”來說可能是遙不可及的，這確實令人感到驚訝。
不過，考慮到“選擇困惑者”的觀點：“微軟默認提供的選項往往過早地讓大多數(shù) .NET 用戶停止了尋找最佳選項的探索。”
然而，事實上，這位用戶所稱贊的 ASP.NET 速率限制 API 在大多數(shù)實際應用場景中，其“實用性”顯然是不夠的。
- 它們僅限于在進程內(nèi)使用，因此，對于那些最重要的經(jīng)濟上有用的速率限制應用（如按租戶計量收費）來說，這些功能根本無法使用。目前計劃在 .NET 9 中修復此問題鏈接。
- 它們的配置十分復雜，難以理解——實際上，執(zhí)行一些基于流的編程（如 Rx、TPL Dataflow、Akka.Streams）會更為簡單。別問我是怎么知道的，因為我整天都在處理這些工作。
- 它們對背壓不敏感——任意對 Web 應用程序進行速率限制是不明智的。我們應該僅在響應業(yè)務原因（如第 1 點所述）或因為共享資源（如數(shù)據(jù)庫）開始變得不可用，且選擇優(yōu)先處理某些流量而非其他流量（這也是一項業(yè)務規(guī)則）時才應該這樣做。這需要一些背壓意識。目前，最接近支持此功能的 API 是令牌桶速率限制策略。
- 當你真正需要開始應用速率限制時，這個 API 在開箱即用的情況下，使得理解重要的副作用和流控制變得困難。我再強調(diào)一下，如果這是一個基于流的編程模型而不是基于配置的模型，那么實現(xiàn)起來會更容易。根據(jù)我的應用程序要求，我可以簡單地開始緩沖、分批處理、減弱請求或執(zhí)行其他適當?shù)牟僮?。然而，在這種情況下，你只能拒絕一個請求，然后在事件處理程序中可能做一些其他工作。
ASP.NET 之所以推出這個速率限制功能，主要是因為“需要”這個功能，但它在考慮實際高流量應用程序需求時顯得捉襟見肘。那些一直在努力管理 ASP.NET 和其他 .NET 系統(tǒng)中高吞吐量流量的開發(fā)人員，比如那些在 https://github.com/ThrottlingTroll/ThrottlingTroll 中支持分布式按租戶限制速率的第三方解決方案，他們在設計這些功能時會更加完善。這是因為他們的業(yè)務依賴于這些功能，而不是因為微軟的產(chǎn)品經(jīng)理將其納入了今年的目標和關(guān)鍵結(jié)果文檔中。.NET 團隊做得不錯，但他們推出和做事情的動機不同，這一點在他們的優(yōu)先級中得到了體現(xiàn)。
在庫/框架作者與用戶需求的“一致性”方面，第三方開源選項通常比微軟更貼近實際。許多這樣的項目都是作者因為感受到真實業(yè)務需求而產(chǎn)生的，比如 Akka.NET 就是這樣誕生的。
如果微軟今年必須交付“云原生”內(nèi)容，明年又必須“與 Python 在極簡主義上競爭”，那并不一定符合當前框架用戶的真實需求。此外，由于 .NET 團隊需要支持的用戶、用例、版本和群體的數(shù)量和多樣性，他們必須提供滿足最低公共分母的體驗。這就是為什么像 ASP.NET 的速率限制這樣的抽象概念，甚至是早期的IDistributedCache這樣的功能，在實際應用中并不常見的原因——對于嚴肅的客戶導向的生產(chǎn)用途來說，它們顯得相當笨拙。
因此，這位用戶在吹噓這個功能有多好的同時，也暴露了自己在速率限制方面缺乏實際經(jīng)驗。這也印證了那些尋找更好選項的人的觀點，即只要微軟在該領(lǐng)域提供了某種解決方案，開發(fā)人員就會停止尋找最佳工具。這正是有人對微軟構(gòu)建事件解決方案提出擔憂的原因所在。
戰(zhàn)略思考與行動
對于 .NET 的開源軟件，你或許無需過于關(guān)注。選擇微軟的官方解決方案同樣無可非議。然而，在選擇微軟的解決方案時，有兩種截然不同的動機：一是因為你確信它能滿足你的需求，而另一種僅僅是因為微軟推出了它。盡管這兩種決策過程最終可能導向相同的結(jié)論，但前者是基于理性的推理，后者則顯得較為牽強附會。
過度吹捧摧毀選項只會損及自己的長遠利益，因為這樣做會讓人才和優(yōu)秀組織疏遠 .NET。下次你在/r/dotnet 上詢問“為何主流互聯(lián)網(wǎng)平臺不采用 .NET？”時，請銘記，這正是因為在 .NET 的過去，構(gòu)建這些平臺的工具匱乏。
.NET 自跨平臺以來一直在穩(wěn)步發(fā)展。若你希望這種進步勢頭得以延續(xù)，就應當支持 .NET 生態(tài)系統(tǒng)中選項的擴展，而非致力于毀滅它們。
作者簡介：
Aaron Stannard，Petabridge 公司的首席技術(shù)官兼創(chuàng)始人，致力于通過開發(fā) Akka.NET、Phobos 等項目，讓 .NET 開發(fā)人員更輕松地進行分布式編程。
原文鏈接:
開發(fā)者陣營分化，.NET 開源生態(tài)系統(tǒng)如何走向未來？_軟件工程_Aaron Stannard_InfoQ精選文章
