Brian Nickel worked on extending our hosting server for ASP.NET applications (XSP) to support FastCGI. Robert Jordan today integrated his Summer of Code project into the main distribution for XSP.

Until today developers had two options to host ASP.NET applications with Mono: mod_mono (using Apache) or using a standalone, minimalistic HTTP 1.0 server (the xsp command).

XSP provides the Mono.WebServer.dll ASP.NET application hosting library (controls application domains, starts up new instances of HttpApplication, configures and most importantly implements the communication endpoint for HttpWorkerRequest). Mono.WebServer.dll is not very useful on its own as it does not actually implement the HTTP protocol.

For Mono.WebServer.dll to actually be useful, it is necessary to write an HTTP front end for it. Something that speaks the protocol and passes on the request to the application hosting interface.

Most setups today look like this:

You just have to imagine the "Internet" on the left side (TODO: get a cloud picture, and copy-paste it).

Some courageous people use our test server (xsp) which merely implements HTTP 1.0 and has no configuration options (other than the port to listen to):

Courageous because really, there is not much other than serving files and requests in that server and it is limited to HTTP 1.0.

With Brian's setup, we now add this to the family:

From the FastCGI and Mono Documentation:

The FastCGI Mono Server was developed as part of the 2007 Google Summer of Code with the goal of increasing the availablity of ASP.NET and simplifying configuration. Requiring as little as zero command line options and supporting a large number of servers, the FastCGI Mono Server makes it simple to include ASP.NET on your server.

Documentation on how to configure the FastCGI support for various servers is available here (In particular lighttpd).

This code is available now from our SVN Repository. This should be available on Mono 1.2.6.

Thanks to Brian for writing this nice code and Robert for integrating this into trunk and Marek for his ongoing maintenance of the ASP.NET stack.

Now, who does one have to bribe to get early access to the ASP.NET MVC bits around here or get invited to the ASP.NET SDRs ;-)

A common problem that I face is explaining to people the current situation of Mono. This is a problem of our own creation when we sketched the major milestones for Mono.

When we originally plotted the course for the Mono Roadmap things looked pretty simple, they were roughly like this:

Mono 1.0:

• Ship the VM 1.0
• Ship the C# 1.0 compiler
• Ship System, Xml, Data, Drawing Web and Web.Services
• Gtk# and friends.

Mono 2.0:

• Upgrade VM to 2.0
• Upgrade compiler to 2.0
• Upgrade libraries to 2.0
• Add Windows.Forms
• Ship Gtk# 2
• Favorite extra stuff (debugger, compacting GC, internal embedding API upgrade)

As you can see, we intended our versioning scheme to track the major Microsoft releases to expedite explanations of what level of APIs Mono supported. So Mono 1.x would be roughly .NET 1.x, Mono 2.x would be roughly .NET 2.x, Mono 3.x would be roughly 3.x and so on.

There is a bit more than just tracking the API, as you can see, there are really two dimensions to what we wanted to call Mono 2.0:

One dimension is the 2.0 compatibility with .NET, and another one has some internal goals of ours. For example, we considered that 2.0 was a good time to break the embedding API for the runtime and also to release the compacting collector.

Complications

There were a few factors that started to complicate our numbering scheme:

• Our Windows.Forms implementation was lagging behind other class libraries (as writing a Winforms control requires much more work than say a Web Control).
• Our desire to implement some major optimizations and improvements in the VM (improved code generation, AOT for 2.x, compacting garbage collection, switch to eglib-based public APIs, change in the embedding API).
• Generics being a requirement for a lot of the 2.0 work that was necessary.
• Microsoft releasing .NET 3.0 which was really just a new set of libraries that just ran on top of 2.0 (we track these in a separate project, called project Olive).
• Microsoft releasing .NET 3.5 which is the actual upgrade to 2.0.
• Some areas would be developed faster than others: sometimes this was due to planning, lack of planning, or big boosts in external contributions (for example, Mainsoft contributed extensively to making ASP.NET 2.0 and ADO.NET 2.0 happen, and they have been shipping their Grasshopper product since ~May).
• We might not support the full API for a given assembly: there might be some features that do not make sense on Linux or features that will never be implemented (like System.Management).

By the time we shipped our Mono 1.2 last year, the problems with the simple versioning numbers started to show. Mono 1.2 included many features from 2.0:

