Opening up the .NET framework source code

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.

Security-sensitive code

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.

Performance/download/management worries

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.

General paranoia

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 🙂

10 thoughts on “Opening up the .NET framework source code

  1. IMO another reason not to open source code is compatibility.

    Imagine if .NET source code is open, you find bug there, do workaround and ship the product, in the next version bug gets fixed, and your app breaks.

  2. In Rotor, JIT compiler and Garbage Collector might be a little simplified but it’s fine by me. Stepping into the CLR might be overdose for daily project work but ability to debug Windows.Forms.* and such would be useful time to time. At least we got Reflector.

    IMHO, Rotor is the right step, and I don’t expect more from MS.

  3. there was a buzz last year from shawn burke of MS about shipping out debugging symbols, looked like it wasn’t approved by MS so lutz tool is still in use.

  4. Vadmyst: I don’t see how the problem you describe is made worse by opening up the source. If you run up against a bug in a framework at the moment, you still have to use a workaround – but it’s harder to *find* that workaround and report the bug.

  5. I agree with Jon — it would be really nice to have access to the source code.

    In another life, I was a Delphi developer. Borland shipped Delphi with (mostly) complete source code to their VCL (sort of analagous the BCL).

    It was great — you could set up your debugger to step right into the code.

    You did occasionally run into people who would try to change the VCL source to make some feature work in their application, but it was generally understood and accepted that modifying the Source was a Bad, Bad Thing.

    There were not any (many?? I don’t remember) comments in the code that Borland sent out — they probably ran it through a tool to strip them out.

  6. Opening up the code would also help me (actually the Mono project) with some problems I have with binary serialization within the .NET framework. Lots of objects that are serialized with .NET can’t be read with Mono because during serialization some private member variables are written as well. Having the source code available would make it easy for the Mono developers to add these variables to their classes as well.

    Of course one probably shouldn’t use binary serialization at all if you need portability.

  7. I think that the major problem would be there would potentially be thousands of version of the framework available then, too many to support in your app. At least this way you know the major releases come from Microsoft and people will have the same (or very similar) framework on their machines.

  8. Why would there be more versions of the framework available? That hasn’t happened in Java, where you can download the source code.

    Yes, someone could potentially compile a different version of mscorlib.dll etc – but they couldn’t sign it, and I doubt that anyone else would install it. It would be very easy to say that you didn’t support any version of .NET which isn’t from Microsoft.

Comments are closed.