Starting the .NET Open Source Revolution

Today building open source software at Microsoft is normal — but when I started at Microsoft in 2007, it sure wasn’t. It took a few years to figure out the right thing to do and to get the big ship that is Microsoft turned into the wind of open source. But we’re there now and I look back on those early challenges with a smile. This is my story of the first successful open source project at Microsoft and how it paved the way to where we are today.

In the late 90’s I was at a startup called Mustang Software that built software for tracking whether all the emails that a company received were answered in a timely manner. Before the startup was sold in 2000, I took my team to Orlando for the Microsoft Professional Developer conference where ASP+ (which eventually became the ASP.NET web stack) and C# were introduced. My team and I installed the preview at the conference and I instantly fell in love with .NET. I continued to use ASP.NET in my subsequent jobs.

It was the blog posts of Brad Abrams and Scott Guthrie about Atlas that got me thinking that I would like to be a part of what was happening at Microsoft

Then in 2006, Microsoft set up CodePlex as a place to share source code. One of the original web projects on CodePlex was code-named Atlas, which is now called the AJAX Control Toolkit. Atlas was one of the first projects that Microsoft ever built that was open source and the conversations and interest around it were impressive. It was the blog posts of Brad Abrams and Scott Guthrie about Atlas that got me thinking that I would like to be a part of what was happening at Microsoft.

I responded to the blog posts by writing an email to Brad — and he responded within a minute! We talked the next day on the phone, and within a week I was on the Microsoft campus going through the interview process. Suddenly, I was moving from sunny California to the more temperamental weather of Redmond, Washington.

I joined Brad Abrams’ team, which was responsible for all of ASP.NET. It was also responsible for the brand-new Silverlight, an early attempt to bring native .NET development to the browser, which had just released as version 1. ASP.NET MVC was in the early prototype stage and was only shown internally, although occasionally used as a recruiting tool, working to great effect on Phil Haack, who joined the team in October 2007 . Scott Hanselman also joined Microsoft around this time, although he was on a different team.

It’s no secret that ASP.NET MVC was a response by the ASP.NET team to the huge surge in popularity by Ruby on Rails

It’s no secret that ASP.NET MVC was a response by the ASP.NET team to the huge surge in popularity of Ruby on Rails — started back in 2004 by the inimitable David Heinemeier Hansson as part of Basecamp. By 2007, Ruby on Rails had been included with the latest version of Mac OS X! The combination of the Model-View-Controller pattern with the scaffolding that was Rails dramatically cut down the amount of plumbing code that a web developer needed to write. It made making forms-over-data web pages delightful, and web developers loved it.

ASP.NET MVC was also a response to the criticism of ASP.NET Web Forms. ASP.NET Web Forms had been built to bring all those Windows Forms developers to the web — without having to learn too much. And it worked, there were a huge number of new web developers created with ASP.NET Web Forms. But after several years of development, it was apparent that ASP.NET Web Forms had its problems too: The process of hiding the nature of the web from developers meant some ugliness under the hood.

For example, the way that C# code and HTML intermingled on an ASP.NET Web Forms page made it very difficult to build unit tests. And without tests, maintaining and modifying a large website got more difficult over time. If you did create tests, they were largely functional tests exercising the UI — and even today, that’s a brittle way to build tests. Any changes to a web page were very likely to break all the tests for that page.

The early prototypes of ASP.NET MVC were impressive, enough that Scott Guthrie decided to show them publicly for the first time at the first ALT.NET Conference in Austin, Texas. The ALT.NET movement had come out of passionate developers who loved working with .NET, but thought that open source tools should be a larger part of the equation.

At that time in Microsoft’s history, Not-Invented-Here syndrome was rampant — there was a tendency to discount any software that wasn’t made by Microsoft

