Will Mono Become the Preferred Platform for Linux Development?
by Edd Dumbill03/11/2004
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.
Two Stacks
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.
Developer Adoption
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.
Future Outlook
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.
Ambitious Goals
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.
Resources
- The Mono home page contains all you need to get started with Mono.
- MonoDevelop is a port of the popular SharpDevelop IDE to the GNOME desktop.
- O'Reilly's Brian Jepson blogged from the Mono meeting.
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.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 5 of 5.
-
"Miguel is trying to justify this expensive vapourware to Novell"
2004-03-15 12:42:26 angdraug [Reply | View]
I think this comment on LWN explains what's going on. And this one explains the problem with "reasonable and non-discrimatory" patents.
-
MS & Mono
2004-03-12 12:39:36 sab [Reply | View]
<tinfoil hat>
<abestos undies>
OK.. this is gonna look like a troll, but honest.. it aint. I just can't believe this much work is being put into something that could end up litigated to death. We've already seen that you don't have to really prove that someone is using your stuff.. all you have to do is allege that they are (the letters 'S', 'C' and 'O' come to mind).
I trust MS as far as I could throw them. If you're in bed with these guys you better have really thought about your escape route because when they roll over you stand a good chance of being crushed.
Ask yourself. Why would MS actually WANT people to implement .NET on Linux? Because they want to be liked? Because they want to show the world that they really ARE nice guys and want to give back? Hello! Wake up! You're living in a wonderland.
If MS has no ace up their sleeve and Linux starts to take chunks from their revenue stream do you think they will simply let it slide? DON'T trust them, SUN did and from the cursory view I've given .NET it looks like a pretty good clone of the Java VM with a whole pile of languages on top.
If you want to build a better platform and release it to the world sans strings then create it yourself. Relying on someone elses proprietary work and their good graces is like dancing in a minefield, dance long enough and you're gonna get hurt.
</abestos undies>
</tinfoil hat>
-
You are mistaken
2004-03-11 22:41:48 electricmew [Reply | View]
im sorry, if you think "C is dead". You are greatly mistaken, and a full blown idiot. C is used more than any other language. Its right up there with ASM. Just becuase application programmers like using things like Java or mono(becuase its "easier") doesnt make it the right language. And to the people. This only makes a note that you should not listen to certain people, no matter what level of expertise or level of access to different things they might have.
-
reasonable and non-discriminatory
2004-03-11 21:37:33 bothner [Reply | View]
Microsoft has granted a license to use [Common Language Infrastructure standardized via ECMA] under so-called "reasonable and non-discriminatory" terms.
"reasonable and non-discriminatory" is not the same as "royalty-free."
It means they can
change as fee for a license, as long as it is
"reasonable and non-discriminatory". If they do
that Mono as a Free Software project is dead.
Hopefully someone misunderstood the situation.
-
Patent isses with Microsoft remain a problem.
2004-03-11 19:59:09 nzheretic [Reply | View]
As a long time critic of the Mono projects position on the Microsoft patents, I am relieved that after more than a year since the patent issues were raised, Miguel and Novell legal staff are currently conducting a formal patent review of mono.However, even if the project is split into two distinct partitions of ECMA-based and non-ECMA components, how easy is it going to be for the third part developers adding components to the ECMA-based partition to know that he is not treading on Microsoft's patents by implementing functionality defined in Microsoft's .NET patents?
For example, in the graphic from the patents section of the Mono FAQ...
http://primates.ximian.com/~miguel/tmp/map.png
XmlRpc.NET and RelaxNG will likely confict with Microsoft's patent application 20020059425 : Distributed computing services platform.Although there is prior art examples of individual technologies such as the JVM etc, Microsoft patents such as the one mentioned, define and claim the interoperation of the components and the .NET platform.
There is NO way to work-around the issue, no amount of renaming the API calls or reimplementing the methords used will invalidate the patents.






