Unfortunately they are licensing it under "Microsoft Reference License" which means read-only access. While not the ideal access mode, I think its certainly a step in the right direction. A little bit at a time, and sooner or later Microsoft might actually embrace open source. ...Maybe.

Right, I don't think Microsoft is open (pun intended) to just anyone modifying their baseline code. It's almost as good, but if you've got access to base class code for instance, instead of extending a class you could instead grab the base code and strip out all the crap you don't need (which is more often than not, quite a bit).

It's a great start.

You seem to be suggesting that Open Source projects allow just anyone to modify their code.

Nobody is open to just anyone modifying their code, whether Open Source or proprietary.

Random people from the internet cannot have their code accepted into the Linux kernel, Firefox, GNU, Java, Ruby, or any other popular Open Source project. They do not have commit access, and the people that can commit code vet contributions quite extensively.

The only group who suggests otherwise is Microsoft - I'm surprised your comment has been moderated up.

Although commits to central repositories of os projects are guarded, open source means that random internet users can take the source and modify it as they like for their own personal use (as regulated by whatever license they've chosen). The ms license is read-only (according to the parent comments; I haven't read it) and so is not open source, by common-usage definition.

I don't think jkush was talking about personal use.

Jkush: "Right, I don't think Microsoft is open (pun intended) to just anyone modifying their baseline code. "

Clearly Microsoft wouldn't mind at all if someone modified the code for their personal use, as it wouldn't affect MS - the user would have an obviously unofficial version of whatever.

It seems the parent poster is implying that 'just anyone' could modify the actual mainline source code of an Open Source app. This is consistent with past statements from Microsoft about Open Source, usually along the line of "anyone can add code, you don't know where it comes from". Both are incorrect.

I'm not typically a Microsoft basher but this isn't a big deal. The .NET source code has always been available via Reflection. Download Lutz Roeder's Reflector, disassemble one of the classes shown in the blog post and compare the disassembled code with the screenshots. Having access to the set of debugging symbols and code commentary is obviously a good thing however.

I think this is a big deal for two reasons: it signals that Microsoft is starting to open up a little and the other reason is that getting code definition information through an IDE like Visual Studio is vastly superior to disassembling a .NET framework dll and inspecting the code.

No it's not. Reading CIL code in the Reflector is often better than reading it in Visual Studio: the Reflector is an amazing little tool with one of the best integrated cross-referencers I've used.

I'm guessing you've never actually used it, because you're using the word "disassemble" to describe it. Like JVM bytecode, CIL is unambiguous, explicitly typed, and doesn't rely on aliasing; therefore, like JVM bytecode, it is easily reversed back out to a high level language. You're not reading CIL opcodes in the Reflector, you're reading C#.

I wonder if this is a valuable lesson for developers here. Bytecode VMs do not offer strong protection of your source code.

This is actually tremendously useful despite the fact that it isn't Open Source. Being able to view method implementations in the debugger will be a boon to performance, and will definitely remove a lot of guesswork.

Excellent - it will pretty much eliminate toggling between reflector and vs.net! This should greatly improve the blog post quality, documentation, books, and community feedback related to .NET.

This seems a bit out of character for Microsoft, doesn't it?

Not really. First, they have very little to gain from keeping .NET closed: there are strong open-source replacement projects for the "proprietary" framework classes, and .NET assemblies don't really protect source code, even when obfuscated.

Second, even if that weren't true, opening things up is actually not out of character for MSFT, despite the conventional wisdom. For instance, you can download near-complete debug symbols for the underlying operating system. If you've ever read assembly with and without PDB files in IDA Pro, you know what a big deal that is.

2 words: too late.

To me it seems much more motivated by desperation than by conviction.

In about 5 years we will see all of Windows(R) source code released, but again, it will be too late...