There are corners of the Internest where foolish people congregate, and invent stories. These foolish stories are then read as gospel by trusting people, and reposted, until the original made-up source is concealed from view. As an attempt to stem this flow of disinformation, here are some commonly held – but incorrect – beliefs about the Mono framework, and an explanation of the reality of the situation, as far as I understand it.
The next Mono version is co-developed with Microsoft
There is a grain of truth behind this one, but it’s a gross mischaracterisation. Mono 2.8, when it ships, will bundle, for convenience, a number of Free Software libraries, which are released by Microsoft under a license considered Free Software by the Free Software Foundation, the Ms-PL. These are:
- System.Web.Mvc and System.Web.Mvc2: ASP.NET MVC, a library for writing ASP.NET web pages with a model-view-controller design, similar to Rails for Ruby. This is not news – System.Web.Mvc has been bundled in Mono since Mono 2.4.2 (June 25th 2009). System.Web.Mvc2 has been bundled in Mono since Mono 2.6.7 (July 14th 2010).
- System.Numerics: Mono re-uses Microsoft’s implementation of BigInteger.cs from the Dynamic Language Runtime (see below). This is indeed new to Mono 2.8, as it is part of .NET 4.0 (Mono 2.8 targets .NET 4.0 compatibility by default).
- System.Data.Services.Client: The OData SDK client library. This is indeed new to Mono 2.8.
- System.ComponentModel.Composition: The Managed Extensibility Framework, a library for writing and using plugins. This is similar in scope to the existing Mono.Addins project. This is indeed new to Mono 2.8, although it was added to Mono Trunk in 2009.
- System.Web.Extensions: Microsoft Ajax, a library for using Ajax inside ASP.NET projects. This is not news – MicrosoftAjaxLibrary has been bundled in Mono since Mono 1.2.6 (11th December 2007).
- Microsoft.Scripting.Core and Microsoft.Dynamic: The Dynamic Language Runtime is a framework permitting implementation of dynamic languages (such as Python or Ruby) on top of the core .NET runtime. It is used for IronPython and IronRuby, amongst others. The DLR has very recently changed license from Ms-PL to Apache 2.0, but the version bundled in Mono is still under the older license. This is not news – the DLR has been bundled in Mono since Mono 2.6 (14th December 2009).
So, to summarise, there are five Free Software libraries written by Microsoft under the Ms-PL included in Mono 2.8 – but only two of those five are new, and none of them were “co-developed” in any meaningful sense.
Mono development is dead
There have been reports that Mono development has ended, on the basis that no commits have been made to Novell’s Subversion server for a few weeks. However, these reports miss one minor detail – Mono has moved to Github.com. There were 35 commits from 9 different people to the main mono.git repository (of dozens of repositories under the main Mono project) in the last 2 days, at time of writing – far from dead.
Mono lacks features found in Microsoft.NET
Mono lacks libraries found in Microsoft.NET, such as the Windows Presentation Framework GUI toolkit. In terms of features, i.e. things implemented at a compiler or runtime level, Mono is typically more advanced. This is helped in no small part by Mono’s Free Software development model, allowing experimentation and “what if” changes to the core runtime which a sluggish corporate behemoth like Microsoft cannot accommodate.
To give three real-world examples, Mono allows embedding of its compiler as a service, and provides a REPL shell – this is a planned feature for .NET 5.0, but has been available for years in Mono; Mono.Simd provides a number of data structures which will run on any version of Mono or Microsoft.NET, but will use optimized CPU extensions like SSE when run on a sufficiently new version of Mono, on an appropriate architecture – as far as I’m aware, there is nothing like this available or planned for Microsoft.NET. Mono is able to produce fully compiled, static executables which do not need to JIT anything at runtime – this is used for iPhone compilation, for example, where JITters are not permitted. There is no comparable feature in Microsoft.NET.
Clearly, Microsoft.NET can only be thought of as more featureful if one defines “features” in terms of “does it have lots of libraries?” – in terms of functionality, Mono is ahead.
Mono can “sneak onto” your system without your knowledge
If you don’t have the “mono-runtime” package installed, you can’t run Mono apps. It is possible to install some Mono apps alongside the awful-yet-popular “mononono” equivs package, since the popular equivs script fails to place Conflicts on the correct packages (F-Spot will be blocked, Tomboy will not). No package in Debian or Ubuntu embeds its own copy of the Mono runtime, and we have no plans to make any changes to packaging which would allow execution of any C# application without mono-runtime installed. If one is using a different OS, then things may be different – e.g. The Sims 3 for Mac & PC uses embedded Mono, which you wouldn’t know about without looking.
Canonical are pursuing a pro-Mono agenda, and are responsible for it being “pushed” in Debian
Mono development has been happening in Debian for longer than Canonical has existed – the first upload was made in April 2002. Ubuntu is made primarily from software already available in Debian deemed of sufficient quality, and when F-Spot and Tomboy became parts of the default Ubuntu desktop system in 2006, both pieces of software were already available in Debian and deemed of sufficient quality. Nobody working on Mono in Debian is paid by Canonical… actually, that’s not entirely true, three packages related to accessibility are officially maintained by someone who was hired by Canonical after doing the initial packaging work when he worked for Novell. But the Mono runtime itself, Canonical have no influence over its direction in Debian. As for a “pro-Mono agenda”, they’ve always taken an extremely pragmatic approach to language choice, never showing any real preference for one language or another when it comes to app selection. They don’t exhibit any overt anti-Mono policies, which is not the same thing. The names of people contributing to Mono in Debian are not secret – check the pkg-mono team page on Alioth.
The System.Windows.Forms namespace is protected by Microsoft patents
The truth is, nobody knows for sure if SWF, or any other part of Mono, or any other framework such as Vala or Python, is covered by Microsoft patents. The way the US patent system is contrived, it is actively dangerous to check whether something contains any patents when you write it, as you are liable for triple damages should it later emerge that there WAS a patent, even if your searching missed the fact. You cannot patent an API or namespace – only a specific implementation of a software concept, in those countries where software patents are permitted. There has never been any evidence shown that Mono’s implementation of SWF, or indeed any part of Mono, infringes any Microsoft-held patents, because if that were the case, then the code would be rewritten to avoid the issue – much like the approach taken by Linux kernel developers when a patent becomes apparent.
The belief within the Mono community is that the core parts of Mono as defined in ECMA334/335 are safe (they are covered by the Microsoft Community Promise patent grant); any of the Ms-PL libraries mentioned above is definitely safe (Ms-PL includes an explicit patent grant); and the rest of the package is likely safe too (on the basis that it is a named component of the Open Innovation Network’s list of protected software – and on the basis that there’s unlikely to be anything patentable in one of many implementations of basic ideas like database connectors). Nobody knows for sure, because that’s how the system works. But, again, nobody knows for sure that Microsoft patents don’t apply to other frameworks such as Python – there is simply a belief and an assumption that they do not.
MonoDevelop contributors removed GPL code from MonoDevelop, in an attack on the GPL
This is somewhat disingenuous, given MonoDevelop is LGPL.
The MonoDevelop team excised the remaining GPL code (and there wasn’t much of it) in order to grant greater Freedom to developers. Previously, the entire MonoDevelop IDE was a GPL combination, meaning any add-ins for the IDE also needed to be GPL, regardless of developer choice. Now, any developer can write an add-in for MonoDevelop, using the license of their choice, whether another Free license like the Mozilla Public License, or a proprietary closed-source add-in. They are still welcome to produce GPL add-ins, if they want to, as well.
Mono won’t run random Microsoft.NET apps anyway, so isn’t really cross-platform
Actually, this one is often true. When developers write apps for Windows primarily, they rarely take the time to think “is this the correct way to do it?” and will often plough on with an assumption about the Windows way of doing things. It might be simple things like filesystem assumptions (assuming a case-insensitive filesystem, or assuming a backslash is used to separate directories, not a forward slash). It might be more involved, such as using P/Invokes into Windows-specific C libraries, when a more cross-platform alternative is possible. So, often, random applications for Microsoft.NET won’t run on Mono. The reverse is also true – F-Spot or GNOME Do are fairly heavily tied to Linux (or to UNIX-like OSes with X11, at any rate), through the libraries they invoke being fairly platform-specific. You can write platform-specific Java, with one quick piece of JNI, too.
It should be noted, however, that Mono makes the chance of .NET applications being ported to Linux (and/or Mac) much more likely, since even in the worst case scenario, a company only needs to fix a portion of their source to make it cross-platform. The Mono team have a tool called MoMA, which will scan an application and its libraries, and give you detailed reports on the app’s portability. This info is used at both ends – by app vendors who want to become more portable, and by the Mono team who want to fill in the most frequently encountered blanks.
And, it should be stressed, writing cross-platform apps is entirely possible if one desires it – e.g. the IRC client Smuxi is pure cross-platform C#, and the executables compiled on Mono on Linux will run fine on Microsoft.NET on Windows. Portability in this direction is important too – consider how many people have been introduced to Free Software thanks to availability of Free apps on Windows like OpenOffice.org, Firefox, Pidgin or GIMP. You can download Tomboy for Windows, and work is ongoing on fixing Banshee portability issues (which are mostly caused by gStreamer).
Mono on Android is a terrible idea which will be super slow
There are two efforts to enable developers to write Android applications with Mono – a paid proprietary product from Novell called MonoDroid, and an untitled porting effort by big-name Android hacker Koushik Dutta. I have no insight into MonoDroid since it hasn’t been released yet, but Koush did some benchmarks of his work which exhibited some remarkable figures compared to Dalvik (and even compared to Sun Java for ARM). Those numbers haven’t been updated to reflect the Froyo Dalvik JITter, but Mono on Android is still very exciting from a performance perspective.
Mono isn’t really Free Software
The source code is all available under Free Software licenses. So, um, yes it is.
We don’t need Mono because we have $LANG
By the same logic, we don’t need $LANG because we have Mono. By all means, use the language of your choice – other developers will use the language of their choice too. If you want to use Vala or Python or Java, then by all means, go ahead. It doesn’t mean there’s no room for more languages, better suited to other usage patterns. Haskell is great for some types of development, so is Fortran, and so is C#.
You might not need Mono because of $LANG, but there are others in the world with different needs.
Mono apps are all slow, and crash your computer, and stuff
No userland app can crash your Linux system, unless there’s a bug in the kernel, or you have some severe problems with your hardware. If you’ve ever observed a crash as a result of running a Mono app, then it’s really coincidence that Mono is tickling whichever part of your system is busted. As for slow… startup time may well be slower than for apps written in C or Vala. There’s a delay due to the JITter needing to compile all the libraries used by the application (we may AOT the most common libraries in a future Mono package version, at upstream’s recommendation). Once an app is running, it should be fast compared to a Python app, and memory-light compared to a Java app. The new garbage collector in Mono 2.8 should also offer significant improvements to performance, especially under heavy workloads.
Ubuntu’s default GTK+ themes require Mono
This is my favourite recent nonsense to emerge from the Internest. There are reports – mostly restricted to IRC and blog comments, that (paraphrasing here) “removing Mono removes the Ubuntu themes”. Here’s the reality: in Ubuntu 10.04, a new visual style was implemented throughout the distro. As part of this, small icons (e.g. notification area icons) were set to be black-and-white by default, and colourised when attention is needed (e.g. the power-off icon turns red when a reboot is needed, the messaging indicator turns green when there’s a new message). All of these new monochrome icons are in a package named “ubuntu-mono”. Removing the ubuntu-mono icon package will also remove the new Ubuntu GTK+ themes, in the “light-themes” package. So there’s your explanation: the themes have a dependence on some monochrome icons, not on the Mono framework.