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.
A few of the attributes that Mono [has] over traditional environments are:
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:
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:
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].
Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others.
Return to ONDotnet.com.
Copyright © 2009 O'Reilly Media, Inc.