現在在微軟開發開源軟體是很一件正常的事情——但在 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