Today, before lunch Aaron, David, Jeff, Michael and myself went to the Carboard Regatta at MIT, the Head of the Zesiger competition.

A perfect complement for the Head of the Charles this weekend. Here are some cell-phone pictures of the event:

The Black Pearl:

The winner was a cardboard boat called "Ship Happens" that looped the swimming pool twice without sinking. All other boats sank. The "Titanic" award was given to the "Unsinkable 2" ship.

Here is "Ship Happens":

Everything sank, except for "Ship Happens". I suspect that the cleaning crew was as surprised as I was to see one of the boats disintegrate so quickly into so many little pieces that went to the bottom of the pool.

For people interested in JIT technology, there are two great posts this weekend from folks in my team.

JIT engines have some great properties, but unlike batch compilation they suffer from having to cope with code generated dynamically. Paolo talks about the memory reduction tricks that he has implemented in Mono.

The tricks are related to the temporary thunks that are generated during JITing ("trampolines"), and some future directions to reduce memory usage in the JIT even more.

Mark talks about his ongoing work to implement generic code sharing. Unlike Java generics that are a language feature, .NET generics are a virtual machine feature. Each approach has its pros and cons. In Java you only JIT the code once, and every generic instantitation reuses that implementation (because it is really a language feature); The .NET approach makes for simpler use or generics and better performance, but it comes with a price: new instantiations of the generics class need to be re-JITed.

Mark discusses his ongoing work to share generics JITed code (when two instantiations of a generic type would generate the same code, say when the sizes and semantics of the types are compatible).

On Monday I joined Brad on stage at the Boston Remix conference to show a preview of Moonlight.

As you can imagine, after years of working on Mono, I was pretty excited to be able to show our work at a Microsoft event.

Brad blogged a summary of all the things that he showed on his keynote here. I was familiar with some of the stuff there, but there were various new things, like the ComponentOne controls for Silverlight 1.1 (they are similar in spirit to Flex: you get some high-level controls that you can use with your Silverlight applications).

Videos of the keynote have been posted, see this page for the videos. The Moonlight section is covered here.

I was running development versions of both Mono and Moonlight (SVN as of 24 hours or so) and you can see that some of the performance tuning that has been going into the Mono runtime (Paolo has not blogged about it, but Mono 1.2.6 will have plenty of performance improvements in the JIT and the memory consumption keeps going down).

I showed the Chess game and you can see from the numbers that Mono running Chess is now getting similar scores as the .NET runtime gets on similar hardware.

Brad also gave us a copy of TopBanana in advance, and everyone in the team worked hard to get it ready for the show:

Lastly, I got a chance to show the Compiz Cube to the audience while playing some videos with Moonlight from the Halo web site.

It was the old cube, the one that we shipped with SLED, but still it makes for a good demo. On my Tuesday session, I borrowed a machine that had more up-to-date software to show the latest Compiz.

Q and A on Moonlight

On Tuesday I had a session on Moonlight (the slides are here).

One of the problems that I face with my presentations is that am not good at transitioning from the presentation to the questions and answer part of it. I always enjoy the questions and answers more than the presentation, and somehow I always botch it by reaching the end and asking "Questions?".

This presentation was quite fun, because the audience asked a lot of questions as I did the presentation which made the presentation a lot more interesting than the slide deck shows.

This was mostly a Windows audience, and I took the chance to show them the Linux desktop, the Mono/.NET compatibility, the MonoDevelop IDE, showed internationalization on Unix, the automatic right-to-left support and automatic layout of desktop apps and a few other features of Mono-based apps on Linux.

Silverlight Performance

On Sunday I had the chance to meet Seema Ramchandani who is a performance PM on Silverlight. On her blog she has some useful hints on how to improve the performance of your Silverlight apps (here and here).

We will be holding the Mono Summit in Madrid Spain, from the 26th to the 30th of November. Five days of Adventures in Open Source Managed Code and tapas sampling.

The first two days are focused on project planning and discussion among the active contributors to the Mono and Moonlight projects (contributors and employees).

