For a long time, I've believed that Microsoft should open up the source code to the .NET framework – at the very least, the managed parts of the standard library, and preferrably most/all of the unmanaged part of the framework and even the CLR itself. As Sun gradually works its way to making Java more fully open source, MS should at least make the source available to the same extent that Sun has made the Java standard libraries available for years. This is not the same as making the framework an Open Source project, of course.
Reasons to open up the framework
Exploring implementation details
MSDN is generally very good, but every so often it's either ambiguous or just plain wrong. Sometimes it makes sense for documentation to be ambiguous – it allows behavioural changes later on – but sometimes you really need to know what the behaviour will be, even if you're only guaranteed that behaviour for the current version. (At that point, a request for the behaviour to be more fully specified is a good move.) Having the source code available makes this exploration possible – as well as enabling those who answer questions about the framework to give answers based on more than just experimentation.
Sometimes, it's just not clear why code is behaving the way it does. Much as I dislike having to use a debugger, it's unavoidable at times. That's okay so long as you can actually debug all the code which is in question. If a framework method is behaving in an unexpected manner, it can be very hard to work out why. Being able to debug with symbols available has often been helpful to me in Java, and I've often wished I had the same ability in .NET.
Understanding and reporting bugs in the framework
The .NET framework isn't perfect. Every so often, there are bugs, and that's completely understandable. It would be frankly remarkable if the framework didn't have any bugs. However, even when you think you've found a bug, it can be an awful lot easier to demonstrate and reproduce in a guaranteed fashion if you've got the source code available. That can make it easier for Microsoft to fix it, and it's also easier to work round it for the time being.
People are reading source anyway with Reflector
Lutz Roeder's Reflector is fantastic. It's a disassembler/decompiler for .NET code. Admittedly it's the kind of tool that scares people into obfuscating their code, when it's usually an unnecessary hurdle which makes life harder for developers but not that much harder for pirates. However, it means people can dive into the framework when they need to. They can't debug into it, or read comments, or see local variable names – but they can check out what's going on in a fashion. If MS cares about this sufficiently little that they don't obfuscate the code, why not make it available in a more developer-friendly manner?
That leads me to what I suspect may be the other side of the argument…
Reasons not to open up the framework – and counter-arguments to them
Commercially sensitive code
It's possible that Microsoft have some really clever code in the framework. I'm sure there's quite a lot of clever code there, actually, and I'm sure it took more man-hours to write than I really want to think about – but I doubt that there's much in there which is sufficiently novel that it would give competitors much advantage. If there is any code in there which is so secretly wonderful it mustn't be discovered, it can still be read with Reflector – unless it's been selectively obfuscated. If it can be selectively obfuscated, no doubt it could be selectively left out of any source code distribution. I suppose that would be painting a bit of a target, but it wouldn't be hard to check the class library for obfuscation.
Maybe there are bits of the framework which really aren't as secure as they should be, and MS is worried that if people can see how everything works, they'll work out how to crack it, too. That's security through obscurity – and it's generally not a good idea. I really hope this isn't the reason. (I'm kinda hoping this blog is being read by a few Softies who might be able to explain what the real reason is.)
Unprofessional or negative comments
Developers can occasionally have a bit of a giggle in comments – and other comments may well point out bits of code which need further work. Both of these could raise a few eyebrows in manager-land, even if most developers would understand it's a normal part of life. There are ways round this though – strip comments for the first "drop" of source code, then gradually put them back in, for example. Leaving the useful comments in would be lovely, of course, but code without comments is better than no code at all.
Downloading the source would take a long time. Downloading the symbols may take a long time. You'd probably need a different copy of the binaries with debugging enabled (I can't remember the details off-hand). You'd need to be able to pick whether or not you wanted to use the source when launching a debugging session. All of these are things which would cost MS some time to get right – but they're not that strapped for resources.
This sounds like the most probable reason in my view. Opening up source code makes managers (and those above) nervous. Heck, it would probably make me nervous too. There are natural fears about letting people see the details of code when they've been able to treat it as a black box for a while. However, the benefits to developers are pretty huge in my opinion. It's worth facing that fear and examining the issue carefully. It would probably be instructive to see what Sun has lost through making the source code for most of their Java implementation available.
I'm not expecting to see MS open up the framework code any time soon. I think it's a pity, but life's full of disappointments. Maybe people inside Microsoft are lobbying for it too – I really don't know. Maybe I'm the only Java/C# developer who really misses having the code available when working on .NET. Maybe you'll let me know in comments