Source code and managed runtimes
I am not an enemy of proprietary software. That shouldn't surprise anyone, as I used to work for Microsoft, but besides that, I've written heaps of articles and blog posts explaining what I consider to be the advantages of incentives created by properietary software.
On the other hand, I also have a healthy appreciation of the goals of open source software advocates (less so free software advocates, as they move beyond the practicalities into advocacy of absolute principles with which I disagree). Source code access, quite simply, is of tremendous use during development. If nothing else, it provides you insight into how the libraries you use in an application will perform, but combined with modern debuggers, provides a development experience that allows you to trace the full execution path, and thus really get to the root of problems.
It is, quite simply, a more productive way to code, which may explain why Microsoft decided to make the full source code available for the .NET Framework as part of Visual Studio 2008. Old news, to be sure, and the utility is patently obvious to regular inhabitants of the open source biosphere, but useful to people who prefer developing using Microsoft tools and technologies (as I do).
Of course, .NET naturally lends itself to a more open approach to software development due to its self-describing nature. Even before Microsoft made available .NET Framework source code as part of the debugging experience, Lutz Roeder's .NET Reflector was one of the more important tools in my development toolkit. I could take any non-obfuscated .NET assembly (more on that later) and decompile it to the language of my choice. My current copy of Reflector includes decompilation support for IL (the "native" language of a .NET assembly, which looks a bit like an object-oriented version of assembly language), C#, Visual Basic, Delphi, Managed C++, Delphi, and Chrome (a language based on Object Pascal).
That makes .NET assemblies a bit like input into universal translators. Granted, the output language has to have support for object oriented constructs, but it is possible to decompile an assembly into any .NET-compatible langauge you want. Quite interesting, and far more open than the native code past.
Of course, obfuscation can interfere with that open process. Obfuscation takes that self-describing code and mangles it in a way that decompilers like Lutz Roeder's can't untangle. Personally, I consider such things to be downright unfriendly. I have a strong incentive to rewrite and replace the obfuscated assemblies I run across.
Most .NET assemblies I use, however, don't go through the trouble of obfuscation. That's good, in my opinion. Personally, I have little interest in maintaining the code of a well-working component upon which I depend. I don't have time to become expert in all the technology areas related to libraries I use. For that reason, I'm not likely to want to do anything more elaborate with the source code I discover through decompilation (or the source code I get as part of open source projects, for that matter) than use it to assist me in debugging.
I do want, however, the ability to do my job effectively. Source code access is increasingly a part of that.
Microsoft has shifted from hiding the source code to protecting their rights over it via licensing. That's a good shift, and though it won't ever satisfy the demands of advocates for free software , it might satisfy those with a more utilitarian approach to the art of software development.