微软是如何使用C#重写C#编译器并将其开源的
Roslyn是C#和Visual Basic.NET开源编译器的代号。这篇文章将介绍它是如何从微软过去的十年至暗时刻走出来，成为开源跨平台的C#和VB公共语言引擎。
我于2005年加入微软，也就是在 .NET 2.0发布之前，当时微软内部已经开始在讨论Roslyn项目，这个项目是关于使用C#重写C#编译器。这对于一门编程语言来说是一件很正常的事情，证明语言已经开始成熟。但我们的动机则更为实际：作为C#的创建者，我们并没有使用C#编程，而是用C++！
要重写一个用户已经使用了好几年的编译器，关键问题在于用户会希望新编译器的行为方式与旧编译器完全相同。为C#开发新的编译器意味着需要匹配旧编译器的缺陷。我说的不只是已知的缺陷，也包括那些未知的缺陷，以及开发人员已经发现并严重依赖的无意识行为，这些通常是在不知情的情况下发生的。
多年来，这些挑战导致我们无法开始这个项目。
虽然使用C#编写新的C#编译器会给语言团队本身带来很多好处，但这样能给用户也带来价值吗？新编译器如何给现有的用户带来帮助？也许唯一关心是否使用C#编写C#编译器的人就是编译器开发团队本身。
但与此同时，我们面临着另一个越来越严重的问题：基于C#的不同工具之间的存在大量的重复性工作。除了编译器，我们的姐妹团队在为Visual Studio提供C# IDE支持，他们必须通过编写大量的代码（他们当时主要也是在用C++）来理解C#的语法和语义。
除此之外，还有很多来自微软和其他公司的工具，如StyleCop、CodeRush，等等。这些工具都需要实现与C#源代码文本相关且对用户来说有意义的功能，并且都存在一些微妙的错误。它们对一些概念的理解处于不同的水平上，而且需要做出不同的折中和权衡。所有人都需要花费大量的精力来理解代码。
最后，我们提出了我们的价值主张：我们只需要一个C#代码库，并把它共享给任何一个想要基于代码库构建工具的人！可用工具的增加将给用户带来价值，特别是现有工具质量的提升。我们将语言正确性和性能方面的需求集中在同一个代码库上，并努力提升质量以及添加大量的功能。我们将会构建出一个语言引擎！这将为C#代码提供统一的公共API：我们将重新定义“编译器”的含义。
当然，既然你在为C#社区构建API，它就应该是使用C#实现的 .NET API。因此，使用C#“引导”C#的老想法借助这个机会得到了实现。
可以说，Roslyn的诞生就是始于这种开放的心态：向世界开放C#语言的内部开发工作。在微软的封闭文化中，这本身就是一个大胆的主张：我们会免费分享这个知识产权吗？我们会助力那些工具开发商更好地与我们展开竞争吗？
我们希望增强生态系统并成为世界上最好的工具语言的想法最终赢得了胜利。我们想要的是C#和.NET的长期增长，而不是为了短期变现和保护微软资产。因此，虽然说不上是开源，承担Roslyn项目的成本和风险对于微软来说也是一个重大的抉择。
当然，你不一定只是构建这些东西。Roslyn有着雄心勃勃的愿景，充满了技术挑战，我们花了五年时间才实现。
在我们构建初始版本时，Roslyn仍然是一个闭源项目。从2009年项目启动以来，我们一直希望我们的编译器是开源的，但微软还没有为开源做好准备。开发私有代码并提交专利的文化代表了微软自20世纪70年代以来的工作方式——虽然变革已经在悄然发生，但速度比我们团队所希望的要慢。
事实上，曾经有一段时间，我们感觉公司正朝着完全相反的方向发展。
Windows 8项目几乎占据了整个公司的资源。因为采用了新的编程模型，其触角已经触及到开发者工具和语言团队的内部，所有的东西都被极端地保护起来，而且不仅仅针对外部，甚至也针对公司内部。例如，我们当时开发的异步功能融合到Windows 8的编程模型中，我甚至不敢在内部发表设计说明，因为担心会意外泄漏有关Windows 8的信息让自己陷入麻烦之中！这给创新造成了一个糟糕的环境，对于我们开放C#编译器的愿望来说，这当然不是什么好兆头。
最终，在Windows 8步入正轨之后，微软开始转型并找到了新的方向。它的核心理念变得与原来完全不一样了，也就是我们今天所知道的微软。开源运动现在开始在微软内部占据一席之地。
F#已于2010年发布，基于开源许可，并提供了自己的基础——F# Software Foundation。围绕它而成长起来的一个充满活力的社区让我们所有人都感到羡慕。我们的团队强烈要求为Roslyn提供开源许可，最后，在公司范围的出现了一个致力于实现这一目标的基础设施。
2012年，微软成立了Microsoft Open Tech，一个专门关注开源项目的组织。Roslyn转到了Microsoft Open Tech之下，并正式成为开源软件。Roslyn是一个非常适合开源的候选项目：开发者都是内部有名的开发者，而且项目本身很独立，没有太多的依赖，不太有可能造成许可冲突。
2014年4月，在旧金山举行的微软“Build”开发者大会上，Anders Hejlsberg将Roslyn作为开源项目进行展示，并于4月3日基于Apache 2.0许可发布在了CodePlex（微软之前的开源托管平台）上。
与此同时，.NET Foundation成为包括Roslyn在内的.NET项目的家。
开放为微软带来了是一股清新的空气！在我们开始从CodePlex的开放性中获得好处的同时，微软也理顺了其余的开源障碍。今天，开源已经成为我们团队工作的一个直接且不可或缺的部分。
此外，在其他方面，微软意识到我们不需要控制一切。很明显，我们可能不需要CodePlex了，Roslyn加入到了从CodePlex迁移到GitHub的项目行列，GitHub是当时事实上的开源之家。不仅仅是源代码，就连构建过程都搬到了GitHub上：它不只是个发布代码的地方，我们把它当成工作的地方。
C#语言设计和编译器实现的流程现在是完全开放的，有很多微软以外的实体或个人参与，包括由外部贡献者构建的全语言功能。C#的价值是巨大的，不仅仅在于通过添加新功能和错误修复来发展项目，还包括我们通过开源提供的即时反馈闭环来获得见解和发展路线修正。
这是一段漫长而疯狂的旅程，在我看来，这是微软在过去十年中所经历的一个巨大的变化。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