The second three days are more general, these are for users of the Mono project: the application developers. In these days we will have some talks and tutorials on what we have been doing, what is available since the last year, meet-the-experts discussions and to present our roadmap and plans that we discussed in the first two days.

This is a good time to introduce a gorgeous Moonlight logo that was designed by Tony Alexander and Miguel Liberero on the Mono-Olive mailing list.

I will be working on an agenda in the next few days and post it next week on the Mono web site.

Alejandro Sanchez and Juantomas worked very hard to look for our venue, it was tricky to schedule in the original dates that I had planned ("sometime in October"). Thanks Alejandro and Juantomas!

Update Booking: Jonathan suggests that booking Sunday-to-Sunday gives you good prices, better than Saturday-to-Saturday, I have not checked.

I have been using Kayak.com myself to book trips recently, and it is my favorite so far.

Mark Pilgim shares his opinion on his managed expectations on the iPhone.

Love the post, worth reading from top to bottom.

But what is really interesting is that the majority of the replies to that post are incredibly insightful, worth reading as well. How does Mark manage to get this much of an educated audience?

Update: correction, as you keep reading the blog, the crazies come out of the woodworks. I guess we are doomed.

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!.

Mike Kestner has been working for the past few months in supporting GLib's GInterfaces in Gtk#. He has commited his code, and written a tutorial.

There were two main use cases that people discussed with us:

• The need to implement new Gtk TreeView models.
• The need to support interfaces for the sake of Atk.

Am not sure if there are any other uses for this.

If you have experience with GInterfaces, we would love if you could send us some comments (Mike Kestner) about the implementation and suggestions on improving the tutorial.

Cliff Brake has announced that there are now packages of Mono available for OpenEmbedded which you can use on your OpenMoko NEO1973 phone, to install, he says:

