知識星球如今，在微軟構建開源軟體是很正常的一件事——但早在2007年，我開始在微軟工作時，情況並非如此。我們花了幾年的時間才找到正確的方法，順利開啟了微軟的開源之路。但是，如今我們已取得勝利，可以面帶微笑地迴首先前所面臨的諸多挑戰。我要講述的故事是微軟首個成功的開源專案，以及該專案如何為我們今天所處的位置鋪平了道路。
90 年代後期，我就職於一家名為 Mustang Software 的創業公司，該公司構建的軟體用於跟蹤公司收到的所有電子郵件是否得到及時回覆。在該創業公司於 2000 年被出售之前，我帶領我的團隊到奧蘭多參加微軟開發專家大會，大會引入了 ASP+（最終成為 ASP.NET Web 堆疊）和 C#。我和我的團隊在會議上安裝了預覽版，我立即就愛上了 .NET。我繼續在後續工作中使用 ASP.NET。
1Brad Abrams和Scott Guthrie關於Atlas的部落格文章
然後在2006年，微軟將 CodePlex 設定為原始碼共享地。CodePlex 上的一個原始 Web 專案的代號為 Atlas，現在稱為 AJAX 控制元件工具包。Atlas 是微軟有史以來構建的首批開源專案之一，圍繞 Atlas 的討論非常激烈，對 Atlas 也產生了深厚的興趣。正是 Brad Abrams 和 Scott Guthrie 關於 Atlas 的部落格文章讓我覺得我想參與微軟正在研發的工作。
我給 Brad 寫了一封電子郵件，對部落格文章進行回應 — 不到一分鐘，他就回覆了！第二天，我們透過電話進行了交談，一週之內，我就在微軟園區進行了面試。突然，我就從陽光明媚的加利福尼亞州搬到天氣變幻無常的華盛頓州雷德蒙德。
我加入了 Brad Abrams 的團隊，負責所有 ASP.NET 工作。此外，我還負責全新的 Silverlight，它是將本機 .NET 開發引入瀏覽器的初步嘗試，剛剛釋出了第 1 版。ASP.NET MVC 處於早期原型階段，雖然偶爾用作招聘工具，但僅在內部試用，它深深地影響了 Phil Haack，他於2007年10月加入團隊。Scott Hanselman 大約也是在這個時候加入了微軟，儘管他加入了其他團隊。
2ASP.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，但他們認為開源工具應是該因素的一個重要組成部分。
3在微軟歷史上的那個時候，“非我發明症”甚囂塵上
在微軟歷史上的那個時候，非我發明症甚囂塵上 — 非微軟製造的軟體往往都會大打折扣。很多客戶都樂於只使用微軟製造的工具，使這種態度得到了加強。當微軟宣佈正在構建自己的物件關係對映器（被稱為“物體框架”）時，此方法就到了緊急關頭。其他物件關係對映器解決方案（如 nHibernate）的倡導者對於構建另一個物件關係對映器、而不是支援現有解決方案感到惱火。這些倡導者成為 ALT.NET 的開端，到2007年10月，他們召開了首次會議。
4從一開始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。
5在CodePlex上與公眾互動是實現開源專案之路上進行的早期透明度實驗
移動 MVC 程式碼副本併在 CodePlex 上就其與公眾互動是實現開源專案之路上進行的早期透明度實驗，微軟內部對此有很多擔憂。標的是每隔幾周推出一次更新，希望有一天可以每天推出一次更新。
大約是那個時候，我們遇到了一個有趣的問題。ASP.NET MVC 的關鍵部分是路由 — 能夠將請求傳遞到控制器中。ASP.NET 動態資料的工作人員還將路由用於他們的技術，我們每個人都構建了自己的實現。事實證明，非我發明症甚至延伸到個人團隊之中！我們花費了一些時間對路由的獨特之處進行抽象，使其與基本程式碼區分開來，併到達一個路由引擎，當時作為 System.Web 的一部分。
此過程的副作用也是建立路由除錯器。該除錯器起初是一個私有工具，幫助我們瞭解新的共享路由模型的情況，最終也使與世界分享它變得有意義。
對程式碼版本命名也是一個有趣的問題。ASP.NET MVC 的初始版本被稱為社群技術預覽版。之後，我們將名稱改為預覽版，有些編號了，有些則沒有。但是，由於起初無法頻繁釋出新程式碼，實現不了 CodePlex 每隔幾周就有新程式碼這一標的，因此我們推出了 Source Refresh。過程有一些混亂，但我們不斷學習 — 最終，預覽版很快就釋出了，備用名稱也停止使用。
62008年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 許可證也同樣適用。但在微軟內部，有些法律人士更樂意看到這樣，但不理解為組織設定獨立許可證的不利方面。
7將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 許可程式碼是沒有意義的。
8我們*永遠*不應該改變第三方開源庫的許可證
就在 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 平臺上的開源協作。
（要瞭解有關 .NET Foundation 歷史的更多資訊，請檢視 Beth Massi 的帖子：建立開源 .NET Foundation）。
回顧過去，看看我們如何嘗試開源，學到一些經驗教訓，並繼續使用有效的方法進行構建也是一件很有意思的事情。如果當時沒有做那些工作，我認為我們不會有今天所取得的成就。