• C# 2.0.
• Generics support in the VM.
• A lot of the 2.0 support in the class libraries. (core, XML, Data and ASP.NET was almost done).
• Support for Windows.Forms 1.0.

Almost a year has passed and we are about to release Mono 1.2.6, six releases after Mono 1.2. Compared to last year's Mono, this upcoming release is a major upgrade, we have since:

• Completed most of the 2.0 support, including:
  • Completed C# 2.0.
  • Completed ASP.NET 2.x (modulo WebParts).
  • Completed ADO.NET 2.x.
  • Most of Windows.Forms 2.0 (about 80% of it at this point).
• Implemented most of C# 3.0 (few tidbits missing).
• Implemented LINQ, and LINQ to XML (.NET 3.5).
• Implemented some other bits from .NET 3.5
• A Visual Basic.NET compiler, and its runtime.
• Added a Silverlight toolchain (.NET 2.1).
• Added COM/XPCOM support to Mono.

From an API perspective, with the exception of Windows.Forms 2.0 we have pretty much completed the 2.0 support (what remains to be done is tracked here for the core and here for winforms).

In addition, some bits from 3.5 are being shipped in this upcoming version.

Since we continue to ship updated versions of Mono every 8 to 10 weeks we have only felt that we needed to update the smallest version number (1.2.6 is our upcoming release) each time.

My concern is that 1.2.xx does not really convey the feature set in Mono and some people get the wrong impression of where Mono is at. This problem is made worse because we have been using the simplified numbering scheme for years.

Just today someone emailed me asking when ASP.NET 2.0 will be released, another person asked about ASP.NET AJAX (supported in SVN, and in the upcoming 1.2.6).

Options

We are looking for a creative solution to this problem.

Without using Mono versions, these are roughly the upcoming milestones:

• Mono A: Estimated 3-4 months of work.
  • The core 2.0 done + ASP.NET 2.
  • 2.0 profile (minus Winforms) becomes officially supported.
• Mono B: Estimated 6-9 months of work.
  • Windows.Forms 2.0 complete.
• Mono C: 9+ months.
  • When the Compacting GC is done.
  • Make the runtime embedding API changes here.
• Mono D: 9+ months.
  • When the new IR/optimization framework is ready
• Mono E: 6-9 months of work.
  • When System.Core and other 3.5 libraries are finished; maybe we could even split this up in chunks.
• Mono F: 12 months of work, Silverlight security features:
  • New security system (done).
  • StackOverflow protection (done).
  • Complete the Verifier.
  • Harden the Mono loader (for Silverlight).
  • Full runtime security audit.

  The order of the above releases is not necessarily the one listed above, and I used letters to avoid discussing the actual release numbers. Three of those (C, D and F) are difficult to come up with an estimate now.

  Massi advocate a model where for large Mono upgrades (ABI changes, like the GC and the runtime API change) we change the major version.

  This would mean that we could ship a Mono 1.4 at the time that the "core" 2.0 is done; A Mono 1.6 when Winforms 2.0 is done; A Mono 1.8 when the 3.5 APIs are ready; and Mono 2.0 when we do the GC changes. This proposal does not fix the confusion problem with "1.x" though.

  Marek has a slightly modified proposal: when we ship 2.0 minus winforms we call it Mono 1.8; Mono 2.0 includes Winforms, GC, ABI breakage; Mono 2.2 includes new optimization framework;

  Jonathan suggest that we could use the major version number to document what is the version number that we feel we can officially support. 2.0 means "2.0 minus Winforms" with an upcoming 2.2 version with Winforms support and 3.5 thrown in the middle at some point (you will notice that the Olive/3.0 discussion is not part of this decision making).

  Thoughts? email them to the devel group and CC me ([email protected]).

George Moudry from the DB_LINQ team has just emailed me to inform me that his multi-database LINQ implementation for .NET is now MIT X11 licensed!

Wow. Rob Conery, the author of SubSonic has accepted a job to work for Microsoft. These are the highlights:

• He will continue to work on Subsonic, paid by Microsoft.
• Subsonic will remain open source.
• Rob will continue doing his SonicCasts.
• Subsonic will be playing an important role on ASP.NET's new MVC framework.

Congratulations!

Now only Jon and Jeff remain independent after Mix 07.

[from Phil Haack].

