Earlier this week Microsoft announced that they would be releasing the .NET Framework code (and later, libraries like WPF and LINQ) to the public in a quasi-open source model under the Microsoft Research License (MS-RL). In short, it grants developers access to the source code for 'reference use,' which Microsoft defines as:
... use of the software within your company as a reference, in read only form, for the sole purposes of debugging your products, maintaining your products, or enhancing the interoperability of your products with the software, and specifically excludes the right to distribute the software outside of your company.
So there won't be any (legal) forks of the .NET Framework, for instance. Another hallmark of open source software is developer contributions. The idea is that if a developer spots a bug, she can correct it and submit a patch that can then be reviewed and integrated into the open source product. At this time, Microsoft is not offering any sort of ability for developer-submitted patches. Instead, feedback is to be directed to Microsoft through a feedback web page.
This announcement, by itself, isn't really anything new. After all, the .NET Framework libraries are unobfuscated and their source code is viewable through disassemblers like Reflector. The real news here is that this code can be seamlessly integrated into the Visual Studio 2008 debug-time experience. Scott Guthrie details this capability in his blog entry Releasing the Source Code for the .NET Framework Libraries. In short, you can configure Visual Studio 2008 to point to a URL that provides the debugging symbols and code for the .NET Framework. With this configuration set, you can step-into the .NET Framework source code directly from within your application, enjoying the same debug-time user experience and functionality.
This functionality is pretty neat. Sure, you can do the same thing through Reflector, but in doing so you have to hunt and peck through the code in Reflector. With this new feature in VS2008, you can step through the actual lines of code and use debugging windows like the Call Stack, Locals, Watch, and so on. But this is no panacea: if you find a bug in the framework code or if you find some internal behavior you'd like to change, you're still out of luck. It's not like you can go and modify the framework library code. Moreover, it's not like internal .NET Framework methods will now magically be accessible to external programs. But it will simplify understanding what's happening underneath the covers of the framework and will hopefully encourage more developers to roll up their sleeves and poke around in the bowels of .NET.