• 微软的开源事业之旅
  • 发布于 2个月前
  • 141 热度
    0 评论
  • 向日葵
  • 1 粉丝 11 篇博客
  •   
现在在微软开发开源软件是很一件正常的事情——但在 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 平台的开源协作。

回首过去所走过的开源之路以及学到的经验教训,如果不是之前付出的那些努力,我们或许不会达到今天这样的状态。

用户评论