“我們把所有對於語言正確性和性能的要求都集中在一份代碼中，使其擁有最佳的質量和最好的多樣性——我們將重新定義“編譯器”這個詞。”
Roslyn是C#和Visual Basic.NET的開源編譯器的項目名。十年來它從微軟的封閉中走出來，變成現在的開源、跨平臺、公開的語言引擎，支持一切使用C#的東西（包括VB，我認為它是C#帶來的饋贈）。
在我2005年加入微軟的時候，有過一次關於Roslyn項目的討論，當時剛好是.NET 2.0發佈前夕。那次討論的內容是用C#重寫C#。這種事情在編程語言中很常見，也是語言成熟的一個標誌。但這樣做還有個更現實、更重要的動機：作為C#的締造者的我們竟然用的不是C#，而是C++！日常使用C#能改變你對C#的看法，這就是使用自家產品的好處。
客戶期待新的編譯器行為與舊編譯器完全一致。使用C#重寫編譯器意味著連bug都要與舊編譯器完全一致。
重寫一個客戶已使用多年的編譯器有很多難點：新的編譯器必須擁有完全一致的行為。編寫新的C#編譯器意味著連bug都要與舊編譯器完全一致。而且這裡說的還不僅僅是已知的bug，還有許多未知的bug和無意的編譯器行為，由於被程序員發現並且利用（而且通常人們意識不到自己利用了這些行為），所以也必須原樣實現才行。
這種級別的難度使得我們很多年來都不敢碰這個項目。
此外，儘管使用C#編寫新的C#編譯器可能會有很多好處，但其價值卻很難展示給客戶：新的編譯器對現有客戶有什麼好處呢？也許，唯一在乎C#編譯器是否用C#編寫的人只有編譯器團隊自己了吧。
但同時，另一個問題也越來越明顯，即所有使用了C#代碼的工具都需要進行修改，儘管這部分工作具有重複性。除了編譯器之外，我們的兄弟團隊在開發Visual Studio中的C# IDE支持，他們也需要寫一些代碼（當時也是C++代碼）來理解C#的語法和語義。
除此之外，微軟和其他第三方如StyleCop、CodeRush等工具也越來越多，所有工具都要根據C#源代碼文本實現。這些工具都有不同的bug，對C#的理解程度也不盡相同，也都做了不同的妥協和權衡取捨。這一切都需要越來越多的努力，只為了解決一個問題：理解源代碼。
到此，我們終於能夠提出項目的價值了：全世界只需要一份理解C#的代碼，任何想開發代碼工具的人都可以共享這份代碼！
這樣，客戶價值就能體現在工具數量的增加，特別是現有工具的質量提高。我們把所有對於語言正確性和性能的要求都集中在一份代碼中，使其擁有最佳的質量和最好的多樣性。我們需要構建一個語言引擎！一個通用的、公開的C#代碼API！我們將重新定義“編譯器”這個詞。
當然，要想為廣義的C#社區開發API，很顯然必須開發成.NET API，因此要用C#實現。所以，用C#自我編譯C#的夢想可以作為意外收穫順帶實現了。
於是，Roslyn從一個開放的思想中誕生了：將C#的內部工作共享給世界，使之可以通過程序訪問。在一個無處不在封閉式文化中，這種想法是一個非常大膽的決定：我們要把知識產權無償分享？我們要給那些不屬於我們的工具開發商提供支持讓他們跟我們競爭？
最後我們得出的結論是：增強生態環境，使之成為全世界最好的工具語言。這是為了C#和.NET的長期增長，而不是隻為了眼前的利益和保護微軟的財產。所以，就算不談開源，考慮到成本和風險，Roslyn項目的通過對於微軟也是件不容易的事兒。
當然，Roslyn項目並不是這麼簡單。Roslyn的願景充滿了野心，也充滿了技術挑戰，我們花了五年時間才實現。但這是另一個話題了。
我們花費了很多時間來構建初始版本，而此時Roslyn依然是個閉源項目。從2009年早期這個項目伊始，我們就制定了將編譯器開源的願景，但微軟顯然還沒做好準備。私下開發再提交專利，這是微軟從上世紀七十年代開始一貫如此的做法。儘管現在有所改變，但改變的速度顯然比我們期待的要慢得多。
實際上，有段時間我們似乎覺得公司會完全走向相反的方向。
Windows 8項目似乎佔用了整個公司的精力。隨著新編程模型的出現，Windows 8的觸角伸到了開發工具和語言團隊中，每個人都被要求高度保密，不僅要對外部保密，而且在公司內部也要保密。比如，我們當時開發的異步功能需要協調Windows 8的編程模型，因此我甚至都不敢在內部發表設計上的說明，以免不小心洩露Windows 8的消息給自己帶來麻煩！這種氛圍非常不利於創新，當然對於我們希望讓C#編譯器開源也不是好兆頭。
但最終，在Windows 8完成開發之後，公司開始轉變到新的方向上，新的領導團隊帶來了完全不同的價值觀，即我們今天的微軟。開源活動像雨後春筍般在微軟內部生根發芽。
F#於2010年以開源授權發佈，並且成立了自己的基金會——F#軟件基金會（https://fsharp.org/）。在它周圍迅速成長起來的生機勃勃的社區得到了我們所有人的嫉妒。我們的團隊繼續努力推行Roslyn的開源產品授權，最後終於實現了。
2012年，微軟建立了微軟開源技術——一個專門關注開源項目的組織。Roslyn移交給了微軟開源技術，從而正式成為開源項目。Roslyn非常適合開源：所有開發資源都屬於內部並且廣為人知，項目自身也沒有太多可能造成授權衝突的依賴。
2014年4月，在舊金山召開的微軟“Build”開發者大會上，Anders Hejlsberg第一次展示了作為開源項目的Roslyn（https://blogs.msdn.microsoft.com/csharpfaq/2014/04/03/taking-a-tour-of-roslyn/），隨後Roslyn於4月3日在 CodePlex（微軟後來退役了的開源代碼平臺）上以Apache 2.0的授權發佈了。
微軟開源技術組織下CodePlex上的Roslyn項目
同時，公司還宣佈.NET基金會成為包括Roslyn在內的.NET項目的總部。
成為開源給我們帶來了美好的新鮮空氣！在我們開始盡情享受CodePlex的開放時，微軟的其他開源過程也已做好準備，而現在，開源已經深入人心，許多團隊都在使用開源。
GitHub不僅是我們發佈代碼的地方，也是我們日常工作的場所。
此外，公司還意識到，我們不需要控制一切。很明顯，CodePlex沒有存在的理由，因此Roslyn同其他項目一起從CodePlex移動到了GitHub，當時GitHub已經成為開源項目事實上的家園。這樣，不僅代碼託管在GitHub上，而且整個構建過程都放在了GitHub上。GitHub不僅是我們發佈代碼的地方，也是我們日常工作的場所。
現在Roslyn放在了GitHub上
C#語言的設計和編譯器的實現現在完全開源，有許多微軟之外的人參加，其中還包含許多完全由外部貢獻者構建的語言功能。這對C#有極高的價值，其中不僅有實現功能和修復bug的貢獻，通過開源提供的日常反饋，我們還能獲得及時的靈感和洞察。
這段旅程漫長又艱苦，而在我看來值得一提的是：微軟在過去十年內做出的巨大改變。Roslyn誕生於封閉，成長於開放，直到今天藉助開源之力在幾百萬用戶間綻放。
來親眼看看Roslyn和C#的語言設計吧：
- https://github.com/dotnet/roslyn
- https://github.com/dotnet/csharplang
原文：https://medium.com/microsoft-open-source-stories/how-microsoft-rewrote-its-c-compiler-in-c-and-made-it-open-source-4ebed5646f98
作者：Mads Torgerson，微軟的C#首席架構師。
閱讀更多 CSDN 的文章
