July 16, 2004

The downlow on Mono

Author: Joe Barr

After three years and much controversy, Miguel de Icaza's Mono project has finally released its 1.0 version. NewsForge recently talked with Erik Dasque, the senior project leader for Mono, about the release of 1.0, the controversy and criticisms encountered along the way, and the plans for the future of Mono.There was mass confusion -- both in the press and in IT circles -- when Miguel first voiced his admiration for .Net's possibilities and outlined his plans to base a new development environment for Linux on it. Miguel explained precisely what he had in mind for Mono in a lengthy article published on Linux Today in 2002:

Mono is an implementation of three pieces of technology:

* A compiler for a new programming language, similar to Java, called C#.
* A virtual machine for the Common Intermediate
Language (CIL) byte codes.
* A set of libraries that encapsulate useful routines and classes: from hash tables, to XML manipulation, to database management, to GUI applications, to Web construction tools.
These are usually referred in the Microsoft world as the .Net Framework, as opposed to .Net.

Fast forward to today. Mono 1.0 has just gone out the door, under the aegis of Mono project leader Erik Dasque.

Barr: What is your background with Mono? Were you involved from day one?

Dasque: No. I come from a J2EE background originally. I got involved maybe a year ago with Mono, as Novell bought Ximian and we started to look at Mono and then see what we could do with it. I kind of jumped ship and went to the Mono side and I've been the senior project manager on Mono since then.

Barr: That must have been an interesting experience for you. Was that your first experience with open source?

Dasque: No, no, I've been actually involved with Linux since 1995 or something like that. And I've been involved with Unixes in general for awhile, so it's not like I came completely blank-sided from a Java world.

I knew what to expect from an open source world, I knew what to expect on Unix, and I knew why Mono was really necessary to have on the Linux platforms, for the Linux platform to become successful. Coming from the Java, J2EE background, I think it gives me a really interesting perspective on enterprise development, and what Java was on the desktop, how it felt on the desktop, and how can we can make Linux and Mono successful on the desktop, as well as on the server.

Barr: Is Miguel still hands-on involved?

Dasque: He is very hands-on. I think what I am able to do is kind of deliver Miguel from some of the project management tasks -- things like dealing with customers, Web site, ISVs, some Novell things. Miguel is able to focus on the technical stuff. If you go to see the source tree, and if you look at recent developments, you'll find that Miguel is still happily coding away.

Barr: How long was it from inception to release of 1.0?

Dasque: It took three years, pretty much exactly.

Barr: Is that about what was expected?

Dasque: No, it wasn't. I think what happened is the classic, "OK, we need a few more weeks to do that, but since we have a few more weeks why don't we add a few things."

The landscape changed a little with us participating in the ECMA meetings with Microsoft, HP, and Intel, to kind of define the future of those specs that affect the .Net platform.

So it was kind of a long time coming. It was a large development. It involved a lot of people. The project grew to be, I think one of the top open source projects, with 150 contributors total. It puts it on the map together with GNOME and KDE and Mozilla and those types of projects. If you look at SourceForge stats, the average open source project is about 10 people.

Barr: What is the mood of the development team now that 1.0 is out the door?

Dasque: It's a really interesting mood, because as we mentioned earlier, it's a project that took three years to release a 1.0 version. So a lot of us are like, "Wow, we did it, we shipped it!" I think it's really important that we shipped, and that we shipped something that we're proud of, because a lot of people basically said, "It's never going to happen, it's never going to release 1.0. They're going to stop and abandon the project."

So I think it was really important for us to release, not just release a 1.0 version, because we could have done that two years ago, but a 1.0 version that is on par with what Microsoft is shipping today. And on top of that, offer all the Mono exclusive features that we think are necessary on Unix platforms, and particularly on Linux. So the mood is kind of like, "Wow, we shipped it! Now we have a clear roadmap for the future, let's buckle up again and ship a new version early next year, that will have even more great stuff."

Barr: Can you highlight some of specific Unix/Linux additional features?

Dasque: I think a lot of people view Mono as a .Net clone, and I think it goes well beyond that. I think the fact that it's a .Net implementation is great. It's a means to an end. But our goal was not to create a .Net implementation. Our goal is to deliver a development platform that works for Linux, that is what Linux needs to kind of go beyond what it has achieved to date.

Coming from the Java world, I can see that Java on the desktop was almost like VMware or Virtual PC in a way. It never really actually touched the host operating system all that much. Java ran anywhere and looked the same everywhere because it was kind of almost-an-OS within an OS in some ways, and it would only rely on the very low-level host OS to provide some services. But as far as UI, for example, goes, it was very much isolated from the OS.