At that time in Microsoft’s history, Not-Invented-Here syndrome was rampant — there was a tendency to discount any software that wasn’t made by Microsoft. And the attitude was reinforced by a lot of customers who were happy to use only Microsoft-built tools. This approach came to a head when Microsoft announced that it was building its own Object-Relational Mapper (ORM) called Entity Framework. Advocates for other ORM solutions like nHibernate were annoyed that yet-another-ORM was being built, rather than supporting existing solutions. Those advocates became the beginning of ALT.NET, and by October of 2007, they were producing their first conference.

Right from the start, Scott Guthrie said that MVC would be open source

At the ALT.NET conference, Scott Guthrie gave the overview of ASP.NET MVC, showing it for the first time in public. Scott Hanselman demonstrated building controllers for MVC in IronPython and Phil Haack did a similar demonstration using IronRuby. Everything demonstrated was prototype code and wouldn’t ship in the form they were shown in at the time, but it was an interesting start to what everyone hoped was a new era at Microsoft. Right from the start, Scott Guthrie said that MVC would be open source.

In the same week as the ALT.NET conference, Microsoft had also “source opened” the entire .NET Framework as the Reference Source. Now you could step into the underlying .NET Framework code while debugging your application. It wasn’t open source as we know it today, but it was another step down the path to open source.

MVC, along with Silverlight, were also the first products from the web team to be released “out-of-band.” It was taking 24–36 months for each new version of .NET and Visual Studio to come to fruition — as much as a year each for planning, coding and fixing to ship. It was apparent that this cycle wasn’t fast enough for the web world anymore, especially for MVC. After all, Ruby on Rails was putting out a new version every year.

By December of 2007, we released a Community Technology Preview (CTP) of MVC that provided basic tooling (a project template) for working with the recently released Visual Studio 2008 and .NET 3.5. The CTP was the first version of MVC that anyone could download and start experimenting.

In February 2008, ahead of the Mix 08 conference, a new version of MVC called the MIX Preview Release not only added a bunch of features that people had been asking for but a ton of new tooling, including direct support for open source testing frameworks like NUnit and MBUnit.

After the Mix 08 conference, the source code of MVC itself was also made available to download, compile and use for debugging. It wasn’t what we would expect today, that is, the team committing the code to the repository as it was coded. Rather, the development of MVC happened internally and then a cut of the code was shipped to CodePlex.

Interacting with the public on CodePlex was an early experiment with transparency on the path to making true open source projects

Moving copies of the MVC code and interacting with the public around it on CodePlex was an early experiment with transparency on the path to making true open source projects, and there were a ton of concerns internally at Microsoft about it. The goal was to push up updates every few weeks, with the hope that someday it would be daily… someday.

It was around that time that we ran into an interesting problem. A key part of ASP.NET MVC is routing — being able to direct requests to a controller. The folks over at ASP.NET Dynamic Data were also using routing for their technology, and we had each built our own implementations. It turns out that Not-Invented-Here syndrome could even extend to individual teams! It took some time to abstract our unique aspects of routing away from the codebase and to get to one routing engine, at that time as part of System.Web.

A side effect of this process was also to create the Routing Debugger. It started out as a private tool to help us understand what was going on with the new shared routing model, and ultimately it made sense to share it out into the world as well.

Naming the code releases was also an interesting problem. The initial release of ASP.NET MVC was called a Community Technology Preview. After that, we changed them to Preview Releases, some numbered, some not. But even those couldn’t come frequently enough at first to keep up our goal of new code arriving at CodePlex every few weeks, so we did a Source Refresh. It was a bit confusing, but we were learning as we went — eventually, the Previews came quickly enough that the alternative names stopped.

By September of 2008, Preview 5 of MVC was out — which was awesome, but even more important was jQuery

By September of 2008, Preview 5 of MVC was out — which was awesome, but even more important was jQuery. Jon Resig had started the jQuery library back in 2006 as a compact set of open source tools to make working in JavaScript less painful and lots of the folks on CodePlex had been suggesting that MVC should take advantage of jQuery’s tooling. Incorporating jQuery was an amazing challenge for Microsoft — it’s one thing to use open source software, another thing to create open source software, but to include an open source library as part of your product? Crazy!

