Thoughts on ASP.NET MVC, ASP.NET Web API, and ASP.NET Web Pages (Razor) open source announcements
I'm really excited by the big announcements earlier this week:
- The source for ASP.NET Web API and ASP.NET Web Pages (Razor) were released under Apache v2 license
- ASP.NET Web API, ASP.NET Web Pages, and ASP.NET MVC (which was already released under MsPL license) will accept community contributions
I'm a big fan of both ASP.NET and open source, so it's exciting to see two of my favorite techy things hanging out at the same party. By now, you've likely read a few post with the actual details, very likely by one or more person named Scott, which contains some actual facts and some of the history. So here are a few recommended posts, followed by some additional commentary.
Must Read Posts
Scott Guthrie: ASP.NET MVC, Web API, Razor and Open Source
Scott Guthrie's announcement explains what's been released and how to get involved.
Scott Hansleman: ASP.NET MVC 4, ASP.NET Web API and ASP.NET Web Pages v2 (Razor) now all open source with contributions
Scott Hanselman's post is worth reading just for the animated GIF's, but he also describes some of the history and answers some common / likely questions, like
- Why are you doing this?
- Are you going to open source more things in ASP.NET?
- Why isn’t ASP.NET Web Forms open sourced?
- What about Mono?
- Why not on GitHub?
Phil Haack: ASP.NET MVC Now Accepting Pull Requests
Phil gives some good background on what was involved in making it possible for these products to accept external contribution. More on that later.
Jimmy Bogard: ASP.NET MVC, Web API, Razor and Open Source and what it means
I really like Jimmy's post. He starts off by clarifying that open source has never required accepting external contributions, then asks and answers some good questions:
- Will the quality of the product be adversely affected because the team accepts contributions?
- Will some yahoo be able to sidestep my current feedback channel and take the product in some other (wrong) direction?
- Will my pull request get accepted?
- Will someone else’s changes be supported?
- Are we in store for human sacrifice, dogs and cats living together, mass hysteria?
- Can we trust these products now?
- Is this a Good Thing?
- Why CodePlex and not GitHub?
I'm going to assume you're familiar with the above for the rest of this post. So here's what I think about this - and as a reminder, these are my own opinions, not Microsoft position or policy or whatever.
Source visibility - What's really changed
.NET framework has never been obfuscated. We all take that for granted, but it's been really useful to me throughout my .NET development career. Come to think of it, the Visual Basic 6 (and previous versions) source code wasn't available to me - and even if it had been, it wasn't written in Visual Basic so I wouldn't have been able to read it. So there are two nice things there:
- The fact that .NET and the frameworks built on top of it have always been available to decompile
- Just about all of .NET and frameworks, such as ASP.NET assemblies, are written in .NET so that they can be decompiled into something .NET developers can readily understand
Several times I week, I pop open ILSpy to either figure out or verify something about how ASP.NET works, often to answer a question that'd be really difficult otherwise. It's not that there isn't plenty of documentation available - there is - but often the best way to learn how code works is to look at the code.
While these are best disassemblers out there have been third party (e.g. Reflector, ILSpy, ), Microsoft's provided ildasm.exe from back in the .NET 1.1 days (maybe earlier?).
We've had symbols available, too, so we could debug directly into .NET source code as needed. You can point Visual Studio at Microsoft's public symbol servers and debug right into .NET source code in a couple of minutes.
And that doesn't even get into what IntelliTrace does if you've got a Visual Studio Ultimate license.
So, the point is that we've always been able to see the source code for pretty much anything most developers would care about. ASP.NET MVC moved things along by actually releasing the ASP.NET MVC code under an open source license, but other than maybe the Mono project, I'm not aware of anyone really taking heavy advantage of it. I'd personally be really happy to hear that I'm wrong here, but just haven't heard of people doing things like building custom versions of ASP.NET MVC.
So what's the point, then?
For me, as a consumer, code that's released under an open license gives me options and peace of mind. It lets me know that, regardless of what happens to the project, the source is available for me and other users to carry it forward. Several of my favorite open source applications are forks, and that's something I consider when I invest my time in learning a new framework or application.
So, back to the earlier question... if we've always been able to view the code, what's really changed?
Two big things:
- Much more visibility into the development process
- Acceptance of community contributions
Instant Visibility
You might think that, as a Microsoft employee, I have free run of the Microsoft source code. Or at least the .NET framework code. Certainly the ASP.NET code repository, right? No, I don't. I subscribe to the source control check-in e-mails, but I've historically kept up with what was going on by talking with the team and keeping up with announcements on the ASP.NET Insiders list.
But over time, that's become less of a thing. As Scott Koon said after the last MVP Summit, he hadn't really heard a single big surprise on what the ASP.NET team was working on... and that's a very good thing. The team's been very open as to what they're up to, what they're thinking about doing in the future, etc.
And this new open source change takes things to a new level there, because they're working in a public repository. So rather than waiting on big releases - or even pre-releases - anyone can watch the checkins as they happen. That's a big deal.
Accepting community contributions
Phil Haack's written some interesting posts recently on open source. His post listed earlier highlighted the difference between code that's released under an open source license and an open source project. As Jimmy Bogard points out, there's nothing about any accepted open source definition that requires accepting community contributions. Nobody would dispute that there are huge potential benefits to code and product quality if you can accept community contributions, but a decision that needs to be made by those who run the project.
But many of the ASP.NET devs run or participate in open source proects, so why wouldn't they just open things up?
Oh, it's stupid company politics and blasted lawyers. Well, that's the simplistic thinking, anyhow. Okay, fine, the devs would like things to be open, but pointy headed bosses ruin it. Oh, and it takes a long time to change minds and steer big ships or something. It's not that simple, though.
[Disclaimer: Personal opinions following. My whole blog is generally my personal opinions unless I say otherwise, but I want to make that really clear.]
Stepping back a bit - and speaking completely for myself, and not Microsoft or any future or previous employers here - businesses that sell some kind of intellectual property (as in they paid someone's salary to create something like digital media and software) need to be careful in giving things away, in ways you wouldn't expect. I have several relatives and close friends who make or have made their livings as musicians, and have explained that it's possible to do something wrong and suddenly your hit becomes public domain and your kids don't go to college. It's the same kind of thing with software - companies that want to give things away need to navigate a complex (bizarre?) legal system that handles intellectual property in non-intuitive ways.
Phil Haack's blog post (ASP.NET MVC Now Accepting Pull Requests) spells this out well:
I also want to take a moment and credit the lawyers, who are often vilified, for their work in making this happen.
One of my favorite bits of wisdom Scott Guthrie taught me is that the lawyers’ job is to protect the company and reduce risk. If lawyers had their way, we wouldn’t do anything because that’s the safest choice.
But it turns out that the biggest threat to a company’s long term well-being is doing nothing. Or being paralyzed by fear. And fortunately, there are some lawyers at Microsoft who get that. And rather than looking for reasons to say NO, they looked for reasons to say YES! And looked for ways to convince their colleagues.
I spent a lot of time with these lawyers poring over tons of legal documents and such. Learning more about copyright and patent law than I ever wanted to. But united with a goal of making this happen.
These are the type of lawyers you want to work with.
Five years ago (long before I worked at Microsoft) I wrote a blog post titled Why Microsoft can't ship open source code which talks about some of the risks a company takes on in shipping code they didn't write:
To understand the code pedigree problem, let's talk about the nightmare scenario. Let's say Microsoft took my advice and shipped Paint.NET as a Windows Vista Ultimate Extra. Unbeknownst to Microsoft - or even the Paint.NET project leads - a project contributor had copied some GPL code and included it in a patch submission (either out of ignorance or as with malice aforethought). Two years later, a competitor runs a binary scan for GPL code and serves Microsoft with a lawsuit for copyright infringement. Microsoft is forced to pay eleventy bajillion dollars and damages. Perhaps even worse, they're hit with an injunction which prevents selling the offending application, which requires recalling shrinkwrapped boxes and working with computer vendors who've got the software pre-installed on computers in their inventory. All for shipping a simple paint program.
So, the risk is too great to justify the small reward.
The point is that, while there are obvious benefits to a company in shipping source code they didn't write, there are risks and costs. There's a good chance that your company doesn't open source all (or any?) of the software you write for these reasons. It's not necessarily because the company leadership / bosses / lawyers are stupid or bad, it's because it's a hard problem.
This doesn't even get into all the other costs, like the time and effort required to support (or continually explain why you don't support) unreleased code, review pull requests, move from systems that work really well internally to systems that are externally visible and accessible, move from source practices that have been optimized for a centralized team to an open source model, etc.
So I for one am profoundly thankful to all those who have done the work to get things worked out legally to both technically.
Where Next?
Lurking
The simplest way to take advantage of this is to watch changes on the live repository. It's easy to see what's being worked on by watching public pages:
Using
If you're interested in using code from the live repository, there are some directions here: http://aspnetwebstack.codeplex.com/documentation. A couple notes:
- The directions show how to get the source code using a git client, which is a good idea if you're going to contribute back. If you just want to use the code, you can download a zip of the latest source (or any changeset) using the Download link on the Source Control tab.
- Make sure you note the SkipStrongNames step which lets you run unit tests against delay-signed binaries.
- If you're using Visual Studio 2010 SP1, the Runtime.sln handles package restore. If not, you'll need to follow the build.cmd directions to handle that.
Contributing
The first thing that often comes to mind when talking about contributing to an open source project is with surprise deliveries of random code. I've found - after having participating in a lot of open source projects - that is not the best way to get involved in any project. The team's listed some good ways to get started, including bug reports and contributing tests. I try to do this kind of thing on projects I'm getting started with - it's a good way to get familiar with the source code and the way the project's run, which is an important first step.
Miguel de Icaza has a great post on Open Source Contribution Etiquette which is great background on how to get started in contributing to a project.
If you want to contribute code, the team has listed some important steps. The whole list is important, but I want to point out one that thing - the Contributor License Agreement. It's a pretty short form (11-12 blanks to fill in, including date and signature) that essentially (I am not a lawyer) says who you are and that you're granting the rights to the code you're contributing.
Oh, and if you're interested in contributing to Mono, they're looking for some help in integrating this new code.
Exciting times!