如今，在微軟構建開源軟件是很正常的一件事——但早在2007年，我開始在微軟工作時，情況並非如此。我們花了幾年的時間才找到正確的方法，順利開啟了微軟的開源之路。但是，如今我們已取得勝利，可以面帶微笑地回首先前所面臨的諸多挑戰。我要講述的故事是微軟首個成功的開源項目，以及該項目如何為我們今天所處的位置鋪平了道路。
90 年代後期，我就職於一家名為 Mustang Software 的創業公司，該公司構建的軟件用於跟蹤公司收到的所有電子郵件是否得到及時回覆。在該創業公司於 2000 年被出售之前，我帶領我的團隊到奧蘭多參加微軟開發專家大會，大會引入了 ASP+（最終成為 ASP.NET Web 堆棧）和 C#。我和我的團隊在會議上安裝了預覽版，我立即就愛上了 .NET。我繼續在後續工作中使用 ASP.NET。
Brad Abrams和Scott Guthrie關於Atlas的博客文章
然後在2006年，微軟將 CodePlex 設置為源代碼共享地。CodePlex 上的一個原始 Web 項目的代號為 Atlas，現在稱為 AJAX 控件工具包。Atlas 是微軟有史以來構建的首批開源項目之一，圍繞 Atlas 的討論非常激烈，對 Atlas 也產生了深厚的興趣。正是 Brad Abrams 和 Scott Guthrie 關於 Atlas 的博客文章讓我覺得我想參與微軟正在研發的工作。
我給 Brad 寫了一封電子郵件，對博客文章進行回應 — 不到一分鐘，他就回復了！第二天，我們通過電話進行了交談，一週之內，我就在微軟園區進行了面試。突然，我就從陽光明媚的加利福尼亞州搬到天氣變幻無常的華盛頓州雷德蒙德。
我加入了 Brad Abrams 的團隊，負責所有 ASP.NET 工作。此外，我還負責全新的 ，它是將本機 .NET 開發引入瀏覽器的初步嘗試，剛剛發佈了第 1 版。ASP.NET MVC 處於早期原型階段，雖然偶爾用作招聘工具，但僅在內部試用，它深深地影響了 Phil Haack，他於2007年10月加入團隊。Scott Hanselman 大約也是在這個時候加入了微軟，儘管他加入了其他團隊。
ASP.NET MVC是ASP.NET團隊對Ruby on Rails大受歡迎的回應
眾所周知，ASP.NET MVC 是 ASP.NET 團隊對 Ruby on Rails 大受歡迎的回應——始於2004年，由獨一無二的 David Heinemeier Hansson 作為 Basecamp 的一部分進行開發。到2007年，最新版本的 Mac OS X 已附帶 Ruby on Rails！“模型-視圖-控制器”模式與 Rails 基架的組合大大減少了 Web 開發人員需要編寫的管道代碼量，使得 Forms-Over-Data 網頁令人愉快，Web 開發人員喜歡使用它。
ASP.NET MVC 也是對 ASP.NET Web 窗體遭受的批評的一種回應。ASP.NET Web 窗體的構建旨在將所有這些 Windows 窗體開發人員聚集到 Web 上 — 而無需學習太多東西。ASP.NET Web 窗體做到了這一點，眾多新的 Web 開發人員都使用它創建網站。但經過幾年的發展，很明顯 ASP.NET Web 窗體也存在一些問題：向開發人員隱瞞網絡本質的過程意味著背後一些醜陋的問題。
例如，在 ASP.NET Web 窗體頁面上 C# 代碼和 HTML 的混合方式使其難以構建單元測試。如果無法測試，久而久之，大型網站的維護和修改工作會變得更加困難。如果您確實創建了測試，這些測試大部分是運行 UI 的功能測試 — 即使是在今天，這也是一種脆弱的測試構建法。對網頁的任何更改都很可能會中斷該頁面的所有測試。
ASP.NET MVC 的早期原型令人印象深刻，足以讓 Scott Guthrie 決定將其在德克薩斯州奧斯汀舉行的首屆 ALT.NET 大會上首次公開亮相。ALT.NET 運動源於一群充滿激情的開發人員，他們喜歡使用 .NET，但他們認為開源工具應是該因素的一個重要組成部分。
在微軟歷史上的那個時候，“非我發明症”甚囂塵上
在微軟歷史上的那個時候，非我發明症甚囂塵上 — 非微軟製造的軟件往往都會大打折扣。很多客戶都樂於只使用微軟製造的工具，使這種態度得到了加強。當微軟宣佈正在構建自己的對象關係映射器（被稱為“實體框架”）時，此方法就到了緊急關頭。其他對象關係映射器解決方案（如 nHibernate）的倡導者對於構建另一個對象關係映射器、而不是支持現有解決方案感到惱火。這些倡導者成為 ALT.NET 的開端，到2007年10月，他們召開了首次會議。
從一開始Scott Guthrie就說MVC將是開源的
在 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 也是網絡團隊“帶外”發佈的首批產品。.NET 和 Visual Studio 的每一個新版本都需要 24-36 個月才能實現 — 每個差不多需要一年的時間進行規劃、編碼和修復上市。很明顯，此週期對網絡世界，特別是 MVC 來說還不夠快。畢竟，Ruby on Rails 每年都會推出一個新版本。
2007年12月，我們發佈了 MVC 的社區技術預覽版，為最近發佈的 Visual Studio 2008 和 .NET 3.5 提供了基本工具（項目模板）。該預覽版是 MVC 的第一個版本，任何人都可以下載並開始試驗。
2008年2月，在 Mix 08 會議之前，新版 MVC（即 MIX 預覽版）不僅增加了人們一直要求的一系列功能，而且還增加了大量新工具，包括直接支持開源測試框架，如 NUnit 和 MBUnit。
在 Mix 08 會議之後，MVC 本身的源代碼也可供下載、編譯並用於調試。這不是我們今天所認為的那樣，也就是說，團隊在編碼時將代碼提交至存儲庫。更準確地說，MVC 在內部開發，然後一部分代碼被髮送到 CodePlex。
在CodePlex上與公眾互動是實現開源項目之路上進行的早期透明度實驗
移動 MVC 代碼副本並在 CodePlex 上就其與公眾互動是實現開源項目之路上進行的早期透明度實驗，微軟內部對此有很多擔憂。目標是每隔幾周推出一次更新，希望有一天可以每天推出一次更新。
大約是那個時候，我們遇到了一個有趣的問題。ASP.NET MVC 的關鍵部分是路由 — 能夠將請求傳遞到控制器中。ASP.NET 動態數據的工作人員還將路由用於他們的技術，我們每個人都構建了自己的實現。事實證明，非我發明症甚至延伸到個人團隊之中！我們花費了一些時間對路由的獨特之處進行抽象，使其與基本代碼區分開來，併到達一個路由引擎，當時作為 System.Web 的一部分。
此過程的副作用也是創建路由調試器。該調試器起初是一個私有工具，幫助我們瞭解新的共享路由模型的情況，最終也使與世界分享它變得有意義。
對代碼版本命名也是一個有趣的問題。ASP.NET MVC 的初始版本被稱為社區技術預覽版。之後，我們將名稱改為預覽版，有些編號了，有些則沒有。但是，由於起初無法頻繁發佈新代碼，實現不了 CodePlex 每隔幾周就有新代碼這一目標，因此我們推出了 Source Refresh。過程有一些混亂，但我們不斷學習 — 最終，預覽版很快就發佈了，備用名稱也停止使用。
2008年9月，MVC的預覽版5正式推出
2008年9月，MVC 的預覽版 5 正式推出 — 該版本棒極了，但更重要的是 jQuery。早在2006年，Jon Resig 就開始將 jQuery 庫用作一套緊湊的開源工具，簡化在 JavaScript 中的工作，同時，CodePlex 上的許多人都認為，MVC 應該利用 jQuery 的工具。合併 jQuery 對微軟來說是一個了不起的挑戰 — 使用開源軟件是一回事，創建開源軟件卻是另一回事，但是將開源庫包括在產品內？太瘋狂了！
但這對使用 jQuery 來說是合情合理的。無論如何，在 MVC 中完善各項特性需要使用 jQuery 提供的大部分功能。為什麼要重新創建輪盤（改變色調怎麼樣）？我們製作的許多不同的網絡產品都可以利用 jQuery，以至於 Scott Guthrie 在他的博客上宣佈，下一版 Visual Studio 將附帶 jQuery，最終於2010年做到了這一點。
此時，早期版本的 Microsoft Azure 也在全球推出，我們嘗試將 MVC 與 Azure 一起用作11月發佈的 MVC 測試版的示例 — 它在洛杉磯舉行的微軟開發專家大會上作為演示展出。
2009年3月，MVC 的交付廠商版（第 1 版）在 Mix 09 會議上上市。我們在 CodePlex 上發佈了帶 MS-PL 開源許可證的代碼。該許可證非常簡短，今天被視為類似於 MIT 許可證（這是微軟目前大部分時間都在使用的許可證）。開源促進會批准了 MS-PL 許可證，但該許可證在某些領域仍然存在爭議 — 微軟為什麼要自己製作許可證？其中到底隱瞞了什麼？當然，MS-PL 許可證沒有任何棘手的問題，從長遠來看使用它最終沒有任何意義 — MIT 或 Apache 許可證也同樣適用。但在微軟內部，有些法律人士更樂意看到這樣，但不理解為組織設置獨立許可證的不利方面。
將jQuery添加到Visual Studio 2010中確實代表了一種新的風險
法律團隊而言，在 Visual Studio 2010 中添加 jQuery 確實代表了一種新的風險——如果添加到 jQuery（包含 GPL 類型的許可證）的代碼會影響 Visual Studio 其餘部分的許可會怎麼樣？當時，對 GPL“自由拷貝”法的擔憂意味著法律人士認為它具有“傳染性”。將 GPL 許可軟件併入具有傳統版權（如 .NET）的軟件將侵犯版權。
如今，似乎這些擔憂有些過度，但這些是處理過以下類似訴訟案件的法律人士：Microsoft Word 中意外地含有一些代碼，導致從全球各地的商店貨架上刪除了 Word 的物理機器。該主張成本很高——2009年，我們仍上市了大量軟件。
為了緩解 jQuery 的法律問題，我們實施了大量程序。我們構建了工具，使用這些工具測試 jQuery 源代碼的出處——這些工具將查找代碼並檢查所有許可。只有一次，我們發現參與者添加了一些 GPL 許可代碼 — jQuery 工作人員甚至都不知道這件事！根據 MIT 許可證，jQuery 被許可用於商業用途，jQuery 中的 GPL 許可代碼是沒有意義的。
我們*永遠*不應該改變第三方開源庫的許可證
就在 Visual Studio 2010 發佈之前，我接到了法律部的一位律師的電話 — 法律意見書認為，Microsoft 軟件包中提供的任何代碼（包括 jQuery）都應獲得 MS-PL 許可證的許可。我被拉進一個電話會議，在會議上，我強烈主張（說了一些難聽的話）我們*永遠*不應該改變第三方開源庫的許可證。MIT 和 MS-PL 非常類似，這一點並不重要——像那樣更改許可證實在是太粗魯了。這樣做沒有得到什麼有意義的好處，反倒對我們作為開源支持者的聲譽造成了重大損害。
最終，我們的法律團隊接受了此次開源之旅，當 Studio 2010 發佈時，jQuery 的捆綁版與其原始的 MIT 許可證相關聯。Visual Studio 2010 還包括 ASP.NET MVC 第 2 版、Silverlight 4 以及其他大量出色的工具。
此版本奠定了基礎，成為我們如何在微軟開源的榜樣項目。當 ASP.NET 團隊開始規劃跨平臺的主要新版本時，我們很自然地與社區合作，公開地構建新版本。最終，這項工作擴展成 .NET Core 以及 .NET Foundation 的成立，以支持 .NET 平臺上的開源協作。
回顧過去，看看我們如何嘗試開源，學到一些經驗教訓，並繼續使用有效的方法進行構建也是一件很有意思的事情。如果當時沒有做那些工作，我認為我們不會有今天所取得的成就。
閱讀更多 科技風雲會 的文章