We certainly didn't want our implementation of .Net to be like that, because then it doesn't make it as useful. It just makes it as an implementation of .Net, not a development platform for Linux.

We need to kind of bind it to everything Linux. Now that's pretty easy at the low level, because I don't need an API to write a file -- you need to rely on the Linux underlying functionality to do that.

But what if I want to open a window? What if you want to really integrate with Linux at the graphical toolkit level, be it GTK or others? What if you want to integrate with existing software? So we have a lot of things that allow you to do that.

Linux is as much GTK as it is Mozilla, and Mozilla is as important to Linux as GTK is, in a way. Because Mozilla kind of became -- at least on GNOME -- the key browser to use within your application.

If you look at Windows, if you look at most applications on Windows, in some way or another, they use Internet Explorer Active Control. Outlook, for example, to represent HTML, will go use IE. Well, we need something similar on Linux with Mono. So what we did is that we have a few libraries that bind into -- on one side, graphical aspect of Mozilla, the HTML page rendering, and on the other side, more the "xp.com" type functionality of lower-level interfaces, to Mozilla.

And that's true of Mozilla, but we have the same thing with MySQL. When you write an application on Linux, a number of times you won't want to go against Oracle or Microsoft SQL Server. You'll want to use the open source databases that are available on Linux, and that's PostgreSQL and MySQL, mainly.

So we've written and included libraries that allow you to access those. Other examples are Zip and encryption libraries. Another key example is GTK-sharp, which is not only wrapping around the GTK libraries, the GTK-plus libraries, but it goes beyond that because it's a .Net API.

It's not something you're using, this weird set of classes, that have nothing to do with the way you normally use a .Net graphical library. It's GTK "dot-net-ified" in a way. Not only just wrap some methods and some objects, but actually deliver something that makes sense from a .Net point of view.

So that's one really important thing. As far as Mono exclusive features, there actually are two more things. One of them is XSP and mod-mono that on one side are ASP.Net server, and on the other are the Apache plug-in that allows you to serve ASP pages from Apache.

That's absolutely necessary. If you're going to serve ASP.Net pages on Linux, you know, even if we deliver something called XSP, which is a mini ASP.Net server, you're going to most likely want to do it with Apache. So we deliver a plug-in to Apache, and a server, that allow you to serve those ASP pages within the realm of Apache.

The last thing that we provide is an embedding API that allows you to take any existing C, C++, Perl, or other piece of software and embed Mono in it. If you want to open your software to people writing plug-ins for that software, they're not using C or Perl, but using a managed language like C#, or Java, or VB.Net.
It's important to be able to do so.

An example is we ran a contest with Evolution where we would give away prizes or money for people who could write interesting Evolution plug-ins. It was quite successful, but not the success we expected, because not only is it extremely difficult to come up with the energy to write a plug-in for Evolution -- because it's such a complicated piece of software -- but you have to do so in C, and there is not much of a plug-in API.

So the Evolution team -- I think it was Jeff Steadfast -- created something called Evolution-sharp, which is essentially the embedding of Mono within Evolution. If you need to write plug-ins for Evolution, you do so using those managed languages, and Evolution opens up some of its API to those plug-ins.

There is actually one more Mono exclusive feature that I think is important. It's the inclusion of Java within Mono. We don't want Mono to become a Java-versus-Mono type fight in a religious "Emacs versus vi" type war.

The virtual machine that Microsoft .Net is an implementation of by design supports multi-languages. You can see that on Mono and Microsoft .Net, you can see that with VB.Net, C#, Python, etc., etc. And we wanted it to be the same way for Java; we didn't want to isolate ourselves from the Java world.

So we partnered with a project called IKVM, and classed that to allow you to use Java within Mono in a variety of ways. You can just write your application using the Java language, that's fine. You can use existing Java libraries, that's fine. You can use existing Java libraries and can turn that into CLI. You can pre-compile or post-compile those. You can actually run Eclipse on top of Mono, Eclipse 2 and Eclipse 3.0 on top of Mono, which I think is not only a good sign, but a good proof that our implementation works really well.

More on page 2...

Barr: One of the things I heard Miguel and the project attacked for was the assumption that Mono was going to help Microsoft lock everybody in to Microsoft products. What you've just outlined gives people freedom of choice for the three main things that Microsoft intends to us to lock people: the browser, the Web server, and the exclusion of Java language. Is that just a coincidence?

Dasque: No, it's not. We've been attacked by people saying, well, if you implement .Net on Linux, you're basically extending Microsoft's reach on Linux. I've thought about this question a lot, and I've got a few answers to that.