Microsoft upcoming .NET 3.5 and C# 3.0 have support for Language Integrated Queries (LINQ). This gives C# and VB users a SQL-like syntax right in the language to access databases directly. For example, this is now valid C#:

public void Linq1() {
    int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };

    var lowNums =
        from n in numbers
        where n < 5
        select n;

    Console.WriteLine("Numbers < 5:");
    foreach (var x in lowNums) {
        Console.WriteLine(x);
    }
}
	

For more samples, check the 101 LINQ Samples.

There are a number of LINQ providers for different kinds of sources. For example, there is a built-in provider for things like arrays, collections and IEnumerables.

A more useful sample comes from Don Box, this is a program to extract the top ten read articles from an Apache log file file:

	var regex = new Regex(@"GET /ongoing/When/\d\d\dx/(\d\d\d\d/\d\d/\d\d/[^ .]+)");

        var grouped = from line in ReadLinesFromFile("logfile.txt")
                      let match = regex.Match(line)
                      where match.Success
                      let url = match.Value
                      group url by url;

        var ordered = from g in grouped
                      let count = g.Count()
                      orderby count descending
                      select new { Count = count, Key = g.Key };

        foreach (var item in ordered.Take(10))
            Console.WriteLine("{0}: {1}", item.Count, item.Key);

There is another provider for creating and consuming XML data: LINQ to XML. The LINQ distribution comes with a nice sample where many of the samples from the XQuery specification have been rewritten into C# with LINQ with code that is roughly the same size (which sadly, I can not find online to point to).

Luckily, we have implementations for both of these in Mono.

And finally there are providers for databases. Microsoft ships one that will integrate natively with Microsoft SQL.

Unlike the XML and in-memory providers, the SQL providers are more complicated as they need to turn high-level operations into optimized SQL statements. Unlike many object to database mapping systems that produce very verbose SQL statements LINQ is designed to provide a very efficient representation.

The Db_Linq is an open source project to create a LINQ provider for other databases. The project is lead by George Moudry and so far has providers for PostgreSQL, Oracle and Mysql.

George keeps a blog here where you can track the development of DbLinq.

Thanks to Bryan for pointing me out to this fantastic piece of code.

Mono users on Linux will now be able to use LINQ with open source databases from C# (in addition to our in-memory and XML providers).

Currently we are still missing some support in our compiler and our class libraries for this to work in Mono, but this will be a great test case and help us deliver this sooner to developers.

Update: A nice blog entry talks about Parallel LINQ. A version of LINQ that can be used to parallelize operations across multiple CPUs:

	IEnumerable data = ...;
	
	// Regular code:
	var q = data.Where(x => p(x)).
		Orderby(x => k(x)).Select(x => f(x));
	foreach (var e in q) a(e);

	// Parallelized version, add the "AsParallel" method:
	var q = data.AsParallel().Where(x => p(x)).
		Orderby(x => k(x)).Select(x => f(x));
	

See more details about the above in the Running Queries On Multi-Core Processors article.

Update2: Am not up to speed in the databases vs object databases wars, but am told that there is also a LINQ binding for NHibernate. A sample is here.

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 :-).

As Jeff and myself walked back from a dose of fried quesadillas from Anna's taqueria on MIT I was telling him "There is always an interesting event announced on these walls".

And in the middle of one of the corridors I found that both John Mearsheimer and Stephen Walt, the authors of the "The Israel Lobby and U.S. Foreign Policy" will be talking at the Stata Center at MIT on Wednesday.

The book has been excellent so far. It expands on a paper that was widely discussed last year but goes into a lot more depth.

Another excellent book that I just finished reading recently is Israel-Palestine on Record: How the New York Times Misreports Conflict in the Middle East.

Update: Robert pointed out that I forgot the link to the event.

Over the summer Ben Motmans rewrote the database support in MonoDevelop. Working with Ben was a pleasure.

Part of the challenge was that I personally had no idea what it is that people do with these database UIs. My contact with databases is so bad that about once a year I google up the instructions to setup Postgres again, and figure out my login, password and connection string followed up by extensive cut-and-pasting of "CREATE" statements until I have something that roughly can store a few values.

His work has now been integrated in the First MonoDevelop Beta release.

Query Result and Database Explorer

Alter Table

Creating a SQLite connection.

This Database Add-in replaces the old Mono.Query add-in, and will hopefully continue to improve to have a central location for all of your database needs.