.NET 开源简史
現在在微軟開發開源軟件是很一件正常的事情——但在 2007 年，當時我剛加入微軟，那時候可不是這么一回事。微軟花了好幾年時間才找到正確的方向，讓微軟這艘大船順著開源之風向前航行。現在回頭遠望過去那些曾經面臨的挑戰，我們一笑而過。這篇文章將講述與微軟第一個開源項目有關的故事，以及它如何為我們到達今天的位置鋪平了道路。
在 90 年代后期，我在一家叫作 Mustang Software 的初創公司工作，這家公司開發的軟件用于跟蹤公司收到的電子郵件是否得到及時回復。2000 年，這家公司被收購，而在那之前，我帶著團隊到奧蘭多參加微軟專業開發者大會，微軟在大會上介紹了 ASP+（最終成為 ASP.NET?Web 技術棧）和 C#。在大會期間，我和團隊安裝了預覽版，而我立即愛上了.NET。在后續的工作中，我繼續使用 ASP.NET。
2006 年，微軟推出 CodePlex 源代碼共享平臺。最初，CodePlex 上有一個 Web 項目，代號為 Atlas 的，現在叫作 AJAX Control Toolkit。Atlas 是微軟有史以來構建的第一批開源項目之一，人們對它的討論和興趣令人印象深刻。Brad Abrams 和 Scott Guthrie 寫的有關 Atlas 的博文讓我有了想加入微軟的沖動。
我給 Brad 寫了一封電子郵件，作為對他的博文的評論——他在一分鐘內回復了郵件！第二天，我們通過電話進行了交談，不到一周，我就通過了微軟的面試。突然間，我從陽光明媚的加利福尼亞搬到了天氣變化無常的華盛頓雷德蒙德。
我加入了 Brad Abrams 的團隊，這個團隊負責 ASP.NET 和 Silverlight 的開發。Silverlight 是將原生.NET 開發引入瀏覽器的早期嘗試，當時剛剛發布為了第一個版本。ASP.NET?MVC 還處于早期原型階段，并且只在內部演示，盡管偶爾也被當作招聘工具，這對于 2007 年 10 月加入團隊的 Phil Haack 起到了關鍵作用。Scott Hanselman 也是在這個時候加入微軟，盡管是在另一個團隊。
眾所周知，ASP.NET?MVC 是 ASP.NET 團隊對 Ruby on Rails 的大受歡迎而做出的回應。Ruby on Rails 由 David Heinemeier Hansson 于 2004 年創建，作為 Basecamp 的一部分。到 2007 年，Ruby on Rails 被包含在最新版本的 Mac OS X 中！MVC 模式與 Rails 腳手架的組合大大減少了 Web 開發人員需要編寫的管道代碼數量。它讓開發帶有表單數據的網頁變成一件很令人愉悅的事情，所以 Web 開發人員都很喜歡它。
ASP.NET?MVC 也是對 ASP.NET?Web Forms 備受批評而做出的回應。ASP.NET?Web Forms 意在將 Windows Forms 開發人員帶到 Web 上。它確實奏效了，有大量的新 Web 開發人員使用 ASP.NET?Web Forms 進行開發。但經過幾年的發展，ASP.NET?Web Forms 也出現了很明顯的問題：為了對開發人員隱藏 Web 的開發特點，他們把背后的東西弄得一團糟。
例如，在 ASP.NET?Web Forms 頁面上混合使用 C# 和 HTML 代碼使得單元測試變得相當困難。如果沒有測試用例，那么隨著時間的推移，維護和修改大型網站會變得很痛苦。即使你創建了測試用例，它們也主要是 UI 功能測試——即使是在今天，這仍然是一種很脆弱的測試方法。對網頁的任何更改都可能會破壞頁面的相關測試。
ASP.NET?MVC 的早期原型令人印象深刻，足以讓 Scott Guthrie 決定在德克薩斯州奧斯汀舉行的第一屆 ALT.NET 大會上首次公開展示它們。ALT.NET 運動源于一班狂熱的開發者，他們喜歡使用.NET，但他們認為開源工具應該占更大的比重。
在微軟的歷史上，曾經有一個時期患上了“Not-Invented-Here”綜合癥——鄙視一切不是由微軟開發的軟件。很多樂于使用微軟工具的用戶進一步強化了這種綜合征。當微軟宣布構建自己的對象關系映射器（ORM）Entity Framework 時，這個綜合征算是病入膏肓了。其他一些 ORM 解決方案（如 nHibernate）的倡導者對于微軟的重復發明輪子感到十分惱火。這些倡導者正是 ALT.NET 的開局者，2007 年 10 月，他們推出了第一個技術大會。
在 ALT.NET 大會上，Scott?Guthrie 概述了 ASP.NET?MVC，這是首次公開介紹 ASP.NET?MVC。Scott Hanselman 演示使用 IronPython 構建 MVC 控制器，Phil Haack 使用 IronRuby 進行了類似的演示。展示的內容都只是原型代碼，并不會實際發布出去。但這是一個有趣的開始，每個人都希望這是微軟新時代的開端。從一開始，Scott Guthrie 就說 MVC 將是開源的。
在 ALT.NET 大會的同一周，微軟還“公開”了整個.NET?Framework 代碼作為參考，這樣在調試應用程序時就可以進入底層的.NET?Framework 代碼。但我們知道，它實際并沒有開源，但卻是向開源邁出的又一步。
MVC 和 Silverlight 也是 Web 團隊首次發布的“帶外”產品。每個新版本的.NET 和 Visual Studio 需要 24 至 36 個月才能上市——計劃、編碼和修復缺陷各自需要花上差不多一年的時間。很顯然，這個發布周期對于 Web 世界來說還不夠快，特別是對于 MVC 來說。畢竟，Ruby on Rails 每年都會推出一個新版本。
到了 2007 年 12 月，我們發布了 MVC 的社區技術預覽版（CTP），它為當時發布的 Visual Studio?2008 和.NET?3.5 提供了基本工具（一個項目模板）。CTP 是第一個可供任何人下載和使用的 MVC 版本。
2008 年 2 月，也就是在 Mix 08 大會之前，一個叫作 MIX Preview Release 的新版 MVC 不僅增加了人們一直要求的一系列功能，而且加入了大量新工具，包括直接支持開源測試框架，如 NUnit 和 MBUnit。
在 Mix 08 大會之后，開發者可以下載、編譯和調試 MVC 本身的源代碼。當然，這與我們現在所期望的方式并不一樣，團隊在寫完代碼后直接將代碼提交到代碼庫。相反，當時 MVC 的開發發生在內部，寫完代碼后再將代碼的一部分發布在 CodePlex 上。
將部分 MVC 源代碼的副本放在 CodePlex 上，并與外部進行交流，這是走向開源之路的一次早期嘗試，微軟內部當時對此有很多擔憂。我們的目標是每隔幾周推出一次更新，希望總有一天會每天更新一次……
差不多就在那個時候，我們遇到了一個有趣的問題。ASP.NET?MVC 的一個關鍵部分是路由——能夠將請求定向到控制器，而 ASP.NET?Dynamic Data 的開發人員也在使用路由——我們各自都構建了自己的實現。事實證明，“Not-Invented-Here”綜合癥甚至擴展到個體團隊！后來我們花了一些時間將路由的獨特部分從代碼庫中抽取出來，變成一個路由引擎，作為 System.Web 的一部分。
在這個過程中，我們還開發了路由調試器。它最初作為一個私有工具，用于調試新的共享路由模型，最后才將它共享給外部。
代碼版本的命名也是一個有趣的問題。ASP.NET?MVC 的初始版本叫作社區技術預覽（Community Technology Preview）。之后，我們將它們改為預覽版本（Preview Release），有一些有編號，有一些沒有。但即使是預覽版在起初也不會經常發布，我們無法達到每隔幾周就將新代碼更新到 CodePlex 的目標，所以我們進行了源刷新（Source Refresh）。這有點令人感到困惑，但我們也一直在學習——最終，預覽版的發布達到了足夠快的速度，并停止使用替代名稱。
2008 年 9 月，MVC 第 5 個預覽版發布——這很棒，但更重要的是 jQuery。Jon Resig 早在 2006 年就開始將 jQuery 庫作為一個緊湊而強大的開源工具，讓 JavaScript 開發變得不那么痛苦，而 CodePlex 的很多用戶建議 MVC 應該使用 jQuery。集成 jQuery 對微軟來說是一個了不起的挑戰——使用開源軟件是一回事，而開發開源軟件是另一回，但是將開源庫作為產品的一部分？這實在是太瘋狂了！
但使用 jQuery 確實是有意義的。無論如何，jQuery 提供的大部分功能都有助于完善 MVC 的功能。為什么要重新創建輪子呢？我們開發的很多不同的 Web 產品都可以利用 jQuery，以至于 Scott Guthrie 在他的博客上宣布，Visual Studio 的下一個版本將加入對 jQuery 的支持，而這在 2010 年成為了現實。
這個時候，微軟 Azure 的早期版本發布了，我們嘗試將 MVC 與 Azure 結合在一起使用，將其作為 11 月要發布的 MVC 測試版的示例，并在洛杉磯舉行的微軟專業開發者大會上進行了演示。
2009 年 3 月，微軟在 Mix 09 大會上發布了 MVC 的第一個 RTM 版本。我們將代碼發布在 CodePlex 上，基于 MS-PL 開源許可。許可協議的內容很短，與今天的 MIT 許可（這是微軟目前使用的主要許可）類似。開源計劃署（OSI）批準了 MS-PL 許可，但它在某些圈子中仍然存在爭議——微軟為什么要推出自己的許可？背后有什么目的？當然，MS-PL 許可背后并沒有藏著任何不可告人的秘密，但從長遠來看，一直使用這個許可并沒有太大意義——使用 MIT 或者 Apache 許可就足夠了。但在微軟內部，有些法律部門的同事樂此不疲，他們不明白一家企業擁有獨立的許可會有哪些不利影響。
法律團隊擔心將 jQuery 添加到 Visual Studio 2010 中存在許可風險——如果 jQuery 中包含 GPL 許可的代碼，這會影響 Visual Studio 其余部分的許可嗎？當時，法律同事擔心 GPL 公共版權具有“傳染性”，將 GPL 許可軟件與具有傳統版權（如.NET）的軟件合并將會侵犯版權。
在今天看來，這種擔憂似乎有點被夸大了，但法律同事們確實處理過一些情況，比如與代碼有關的訴訟，這些代碼被意外地包含在微軟 Word 中，導致不得不在世界各地下架 Word 產品。
微軟制定了一系列程序來解決與 jQuery 有關的法律問題，還構建工具用于測試 jQuery 源代碼的譜系——這個工具搜索整個 jQuery 代碼，檢查其中所有涉及的許可。我們發現有一個貢獻者添加了一些 GPL 許可代碼——jQuery 維護者們甚至都不知道！jQuery 是基于 MIT 許可的，被用于商業用途，在其中添加 GPL 許可代碼是沒有意義的。
就在 Visual Studio 2010 發布之前，我接到了法律部門的一位律師的電話——他們認為，微軟軟件包提供的任何代碼（包括 jQuery）都應該基于 MS-PL 許可。后來，我參加了一次電話大會，我強烈主張我們不應該改變第三方開源庫的許可。MIT 和 MS-PL 非常相似，但這并不是重點——只是改變一個開源項目的許可實在是太魯莽了。這樣并不會帶來任何有意義的好處，卻嚴重損害了我們作為開源支持者的聲譽。
最終，法律團隊也開始擁抱這個開源之旅。當 Studio 2010 發布時，其中包含的 jQuery 仍然保留了原始的 MIT 許可。Visual Studio?2010 還包含了 ASP.NET?MVC V2、Silverlight 4 和其他一系列出色的工具。
這一版本成為微軟開源項目的榜樣。當 ASP.NET 團隊開始計劃一個跨平臺的新版本時，我們很自然地公開與社區一起合作。最終，這項工作發展成為.NET?Core 和.NET?Foundation 的基礎，以支持.NET 平臺的開源協作。
回首過去所走過的開源之路以及學到的經驗教訓，如果不是之前付出的那些努力，我們或許不會達到今天這樣的狀態。
英文原文：https://medium.com/microsoft-open-source-stories/starting-the-net-open-source-revolution-e0268b02ac8a
原文地址：https://www.infoq.cn/article/qjPthH_mUfwwmqN04uK0
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
- 上一篇： IdentityServer4实战 -
- 下一篇： 如何在ASP.NET Core程序启动时