The first one is that what we are trying to do is build a development platform for Linux that makes it easy to build applications on Linux, because today it's not.
Because we have chosen .Net to develop that platform, we can easily seduce developers that have been using the Microsoft platforms for 10-plus years onto the Linux platform, so basically that effort is making the Linux platform an easier platform to move to, to write applications to, and down the line, to use.

And you know, that can't be playing into Microsoft's favor, because basically it makes the Linux platform a better platform for people to use. What does that mean? It means less license of Windows, and we know how Microsoft makes money. They make money with Windows and Office. And on Linux we have OpenOffice.org, and now we have a great alternative to the Windows desktops.

Second, people say if you have .Net on Linux, Microsoft just has to change .Net and you guys will have to move back to Windows. What does that mean? That doesn't mean anything.

If we make Mono successful, if we make Mono a great development platform on Linux, and people start moving to Linux, we're the one that are actually locking them into Linux, because they start using it, and it's good, and they start liking it, and they start using only Linux.

So I think it's a way to use Microsoft's marketing and R&D dollars to Linux's favor, and I don't see that as opening a lock-in possibility for Microsoft. So I think that the critique that we are getting from different people regarding that -- and I'm not going to attack them personally -- but it's probably people who have no vested interest in the Linux platform, but more in the interest of their own company, which is delivering some competitive products on the Linux platform.

We've tried to work with different companies that are working on the Linux platform and delivering products, and they chose to go another way. We're just delivering software. We're don't spend too much time on blogs just defending it, we're trying to deliver something that's good.

Barr: Did the personal attacks on Miguel and others involved in the project have any effect on the development process?

Dasque: I don't think it had that much of an impact. If anything, it allowed us to have some discussions internally, and maybe revisit some of our decisions and improve on our implementation. I don't think it had any negative impact.

Even if from the outside world it seems like those are pretty harsh personal attacks between the different parties, I think in the end we all go out and get a beer. It's the open source community, and it's a lot of people with strong personalities and great technical skills. At the end, you know if we can make the whole thing successful -- Mono or Linux or just the open source software movement in general -- I think that's what we want.

Barr: How is 1.0 being received?

Dasque: Well, first we were able to launch 1.0 having a few customers already using Mono, which I think was good. We changed to a new Web site that's a lot more targeted at people wanting to learn about Mono, wanting to use Mono, rather than the people wanting to contribute to Mono. So there's still all the contributing section, and all that content, but we added a lot of content for people wanting to use it and not necessarily to get involved in pure hacking of the Mono source tree.

So I think that was important, and that shows a shift of Mono saying, "I think we've released something that everybody can use. Now go and use it, because we are proud of what we've done."

Just to give you an idea, when we launched Mono 1.0, the Mono Web site -- which is monitored by the same tool as the Novell Web site -- the Mono Web site was responsible for more than 25% of the traffic of Novell that day. It accounted for 200,000 page views, and thousands and thousands of downloads.

We were also Slashdotted, so for a while we were not able to serve all the downloads. Things have calmed down now, and people are able to download without difficulties. That's the launch, we're very happy with that. Now we have lots of new content, and packaging not only for all the Linux distributions we are targeting but also Mac OS, Solaris, and S/390. That's very important to a few customers as well. As well as our Windows implementation, which is always our sanity check. It allows us to make sure that everything runs everywhere. That's the launch.

Barr: What's next?

Dasque: We're practically finished with the planning for Mono 1.5 and Mono 2.0. It's pretty simple, it's pretty straightforward, really. One thing that we haven't been able to deliver with Mono 1.0 is a final Windows system for implementation, because we were very focused on GTK-sharp at first, and a final VB.Net implementation. So both of those will be in 1.5, and in addition to that we'll have improvements to our existing "Mono Exclusive" stack. So some of the things that I've mentioned earlier, as well with Mono 1.5 previews of .Net 2.0 features.

With Mono 1.0, we've delivered generics in a final form, which is something that Microsoft hasn't done. With 1.5, we'll deliver things like anonymous methods, anonymous delegates, and things like that, which are also important that Microsoft won't have delivered by then, yet. If I were to sum it up: finish a few things that we haven't delivered with Mono, deliver previews of .Net 2.0 technologies, and deliver updates to our "Mono Exclusive" stack. Thats going to happen in early 2005. We're shooting at February 2005 today.

As for Mono 2.0, you know, a lot more in the future. Probably early 2006 or late 2005. There we're looking at delivering the final version of our .Net 2.0 compatible world, as well of course, as updates to all of the Mono stack things, so we're finalizing plans for that.

We already have people working on 1.5, of course. The 1.0 tree is not closed because we are probably going to have some minor release, 1.01 or something like that, to fix some annoying bugs. And some people have started to work on 2.0 things, as well.

Barr: Thank you, Erik.

Click Here!