A Journey Into the Dumb-o-Sphere

It did not take long for the IT pundits to declare that having the source code available for .NET is either "a trap for Mono", "the end of Mono" or some similarly low accuracy per bit arguments.

It is amazing though, as some of these pundits are supposed to be covering "free software" and "open source" and yet, they know very little about history and how open source software is actually developed. More worrying is the fact that they could have researched this instead of sticking their foot in their mouth.

I was not going to blog about this, hoping that this would just go away, but I keep getting emails asking about these articles (which am not going to link to, you can google them up):

Lets look at Pundit #1:

Thanks to Mono, we now have the popular Linux programs such as the Banshee music player, Beagle search tool and F-spot photography program. With Mono, you can also now run Visual Basic programs on Linux. Mono is also working on porting Microsoft's Silverlight 1.0, a cross-browser, cross-platform plug-in for delivering richer Web user experiences in a project called Moonlight.

All of these programs are now in danger from Microsoft.

I know, I know, if you just look at the headline, the executive summary, "Microsoft opens up .NET," it sounds great for Mono open-source developers. It's actually a death trap for Mono.

No, it is not a death trap for Mono.

It seems that Pundit #1 needs a history lesson on free software.

When GNU was launched in 1983 there were concerns similar to this one. In particular, a concern was what would happen to people that contributed code, but the code came from the wildly available proprietary source code?

To put things in perspective, at the time, Universities were getting source code licenses to ATT's Unix and it was wildly available (by the 1980's standards of availability). It was important that contributions to GNU were not tainted by proprietary code that belonged to someone else.

I quote section 2.1 of the GNU Standards document on this matter:

2.1 Referring to Proprietary Programs

Don't in any circumstances refer to Unix source code for or during your work on GNU! (Or to any other proprietary programs.)

If you have a vague recollection of the internals of a Unix program, this does not absolutely mean you can't write an imitation of it, but do try to organize the imitation internally along different lines, because this is likely to make the details of the Unix version irrelevant and dissimilar to your results.

For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. You could keep the entire input file in memory and scan it there instead of using stdio. Use a smarter algorithm discovered more recently than the Unix program. Eliminate use of temporary files. Do it in one pass instead of two (we did this in the assembler).

Or, on the contrary, emphasize simplicity instead of speed. For some applications, the speed of today's computers makes simpler algorithms adequate.

Or go for generality. For example, Unix programs often have static tables or fixed-size strings, which make for arbitrary limits; use dynamic allocation instead. Make sure your program handles NULs and other funny characters in the input files. Add a programming language for extensibility and write part of the program in that language.

Or turn some parts of the program into independently usable libraries. Or use a simple garbage collector instead of tracking precisely when to free memory, or use a new GNU facility such as obstacks.

(Emphasis added).

Now, Mono is an open source project and follows those rules (and I have followed those rules myself since 1992 when I first started writing free software).

If only reporters had a way to find out this information, some kind of wizard that they could use to fact check their pieces...

[Ziing!] Hi! Am the Great Gazoogle!

Oh hi, Great Gazoogle. Say, what’s this?

Mono Project -- Contributing -- Important Rules

• If you have looked at Microsoft's implementation of .NET or their shared source code, you will not be able to contribute to Mono.
• In general, be careful when you are implementing free software and you have access to proprietary code. We need to make sure that we are not using someone else's copyrighted code accidentally.
• Do not use the ildasm, reflector or other equivalent tools program to disassemble proprietary code when you are planning to reimplement a class for Mono. If you have done this, we will not be able to use your code.
• Please stick to published documentation for implementing any classes; when in doubt, post to the mailing list and discuss the possible approaches with others.

This text was originally added before the launch of the project, as indicated by the Great Gazoogle:

[Zeerp!] "I looked it up, this horse was beat to death on the mailing lists!" says the Great Gazoogle.

The Great Gazoogle can be used to identify other times when we the issue of Rotor, SSCLI and Mono has come up in the past.

We go even further than that. We do not even accept LGPL contributions to our own class libraries, we use the MIT X11 license for that, and as such we are unable to incorporate changes that were developed as LGPL or GPL with exceptions (which is why we could not work together or accept patches from pnet folks unless they relicensed their code).

So we do not take proprietary code, and we do not take open source code that is not suitably licensed to be included in Mono itself.

A similar situation existed forever for Java. Java was only open sourced less than a year ago, but before it became open source, the source code for Java was wildly available for anyone that wanted to look at it under a non-open source license.

Obviously open source efforts --GNU Classpath, the older class library project and the various open source Java VMs-- could not accept contributions from people that had looked at Sun's code.

And of course, there was Rotor. Rotor was Microsoft's first attempt at giving developers some access to the source code of .NET. Rotor used a Shared Source license instead of MS-RL that prevented people from using its source for commercial purposes (so just like this new release, it is a non-stater for Mono).

Rotor differs also from the upcoming release in that Rotor contained the source to the C# compiler and the virtual machine and this release does not. But Rotor did not include the "major" class libraries like ASP, ADO and Winforms that are included in the upcoming release.

So the doomsday scenario has existed for as long as 24 years for free software, but Pundit #1 just thought of this scenario all by himself:

If you ever, and I mean ever, want to write open-source code, I recommend you not come within a mile of Microsoft's .NET Framework code or any other similar projects that the boys from Redmond "open" up.

To be fair though, it is an important warning, and it is good that this is kept in mind by anyone contributing to open source software.

Now lets look at Pundit with an Axe to Grind (referred to from now on as Pundit #2). Pundit #2 likes to setup a strawman, but he does so in a careful way, with plausible deniability, look at this carefully crafted piece:

If you believe some of the headlines, Microsoft just open sourced a bunch of software related to its .Net libraries. Don't be fooled. The definition of open source is very clear. This is not open source. Not even a little bit. In fact, this may actually be an insidious trap (more on that below).

Microsoft never claimed they were open sourcing anything in .NET. They do not even use that language. Am not sure where the rumor that it was open source started, but clearly people did not even bother reading the actual announcements from Microsoft, because such text is nowhere to be found. You would think that in this day an age they could have done a quick check. But alas, when you got an Axe to Grind the axe comes first. Facts and research come last.

Some creative uses of the Axe (I had to use the great Gazoogle to get the "joke"):

Far-fetched? Well, not if you look at Microsoft's history. Microsoft is playing to win, and it seems to believe the only way to win is if open source loses. This is myopic, but the company refuses to get LASIK.

Do you get it? LASIK: so you can fix the myopic view!

So this is a pundit that repeats and quotes the claims from Pundit #1 (the guy that did not know history) and invokes history. To be fair, he is a pundit, his depth of knowledge is razor thin.

In my opinion, Pundit #2 is failing at both punditry and humor.

Credits: Great Gazoogle artwork and concept originally from Gavin M. at Sadly, No!.