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.


Debugging


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.


Conclusion


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.