Mono 2.0...why not Microsoft?

As reported elsewhere on the web, Mono version 2.0 was released today. Built as an open source implementation of the .NET framework, this release goes further in its goal to encompass more of the full range of .NET APIs in a package that can run on both the Mac and Linux (important note: though a cursory glance at the name "Mono 2.0" might make one think that this is the version that supports .NET 2.0, Mono version numbers bear no relation to .NET version numbers). New concepts released as part of Microsoft .NET 3.5, such as Linq (a data access abstraction that works across data source types, such as XML and databases), are now officially supported by Mono.

Of course, there will be differences in the kinds of assumptions you can make when you write a .NET application for Windows versus when you write an application for Mono. As Betanews describes:

For Mono, you can't exactly bind to the same things (DirectX, SQL Server), so developers have to be cognizant of the open source counterparts they use instead.

In other words, instead of binding to a SQL Server database (not strictly required on Windows, but exceedingly common given the primacy of SQL Server on Windows), you would likely bind to something commonly found in a Linux environment. Mono favors PostreSQL, though other database bindings do exist.

You also might want to use GTK#, Mono's binding to the GTK library that serves as the foundation of the GNOME window manager (and works on Windows, too, if you install the GTK library). Windows Forms, however, are supported, and is "complete" with version 2.0 in ways previous iterations of the Mono framework was not.

I think what the folks at Mono have managed to accomplish is rather impressive. They've managed to port most of the .NET Framework to non-Windows platforms. What I sometimes wonder, however, is why Microsoft has no interest in doing such a thing themselves.

Granted, I do understand Microsoft's desire to preserve for itself a competitive advantage. Microsoft is, clearly, a profit-oriented company, and that consideration will always be given priority by Microsoft executives. On the other hand, would Microsoft's interests really not be met by a Microsoft-created and supported runtime that is sold for use on non-Microsoft platforms (obviously, .NET would be a "free" inclusion as part of any Microsoft operating system)?

To a certain extent, some of that work has already been done. Silverlight is Microsoft's attempt to bring .NET 3.0 / WPF programming conventions to the web as part of their effort to compete with Flash. Microsoft would get a whole lot of nowhere, however, if Silverlight was a Windows-only technology. Silverlight, therefore, is available as a downloadable plugin for use on Mac platforms in Safari (Moonlight, created by the folks at Mono, is the version Silverlight for Linux, though it wasn't created by Microsoft). That means they already have had to do some work related to porting the .NET framework to other platforms.

I think .NET would be in a much better revenue-generating position than Sun's attempt at creating a cross-platform layer with Java. Microsoft has a lot more knowledge about desktop systems, a heck of a lot more supporting tools, and a much larger group of developers whose creations would serve as sufficient reason for a lot more people to pay for the Microsoft add-on framework.

Heck, Steve Jobs has even trained Apple users so that they are accustomed to pay for upgrades.

Not being privy to analysis on the issue that I'm sure must have been done by some team within Microsoft, I can't say what kind of effect a truly cross-platform, fully-supported .NET runtime would have on Windows operating system sales. On the other hand, there has to be some value to be derived from giving Microsoft more heft in the cross-platform API space.