But it made sense to use jQuery. Much of the functionality that jQuery provided was going to be required to round out the features in MVC anyway. Why re-create the wheel (how’s that for a tone change)? And many of the different web products that we were making could take advantage of jQuery, so much so that Scott Guthrie announced on his blog that jQuery would ship with the next version of Visual Studio, which ended up being 2010.

The early version of Microsoft Azure was also out in the world at this point, and we experimented with making MVC work with Azure as a sample for the beta release of MVC in November — it was shown as a demo at the Microsoft Professional Developers Conference (PDC) in Los Angeles.

The Release to Manufacturing (RTM) edition of MVC, version 1 shipped at the Mix 09 conference in March 2009. We released the code on CodePlex with the MS-PL open source license. The license was quite short, and today is seen as similar to the MIT license (which is what Microsoft uses most of the time these days). The Open Source Initiative (OSI) approved the MS-PL license, but it was still controversial in some circles — why should Microsoft make its own license? What was hidden in it? Of course there wasn’t anything tricky in the MS-PL license, and it ultimately didn’t make sense to use it in the long run — MIT or Apache licenses served just as well. But internally at Microsoft, there were legal folks that were happier, not understanding the unfavorable optics of having a separate license for an organization.

Adding jQuery to Visual Studio 2010 did represent a new kind of risk as far as the legal team was concerned

Adding jQuery to Visual Studio 2010 did represent a new kind of risk as far as the legal team was concerned — what if there was code added to jQuery that had a GPL-type license included could impact the licensing of the rest of Visual Studio? Back then the fear around GPL’s “copy left” approach meant that legal folks saw it as “infectious.” Incorporating a GPL licensed piece of software into software with a traditional copyright (like .NET) would breach the copyright.

Today, it seems like these fears were overblown, but these were the legal folks that had dealt with situations like a lawsuit around some code that was accidentally included in Microsoft Word that caused the physical boxes of Word to be removed from store shelves everywhere in the world. That’s an incredibly expensive proposition — and in 2009, we were still shipping boxes of software.

An extensive procedure was put in place to mitigate the legal concerns around jQuery. Tools were built and used to test the pedigree of the source code of jQuery — tools would search through the code and check all the licensing. Only one time did we find a case where a contributor added some GPL licensed code — that the jQuery folks weren’t even aware of! jQuery is licensed for commercial use under the MIT license, and it made no sense to have GPL licensed code in it.

I got pulled into a conference call where I advocated strongly (some bad words were used) that we should not *ever* change the license of a third party open source library

Just before Visual Studio 2010 shipped, I got a call from one of the lawyers in the legal department — there was a legal opinion forming that any code, including jQuery, shipped in a Microsoft package, should be licensed with the MS-PL license. I got pulled into a conference call where I advocated strongly (some bad words were used) that we should not *ever* change the license of a third party open source library. It didn’t matter that MIT and MS-PL were remarkably similar — it was simply rude to change a license like that. It provided no meaningful benefit, and did significant harm to our reputation as supporters of open source.

Eventually our legal team embraced this open source journey and when Studio 2010 shipped, the bundled version of jQuery had its original MIT license associated. Visual Studio 2010 also included ASP.NET MVC Version 2, Silverlight 4 and a whole other host of great tools.

This release set the stage and became the role model project for how we do open source at Microsoft. When the ASP.NET team started planning a major new release that would be cross platform, it was only natural that we’d build it in the open in partnership with the community. Eventually that effort expanded to become .NET Core, and to our founding of the .NET Foundation to support open source collaboration on the .NET platform.

(To learn more about the history of the .NET Foundation, check out Beth Massi’s post Building an Open Source .NET Foundation).

It’s fun to look back and see how we experimented with open source, learned some lessons, and kept building on what worked. If not for those efforts then, I don’t think we’d be where we are today.

For more information on .NET, see our website www.dot.net