Miguel de Icaza Explains How to "Get" Mono

It's perhaps the most controversial project in the open source
world,
but this mostly stems from misunderstanding: Mono, the open source
development
platform based upon Microsoft's .NET framework. Immediate reactions
from many dubious Linux developers have ranged from confusion over its
connection with .NET to wondering what the benefits of developing under it are.

Throughout the course of Mono's four years of intense development,
sponsored by Novell, founder Miguel de Icaza has had to frequently
clarify the .NET issue and sell the community on it. But the project's
heart has always been, he explains, about making the lives of Linux
developers easier: "One of the reasons that we developed Mono was
because we wanted to have better tools to develop software." (Figure 1.)

Vice president of developer platform for
Novell in Boston, de Icaza, 32, took a moment to discuss with us
the primary legal concerns and technical issues with Mono, its current
and near-future status, and why you should consider developing
your next project with it. For those of you who are still unfamiliar
with Mono, consider this interview a definitive, quick-and-dirty primer.

Figure 1. According to de Icaza, the Mono platform was devised to make software development easier. Here we see F-Spot, a photo management application
for the GNOME desktop that was developed under Mono.

Oreilly.com: Let's clear this
question up right off and get this out of
the way. It's the one thing many people continue to misunderstand about
Mono: What exactly is Mono's connection to Microsoft's .NET?

Miguel de Icaza: .NET was a
company-wide branding effort at Microsoft
that spanned multiple projects.

Mono is most similar to one component of it: the .NET framework. We
are
an open source implementation of the virtual machine, the C# language,
the base class libraries, and we have a compatibility stack (ASP.NET,
ADO.NET, and Windows.Forms). In addition to that, Mono has produced a
very large set of extra libraries.

Oreilly.com: Let's say I'm a
Linux developer but still have doubts. So
tell me, why should I develop with Mono instead of going the
traditional route (i.e., C++)? What are the advantages, technically?

de Icaza: I classify C# as a
component-programming language: a language
that is particularly well suited for medium-to-large applications,
where multiple developers contribute; where having a strict compiler,
strong typing, and contracts/visibility are tools that help developers
reduce the bug counts and reduce mistakes.

Even if C# is not your favorite language, you can use other
third-party
languages [with Mono]--Java, Python, JavaScript, VB.NET, Fortran,
Cobol--and you can reuse existing code from C and C++ very easily.

A few of the attributes that Mono [has] over traditional
environments
are:

Easy to integrate with native libraries: The Platform/Invoke
feature allows developers to call into native operating system
libraries without having to write glue code.

Automatic memory management: Using a language with a garbage
collector is a great productivity gain, as developers can focus on real
problems instead of fighting with the circuitry every time.

A feature-full runtime: The runtime provides many features to
applications running on it, from a thread-aware and thread-safe set of
libraries to built-in garbage collection.

Modern APIs: The industry has learned a lot about OO API design
in
the last few years; this are now available for developers to use in a
nice package.

Oreilly.com: Could the code
that the Mono team has been developing be
reused for other projects?

de Icaza: All of our code is
open source, so it can be used for other
projects. The compilers are GPL. The virtual machine is LGPL, and the
class libraries are MIT X11. I know of at least two uses of our C#
compiler for research.

Our class libraries are regularly copied-and-pasted into other projects,
as
they fill a large void in the compact framework world, where the class
libraries are fairly incomplete.

Oreilly.com: What are the
inherent issues one needs to keep in mind
when developing code under Mono?

de Icaza: If you are developing
cross-platform code, it is always
important to test your application on the target platforms that you are
using (Windows, Linux, and Mac OS, for example). Mono is not able to
hide all the details of each operating system, and details about it
might bubble up (like the path-name separators, the case sensitivity of
files, the behavior of deleting an open file, etc.). (See Figure 2.)

At Novell, we have set up a continuous build process for Mono and
its
tools that not only builds Mono, but also runs an extensive test suite.
This is done in multiple platforms at once. Running the test suite like
this allows us to catch problems when they are just introduced.

We have tremendously enjoyed user contributions in the form of bug
reports. If you find a problem with Mono, we really want to know about
it, so it can be solved.

Figure 2. Demonstrating the cross-platform versatility of the Mono development
platform, the Mono-based IDE MonoDevelop is shown here running on Mac
OS X

Oreilly.com: What is the
current status of Mono?

de Icaza: Mono 1.0 was released
last year. After releasing Mono 1.0, we
started work on a new edition of Mono that will be released later in
the year.

Mono [1.0] today consists of three groups of components:

Core components: Virtual machine, C# compiler, base class
libraries.
These are based on the ECMA 334 and 335 standards.

Mono/Linux/Gnome development stack: A set of class libraries
that
complement the core and provide a wide range of tools for developers.

GUI development tools with Gtk# that integrate natively with
the
GNOME desktop. This is our recommended path for developers creating
GUI applications on Linux.

Mozilla libraries to allow people to create applications with
the
Gecko Rendering Engine (GRE) with Mono.

RelaxNG: A new and simplified XML schema language.

A complete security stack: This is a superset of the features
available on the .NET framework.

Database providers for both open source and proprietary
databases:
Postgress, MySQL, Sqlite, DB2, Sybase, and ODBC.

Unix integration libraries: For people who want to use the
low-level Unix system interface.

Microsoft compatibility stack: A stack of libraries that allow
developers to port their existing software from Windows to Linux. This
includes ADO.NET for database access and ASP.NET for SOAP and WebForms
applications.

