As a c# developer coming from the java world. I have taught myself to be better at reading the code then documentation. The only way to be really sure what is going on is to go to the signature and read the code. From that stand point having the source for a lot of the .Net framework libraries, would really improve my understanding of what really is going on with the program. Especially in the case of obscure bugs where you're just not sure if the framework classes are holding up their end of the bargain. With the incomplete and often buggy nature of the framework libraries, this is not as trivial as it might appear at first glance.
Competetive advantage is not created and sustained by semicolons and angle brackets, but rather through innovation and the ability to execute and maintain a strong vision.I'm sick of hearing this argument... it's so 90's.
I think you've maybe missed the Pink Elephant in the room. the transparency that would help most developers is the API, even the beaurocrats in the EU seem to grasp this singular point, sure some MBA will say that having hidden APIs for your own apps is a competitive advantage, the rest of the IT world looks at it and bells sound and people start exploring other software solutions, sure maybe you maximise some short term gains, but do you want to risk the medium and long term future of the corp?
From my own personal perspective, I couldn't care less about the source code for tools such as VS.NET - however, I do feel that the full source code for the various System namespaces in .NET should be made available as with the JDK.Moreover, they should be released under a completely non-restrictive license (possibly BSD style) so that projects like Mono and dotGNU could make full use of them.