Microsoft Opens up the .NET Class Libraries Source Code

I read on Scott Guthrie's blog the news that Microsoft will release the source code to the class libraries that make up .NET:

Today I'm excited to announce that we'll be providing this with the .NET 3.5 and VS 2008 release later this year.

We'll begin by offering the source code (with source file comments included) for the .NET Base Class Libraries (System, System.IO, System.Collections, System.Configuration, System.Threading, System.Net, System.Security, System.Runtime, System.Text, etc), ASP.NET (System.Web), Windows Forms (System.Windows.Forms), ADO.NET (System.Data), XML (System.Xml), and WPF (System.Windows). We'll then be adding more libraries in the months ahead (including WCF, Workflow, and LINQ).

The source code is released under a new license they are calling the Microsoft Reference License, this is not an open source license.

First of all, congratulations to everyone at Microsoft that made this happen. Am sure many .NET developers will be happy with this new development and there will be many genuine uses for this.

I heard a podcast with Shawn Burke where he discussed some of the history of behind this move. The discussion seemed mostly tactical, and am sure that to do this they must have presented a strong business case to their management that opening up the access to the source code (even under the MS Reference License terms) was important.

Even if the license for the code is not open source, it is an important step. Sun had done something similar with Java in the past and over time they moved towards opening more and more of it. Am still hope that one day Microsoft will open pieces of this under more liberal licenses that would allow those pieces to be used for any purposes, including Mono.

Mono, free software and the source code release

The source code that will be released goes beyond the scope of the C# source code that was released as part of Microsoft Rotor.

But like Rotor, the license under which this code is released is not open-source. People that are interested in continuing to contribute to Mono, or that are considering contributing to Mono's open source implementation of those class libraries should not look at this upcoming source code release.

At the same time, Microsoft already releases some class libraries under an open source license, the Microsoft Permissive License (MS-PL, which will soon be renamed the Microsoft Open License).

Mono manages to benefit from code that Microsoft releases under the MS-PL license and we even redistribute some of it: The Dynamic Language Runtime, IronPython, IronRuby and the ASP.NET AJAX Javascript client-side library.

Speculation

Am not sure why Microsoft did this, there have been a few theories around this, but my own guesses are:

• Scott and many people reporting to him understand developers (Scott did ASP.NET). Scott being in charge of .NET probably has made this organization be more Web-y, in that they understand that developers are more effective if they can "View Source". So it might be a natural cultural shift.
  Scott and his team are behind the Microsoft/Novell collaboration on Silverlight for instance.
• Large .NET users probably already had access to the source code, and probably had access to under a myriad of customer-specific NDAs or licenses and this was hard to work with, and hard for the organization to manage. This could be license consolidation and streamlining of the process to get people access to the source code.
• Getting access to the source code alone was probably very cumbersome. This is probably why the focus of the release is on the simplicity of getting the source code for debugging (the most important scenario presented so far).
• Sun and Java: it is possible that some customers were getting cozy with the ease of access to Java source code to the class libraries and this had some mounting pressure on Microsoft.

Some of the statements are very similar to what Sun used to make about Java before they agreed to open source it:

Allowing developers to rebuild a framework, any framework, from source, and then redistribute the modified result, can introduce problems with providing support, serviceability, integrity and security of the framework itself. This is true with .NET, Java, Ruby, and other frameworks. Multiple independent redistributed modified versions of a framework can decrease the reliability and dependability of the common platform, which is not desirable. In the path we've taken here, we are seeking to balance the requirements we hear from the developer community for transparency and of reliability and dependability of the platform. In striking that balance, we believe the Microsoft Reference License is the right license for this release.

There are a number of scenarios that go beyond looking at the source code which are think are valuable in the existing Microsoft ecosystem and which is ultimately why it would be useful for some chunks to become open source.

For example:

• Bugs in Class Libraries: If there are bugs in the class libraries that can not be worked around, the user does not have to ship a replacement System.dll, but he could copy-paste the code, make the adjustments in the code and ship the resulting executable.
• Different Needs: If the code is close, but not quite what he needs, a developer could cut-and-paste, and then tune the code to do what he needs. This is a very common case that we see with Mono's own source code.
• Complement Existing Frameworks: Microsoft ships a number of reduced versions of .NET: Compact Framework and Silverlight 1.1. People often need features that are only available on the full framework.
  Many folks today cut-and-paste code from Mono to be used on the Compact Framework edition because the subset that Microsoft chose for the CF is a good starting point, but it does not fit all the needs, specially in a market that is heavily slanted towards embedded systems (our XML Serializer is one of the most cut and pasted pieces of code for example).
• Supporting old Frameworks: With 3.5 coming out it is very likely that some features would be useful for applications that must run with 1.1 or 2.0 on systems that can not be upgraded to 3.5. Cut and pasting code would be useful.
• Innovation: Although people can always innovate on "top" of an API, some kinds of new features can only be done if you can alter the inner workings of it. Certainly Microsoft has the right to not let people do that.

For the above cases, people today can continue to use the Mono source code and cut and paste at will (with our super-liberal license the MIT X11 that comes with no strings attached).

But I still believe that there is a good business case for opening more stuff under the more liberal MS-PL license.

And of course, beyond the Microsoft ecosystem, there is the Mono ecosystem, where we could leverage that code if it were open source :-).