Oreilly.com: What do you have
planned for the next version?

de Icaza: The new release of
Mono is scheduled to improve upon Mono 1.0
in the following areas:

Windows.Forms API: This is part of the Microsoft-compatible
stack.
It is used by programmers on Windows to develop client applications
with .NET. With Mono 1.2, we will allow people to bring their existing
GUI applications to Linux.

C# 2.1: The new edition of the C# specification includes many new
features that we now support: generic types, anonymous methods,
iterators, fixed buffers, covariant/contravariant delegates,
per-accessors access levels, and a few smaller changes.

64 bits: At this point we have two full 64-bit ports: the SPARC
v9
with Solaris and the AMD64 port.

New ports: S390, AMD64, and a few more variants of the PowerPC
architecture are added to the list of back ends.

JScript and Visual Basic open source compilers: These compilers
will
only be available as beta compilers at the time of the release. These
are just convenient tools to have a complete self-hosting system;
developers can still use third-party compilers on the Windows platform
to compile their existing code in the meantime.

Virtual machine upgrades: Mono 1.0 was about being as
feature-complete as possible. In 1.2, we are tuning various key elements
of the virtual machine:

A new, stronger code optimizer that offers many optimizations only
found
on advanced optimizing compilers, like SSAPRE/GVNPRE for redundancy
elimination, arrays bounds checking, many peephole optimizations,
and inlining of common operations.

Garbage collector tuning: we have tuned the garbage collector
extensively, and it will now be operating in mostly-precise mode. The
result is less memory consumption: long-running applications do not
tend to bloat, and it is the first step in the way of having a
compacting collector.

Memory consumption reduction: Mono's memory consumption is
lower
than ever, and for GUI applications, it actually consumes less than the
equivalent programs written in Perl or Python. It has been an important
goal of us to reduce memory usage in Mono. Java, in particular, made
people afraid of large virtual machines, and we are working very hard
to avoid giving anyone that impression.

Ahead-of-time compilation: Although present in the Mono 1.0
release, this feature that is used to basically pre-compile all of your
bytecode into native executable code has been vastly improved. In Mono
1.2, we redesigned it not only to minimize the run time, it is now
designed to minimize memory usage by having multiple Mono processes
share the same pre-compiled code by using position-independent code.
This is important when people are running multiple Mono applications on
their desktop.

Java support: The IKVM runtime for Java is now part of the Mono
1.1.
x releases. Thanks to the help of Jeroen Frijters and Zoltan Varga, the
support for IKVM in Mono is now superb. It is possible to mix Java code
and C# code in the same application and consume the most exciting
pieces of Java components from Mono applications today.

Gtk# improvements: The binding has been improved and now also
supports new versions of Gtk+. The improvements are too many to list,
but we are using it actively on some projects, like MonoDevelop and
Stetic.

Documentation: We continue to consider documentation as key to
Mono,
and our Wiki-like documentation system has been great in allowing
developers to correct and update the documentation we ship.

Cocoa#: This is an application stack for OS X developers that want
to use the C# and the CLI to develop native OS X applications, very
much in the same spirit that Gtk# is used to develop native Linux
applications.

Another effort we are working on is a certification program of
third-party components and compilers. This will help potential users
pick components for their applications and have their components
supported by the producing companies.

Oreilly.com: What have been the
biggest development challenges the Mono
team has faced?

de Icaza: I think every aspect
of the system was fairly hard. Nobody in
the team had built something of this size and scope before. It has been
four years of very intense activity.

The code generator was a large project. The batch compiler was
another
one. The web services stack, the Gtk# binding, the WebForms framework,
our Apache integration, our C# compiler, the Tds and database providers
have challenges of their own.

Oreilly.com: What would you
like others to pay notice to the most about
Mono?

de Icaza: We are making Linux a
fertile ground for third-party
developers: we are allowing developers with Windows/.NET expertise to
use and distribute software for Linux, easing the adoption of Linux.

Oreilly.com: Personally, what
motivates you to keep working on Mono?

de Icaza: A fantastic community
of developers, users, and friends that
make up Mono today. Many products at Novell are now using Mono: iFolder, ZenWorks, F-Spot, and Stetic. [Knowing that] seven
of the 20
top-rated applications on GnomeFiles
are Mono-based. (Figure 3.)

Figure 3. Muine, a music player, is
another GNOME application that was developed with Mono

Oreilly.com: What about the
legal concerns/patent issues with
Microsoft's .NET? How do you clarify these issues and questions that
many developers still have about Mono's connection to .NET?

de Icaza: Every piece of
software written today is likely going to
infringe on someone else's patent. Sometimes the infringement is
serious; sometimes it is not. This depends on whether the patent that
was granted was valid (i.e., it did not exist before, and it was not an
obvious extension to something existing). The software patent problem
is not limited to Mono. Software patents affect everyone writing
software today.

Our strategy in dealing with patents in Mono is the same strategy
that
any other software developer would take. In the event of a patent
claim, we will try to find prior art to the claim of the patent. If no
prior art can be found, we will try to find an alternative
implementation that will not infringe the patents. If none of the above
can be done, we will remove the infringing code from Mono.

Dealing with the last bit, what happens if we have to remove
functionality from Mono? One option is to have the compiler recommend
the use of a different set of APIs [or] ship tools that can convert
existing code to use a different set of cross-platform APIs.

At this point there are no concrete, validated patent claims that we are aware
of [with Mono].