Over at the Enterprise Linux Blogs there is a quite positive article about Mono and I wanted to comment on it without having to fill 20-pages worth of questions to post a reply there.
Schley makes a few good points, but its worth pointing out some things:
2. People assume that Mono is not ready for the enterprise.
One of the reasons for this is because not many enterprise projects are being built with it (I'll get to that later.) Instead, Mono is primarily being used to construct desktop software.
The second reason for this misconception is the Mono project's inability to stay in step with Microsoft .NET. Currently, Mono is somewhere between .NET version 1.1 and 2.0 while .NET 3.5 was just released. This is not the Mono team's fault. Microsoft does not collaborate with them, so everything the Mono team accomplishes is through their own blood, sweat and tears. Nevertheless, this version discrepancy creates the perception that Mono is just a .NET wannabe.
[...]
With the exception of iFolder, Mono is not being used to develop any truly useful enterprise applications. Great desktop applications are being created, like Tomboy and Beagle, but no one has created the next great server application using Mono.
He is correct that Novell's use of Mono has been mostly focused on the desktop.
But there are quite a number of applications beyond the desktop that are being developed with Mono outside Novell. We have been tracking a list of companies using Mono and the list of programs and libraries keeps on growing every day.
A problem that we do have is that of the companies using Mono have policies of not publicly endorsing third party products. Also, we typically only find out about who is using Mono when they have a bug to report, or need some new feature to be implemented. And in many of those cases we are not in a position to use them as reference customers.
If you look at the posts, sigs and domains of people posting to the forums and the mailing lists, you will get a better idea of what kind of applications people are building, and who is building them.
A few companies have agreed to allow us to publish success stories about their use of Mono, some of them are:
Some other serious uses of Mono, but without a full success-story case include Fiducial.FR (their intranet runs on Mono), Zing (mp3 and Sirius radio players), Medsphere (Health Care software), Quantify Solutions (financial tools), MindTouch (commercial Wiki hosting) and its even used by companies in the USC 2257 space to build enterprise solutions (for an interesting definition of enterprise).
At least a few years ago, the Wikipedia search engine was powered by Mono. I do not know if that is still the case.
The goal of the Mono team at Novell is not only to help our internal users, but to make sure that external developers can use Mono without a problem. We fix bugs, improve performance, improve compatibility and write new libraries (both Microsoft compatible, or part of Mono's own stack).
Maybe the issue is that we do not have a lot of server-side
applications that are part of a default Linux install. What
we do have are plenty of vertical applications that people are
developing or porting.
Memory Leaks If you have ever used Beagle you know that it can
heinously crash your system. Since it's inception, Mono has
been plagued with a random memory bug. Your system memory will
go from 1% to 1000% in a matter of seconds, without
warning. If the Mono developers want to make Mono more than
just a desktop hobbyists language then they need to fix this
bug once and for all.
As for memory usage problems: there are certainly memory leaks in Mono, but nothing as bad as a show stopper. Mono can not reduce memory usage if an application uses a lot of memory. Sometimes the blame for memory consumption falls on the application and is usage patterns.
Beagle might have had bad memory usage patterns on its early days, but a lot of this changed in newer releases.
There is one particular class of memory-hungry applications: any .NET applications that used generics (the 2.0 profile) extensively was negatively impacted by memory consumption before Mono 1.2.5. On one hand, we are glad that application developers switched to 2.0, as they helped us find the bugs and limitations in Mono, but it also meant that users had to suffer as we understood all the ramifications of the 2.0 profile and generics.
The situation will dramatically improve with our upcoming Mono 1.2.6. As Aaron already reported 1.2.6 had a dramatic impact on memory usage in Banshee (a generics-heavy application).
Python Effect There is a huge movement in the Gnome community to make Python the standard language for Gnome development. Mono is a close second, thanks in part to the great desktop applications being written with it. However, if Python is officially adopted, there will be a backlash against Mono, or pressure on developers to adopt Python and port their once Mono applications to the official language. In order to prevent this from happening, Mono developers need to demonstrate Mono’s cross-compatibility.
Python is indeed making great strides as a desktop development platform and am not sure that we are in the business of competing with it. If people like writing Python code, they should just keep writing python code.
Myself, I like the IronPython variation of Python more. IronPython just happens to be JITed Python and in most tests it is faster than CPython. For the past year or so, we have also been in love with Boo, another .NET language. Boo has support for strong typing, so for certain scenarios you will get even better performing code (basically, when you can determine the type of a variable ahead of time, instead of having the variable be entierly late bound).
At the Mono Summit, a developer had built a game that was scripted with Python, said something more or less like this: "Our game used to be very slow, when we switched to Mono, all those problems went away" (edited for political correctness).
So each developer will make up his mind as to what is best for a particular use case.
The Mono team needs to have Mono installed by default into Linux so that if you write an application with Mono it can run in Windows AND Linux (and even OS X).
We agree with that. Applications built with Mono on Linux already work on Windows and MacOS (including Windows.Forms).
When it comes to Gtk# applications, Our Mono on Windows ships with Gtk# and we recently announced that we will be supporting it as well on MacOS X and that we will be extending our OSX support.
Posted on 06 Dec 2007