The Mono project has a clear goal: to become the first-choice platform for Linux software development. Considering that Mono is an implementation of Microsoft's .NET framework, that goal might sound particularly audacious to many Linux fans.
To find out more, I attended a two day developer meeting hosted by Novell's Ximian division in Boston, MA. Led by the energetic and inimitable Miguel de Icaza, the meeting gave plenty of opportunity for mingling with the Mono developers and listening to presentations on various aspects of the project.
The meeting was held at the end of a week of collaboration between the core Mono developers. A remarkably distributed team, this was the first time some of them had met. Even more remarkable is the small number of people involved in Mono's implementation: the core developers total only twelve.
Over fifty people attended the meeting. Many early adopters and interested developers made the journey to find out more. Despite the fact that Mono is still under aggressive development, there are already some serious deployments being made. Miguel de Icaza mentioned some of these at the introductory session, covering enterprise deployments, embedded systems vendors, and the open source world. Of particular note was an installation in Munich, Germany, supporting 350 servers and 150,000 users.
The licensing status of Mono is of immediate concern to most would-be adopters. Isn't Mono at risk of being wiped out by Microsoft patents? De Icaza explained the situation. The Mono runtime is an implementation of the Common Language Infrastructure standardized via ECMA. Microsoft has granted a license to use this technology under so-called "reasonable and non-discriminatory" terms.
On top of the core system sits two stacks of APIs. One of these is an implementation of Microsoft's APIs for user interfaces, web services, and database access. The other stack is entirely unique to the Mono project and includes things like bindings to the GTK user interface toolkit, the Cairo graphics system, and Mono's own database layer.
It is conceivable that Microsoft would enforce licensing terms on the implementation of the APIs that it hasn't submitted to ECMA. In the worst case, says de Icaza, distributors of those APIs would need to pay fees to Microsoft. None of this would touch the other, Mono-specific, APIs. The two different stacks of APIs are being kept separate to account for this possibility and to ensure that Mono is distributed by vendors such as Red Hat, who are reluctant to take on an unknown patent situation.
So why implement the Microsoft APIs at all? Simple: to make migration from Windows to Linux as easy as possible. With the advent of Microsoft's Longhorn platform, there's only a limited life span for the current .NET Windows APIs. Just in case there remain some unconverted by then, de Icaza is hedging his bets and plans to provide implementation of Longhorn technologies such as Indigo and Avalon, the new XML web services and user interface layers.
From conversations with some of the early adopters at the meeting, it's plain that the Windows migration strategy is working. Developers were able to take their ASP.NET web applications and run them under Mono, after a little accounting for a few pieces of non-portable code.
For Microsoft's part, they're nervous onlookers. There's benefit to them in more implementations of the common runtime, but the wholesale duplication of Windows APIs is causing them some concern.
As well as the implementation of familiar APIs, there's another key factor in bringing Windows developers over to Linux: the IDE. Mono has an answer to that, in the form of MonoDevelop. This is a port of the popular open source SharpDevelop application to Mono. However, MonoDevelop has a completely new user interface, and looks and feels like a GNOME application.
Todd Berman demonstrated MonoDevelop in action at the meeting. It has all the smarts you'd expect from an IDE, including "IntelliSense"-style completion and a debugger. Berman obviously relished the ease with which he was able to develop in Mono, showing attendees a new Mozilla component he created quickly last week. Using MonoDevelop to write web pages, you are able to see a rendering of the page in a browser pane, updated in real time as you type. MonoDevelop is under very active development and should be in a decent state for the release of Mono 1.0.
The MonoDevelop IDE
If compatibility and IDEs smooth the path for Windows developers, what will bring Linux developers into the Mono fold? The answer seems to be productivity. A great deal of serious end-user application coding on Linux still goes on in C or C++. Using Mono vastly reduces the amount of boilerplate code that must be written, along with the opportunity for bugs to creep in.
Also, it can't be ignored that the Mono compiler is blisteringly
fast. Typical GNOME applications have
libtool link lines filling
screenfuls, and enough dependencies to cause even a powerful PC to
labor in compilation. By contrast, Mono compilation happens so
fast it could almost be done in real time.
The Mono project also recognizes the need for good documentation. Of course, part of the Mono genius is that Microsoft documentation can readily be reused. That's a good interim solution, but there's a project called Monodoc underway to independently document Mono, including all the non-Microsoft APIs.
So far, there's a surprising enthusiasm for Mono and C#. Perhaps the respect Miguel de Icaza and Nat Friedman command makes developers willing to try Mono. From the developers I've talked to, though, it seems that it's the platform itself that's attracting them.
The Muine music player
As well as MonoDevelop and Nat Friedman's Dashboard, there are a few other open source Mono/GTK applications that have appeared, including a smart new music player, Muine, and BLAM, an RSS aggregator.
Getting Mono to its 1.0 release is the focus of the Mono team right now. This release is planned for June 2004, and will contain the .NET 1.0 and 1.1 APIs and an implementation of C# 1.0. By the end of the year, another release will add C# 2.0, .NET 1.2, and version 2.0 of Microsoft's ASP.NET and XML technologies.
Further into the future, a planned Mono 1.4 release in August 2005 will include previews of Longhorn technologies Indigo and Avalon.
Linux development is going to look very different if Mono succeeds in its goals. There's no doubt in de Icaza's mind: "To me C is dead. Except for the JIT!" Where does this place the future of the Linux desktop, and in particular, the project de Icaza himself founded five years ago, GNOME?
GNOME is currently pursuing a series of incremental point releases, with 2.6 due any moment now. The expectation for GNOME 3.0, however, is that a lot of the platform will use Mono, rather than the C implementation it has now. While no formal announcements have been made to this effect, it seems to be the strong hope of Ximian personnel.
That will be an interesting journey, as two other major backers of GNOME are IBM and Sun. The attitude of these companies to .NET is at the moment uncertain, with both having a substantial interest in Java. The irony of Sun's successful (yet oddly-named) GNOME desktop, the Java Desktop System, being based on .NET might be a little too much for them to swallow.
The Mono project is one to watch. The audacity of using Microsoft's own investments and technologies to bring developers to the Linux platform sets the tone for interesting times. If they're prepared to take on the 800lb gorilla in this way, there should be no doubt that Novell is aiming to grab the Linux platform by the neck and shake it up a bit, too.
Edd Dumbill is co-chair of the O'Reilly Open Source Convention. He is also chair of the XTech web technology conference. Edd conceived and developed Expectnation, a hosted service for organizing and producing conferences. Edd has also been Managing Editor for XML.com, a Debian developer, and GNOME contributor. He writes a blog called Behind the Times.
Return to ONLamp.com.
Copyright © 2009 O'Reilly Media, Inc.