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