add the following to a /etc/ipkg/*-feed.conf file:
src/gz mono-armv4t http://dev.bec-systems.com/feed/openmoko/mono

ipkg update
ipkg install mono

OpenMoko is a completely open phone platform: starting at the hardware level (they have hardware kits for hardware developers) up to the software level (all the software is open source/free software).

Unlike other phones, this is completely open, and development and innovation on the phone are encouraged.

All those people that were disappointed that the iPhone is being locked down to developers, this is a good time to help improve a completely open platform. And you should be able to run Gtk/WebKit (the same engine from the iPhone) on the device.

A comparison chart for the hardware is here. OpenMoko today is a developer platform, so expect some updates in the near future.

Sankar has updated the Mono-based plugin for Evolution the Gnome email/calendar/pim client.

It is possible again to write plugins using any of the Mono supported languages to extend Evolution.

The code builds on the previous effort from Michael Zucchi.

You can download the sample plugin here. The sample plugins adds a new menu option to translate an email message to Spanish, and then uses Google to do the translation.

I read on Scott Guthrie's blog the news that Microsoft will release the source code to the class libraries that make up .NET:

Today I'm excited to announce that we'll be providing this with the .NET 3.5 and VS 2008 release later this year.

We'll begin by offering the source code (with source file comments included) for the .NET Base Class Libraries (System, System.IO, System.Collections, System.Configuration, System.Threading, System.Net, System.Security, System.Runtime, System.Text, etc), ASP.NET (System.Web), Windows Forms (System.Windows.Forms), ADO.NET (System.Data), XML (System.Xml), and WPF (System.Windows). We'll then be adding more libraries in the months ahead (including WCF, Workflow, and LINQ).

The source code is released under a new license they are calling the Microsoft Reference License, this is not an open source license.

First of all, congratulations to everyone at Microsoft that made this happen. Am sure many .NET developers will be happy with this new development and there will be many genuine uses for this.

I heard a podcast with Shawn Burke where he discussed some of the history of behind this move. The discussion seemed mostly tactical, and am sure that to do this they must have presented a strong business case to their management that opening up the access to the source code (even under the MS Reference License terms) was important.

Even if the license for the code is not open source, it is an important step. Sun had done something similar with Java in the past and over time they moved towards opening more and more of it. Am still hope that one day Microsoft will open pieces of this under more liberal licenses that would allow those pieces to be used for any purposes, including Mono.

Mono, free software and the source code release

The source code that will be released goes beyond the scope of the C# source code that was released as part of Microsoft Rotor.

But like Rotor, the license under which this code is released is not open-source. People that are interested in continuing to contribute to Mono, or that are considering contributing to Mono's open source implementation of those class libraries should not look at this upcoming source code release.

At the same time, Microsoft already releases some class libraries under an open source license, the Microsoft Permissive License (MS-PL, which will soon be renamed the Microsoft Open License).

Mono manages to benefit from code that Microsoft releases under the MS-PL license and we even redistribute some of it: The Dynamic Language Runtime, IronPython, IronRuby and the ASP.NET AJAX Javascript client-side library.

Speculation

Am not sure why Microsoft did this, there have been a few theories around this, but my own guesses are:

• Scott and many people reporting to him understand developers (Scott did ASP.NET). Scott being in charge of .NET probably has made this organization be more Web-y, in that they understand that developers are more effective if they can "View Source". So it might be a natural cultural shift.
  Scott and his team are behind the Microsoft/Novell collaboration on Silverlight for instance.
• Large .NET users probably already had access to the source code, and probably had access to under a myriad of customer-specific NDAs or licenses and this was hard to work with, and hard for the organization to manage. This could be license consolidation and streamlining of the process to get people access to the source code.
• Getting access to the source code alone was probably very cumbersome. This is probably why the focus of the release is on the simplicity of getting the source code for debugging (the most important scenario presented so far).
• Sun and Java: it is possible that some customers were getting cozy with the ease of access to Java source code to the class libraries and this had some mounting pressure on Microsoft.

Some of the statements are very similar to what Sun used to make about Java before they agreed to open source it:

Allowing developers to rebuild a framework, any framework, from source, and then redistribute the modified result, can introduce problems with providing support, serviceability, integrity and security of the framework itself. This is true with .NET, Java, Ruby, and other frameworks. Multiple independent redistributed modified versions of a framework can decrease the reliability and dependability of the common platform, which is not desirable. In the path we've taken here, we are seeking to balance the requirements we hear from the developer community for transparency and of reliability and dependability of the platform. In striking that balance, we believe the Microsoft Reference License is the right license for this release.

There are a number of scenarios that go beyond looking at the source code which are think are valuable in the existing Microsoft ecosystem and which is ultimately why it would be useful for some chunks to become open source.

For example:

• Bugs in Class Libraries: If there are bugs in the class libraries that can not be worked around, the user does not have to ship a replacement System.dll, but he could copy-paste the code, make the adjustments in the code and ship the resulting executable.
• Different Needs: If the code is close, but not quite what he needs, a developer could cut-and-paste, and then tune the code to do what he needs. This is a very common case that we see with Mono's own source code.
• Complement Existing Frameworks: Microsoft ships a number of reduced versions of .NET: Compact Framework and Silverlight 1.1. People often need features that are only available on the full framework.
  Many folks today cut-and-paste code from Mono to be used on the Compact Framework edition because the subset that Microsoft chose for the CF is a good starting point, but it does not fit all the needs, specially in a market that is heavily slanted towards embedded systems (our XML Serializer is one of the most cut and pasted pieces of code for example).
• Supporting old Frameworks: With 3.5 coming out it is very likely that some features would be useful for applications that must run with 1.1 or 2.0 on systems that can not be upgraded to 3.5. Cut and pasting code would be useful.
• Innovation: Although people can always innovate on "top" of an API, some kinds of new features can only be done if you can alter the inner workings of it. Certainly Microsoft has the right to not let people do that.

For the above cases, people today can continue to use the Mono source code and cut and paste at will (with our super-liberal license the MIT X11 that comes with no strings attached).

But I still believe that there is a good business case for opening more stuff under the more liberal MS-PL license.

And of course, beyond the Microsoft ecosystem, there is the Mono ecosystem, where we could leverage that code if it were open source :-).