In this interview we talk with Joseph. In specific, we talk about:
- The case for developing for Mono under Windows
- Challenges in coupling open source development to Microsoft platforms
- The relationship (or lack thereof) between Mono and Wine
- Microsoft tools as they relate to Mono development
- Market evolution with Moonlight, Silverlight, and Flash
Sean Campbell: Joseph, would you introduce yourself and tell us a bit about Mono, Moonlight, and the kinds of stuff you work on?
Joseph Hill: Certainly. I am the Product Manager for Mono at Novell, which gives me the great privilege of working with Miguel de Icaza, who is the founder of the Mono project as well as GNOME and several other open source projects. Mono is an implementation of the .NET framework that is open source and available for Linux and Macintosh as well as Windows, Solaris, and any other platforms that people want to run .NET code on.
When Microsoft came up with the .NET framework and the CLR (common language runtime), they took steps to make sure that it would be available as a standard. They wanted to get participation from people involved in designing languages and runtimes, so they submitted their specifications for the runtime and the C# language to ECMA.
Miguel chose to implement Mono because he saw that C# is a very nice language that solves a lot of problems elegantly, so it would be a nice language to have available as an improvement over C and C++. The first target for Mono was for Linux desktop applications, where they built and offered GTK# as an improvement over GTK and GTK+, which is a graphics toolkit for the GNOME desktop.
The project started in 2001, around the time that .NET was entering beta. It has progressed from there to encompass a lot more of .NET. Since those initial libraries, Mono has taken on ASP.NET and WinForms implementations, and it has been used in various interesting circumstances.
Sean: There is a certain amount of skepticism about Microsoft in the open source community; people are always wondering what they are “really up to.” I would imagine that people must ask you fairly frequently why they would develop under Mono for Linux, instead of using Java or Python or PHP.
Joseph: I think it ultimately comes down to individual preference, and there are actually several different parts to that question. C# is a nice language, and we think it is an improvement over Java, because Microsoft had the opportunity to look at Java and to identify enhancements that they could make in a new language that Java couldn’t or wouldn’t.
That is part of what makes C# attractive, and beyond that, the runtime is capable of running code written in VB or several languages that target .NET today. That includes everything from the classic example of COBOL to the newer DLR focused languages like IronPython, IronRuby, and so on.
Mono means different things to different people. Some may want interop, while others want to consume libraries written in one language from another language.
Sean: One of the things that everybody points to in terms of building an ecosystem for their platform is the list of applications that are on it–they always have a marketing slide that says, “We have 3000 ISV applications.”
When you are out there evangelizing and touting Mono, what do you usually point to?
Joseph: If we do go back to the beginnings of Mono and GTK#, once we got a working GTK#, we at Novell started building a lot of applications. We were shipping .NET applications in Linux well before Microsoft was shipping any .NET applications bundled with its operating system, such as Beagle and F-Spot, which are desktop search and photo management applications, respectively.
The community also built several popular applications like Tomboy, which is a note taking application that is actually considered part of the GNOME standard desktop now. So, there are a lot of popular applications on Linux and a community there.
There are also ISVs such as Medsphere shipping GTK# applications that basically chose Mono because they like .NET and they wanted a good cross platform story for the product they offer in the healthcare industry.
This historically has been the story of GTK# on the desktop, because we ship a very nice desktop, but with the state of Mono today supporting ASP.NET and Windows Forms, we are working to get library vendors and third party control vendors that ship managed applications or managed components to certify that they work on Mono.
Sean: It sounds like you guys are really collecting and putting a lot of evidence out there to show people that this isn’t just kind of a hobby; people are doing real stuff on this. People are making business decisions based on the viability of Mono to be able to run production code on Linux, and it gives them reach across more platforms and it provides a lot of advantages for them.
Joseph: The fact that I have been hired into the role that I am in is a clear indication that Novell feels Mono is ready to be used for more than just the applications we have been building. Going forward, we are working to attract ISVs to the platform as well as building out end user customer stories, where people have chosen Mono to deploy on and to build for.
We think that that enhances the story for being able to take customers that have already chosen .NET as their platform, but don’t want to be limited to just Windows as their target. We give them a way to grow their addressable market.
The other indication I can give is that we are releasing Mono 2.0 in October. That version number is really a statement on our part that Mono is ready to support what customers want from .NET 2.0. .NET is a really big platform and it just gets bigger with every release, but the portions that customers are using tend to cluster around specific functionality.
ASP.NET has been around for six years and has a really huge part of the web’s market; we support applications based on ASP.NET 1.1 and 2.0 and AJAX very well. Beyond that, the majority of what people are doing with ASP.NET is 100% managed.
At this point, customers have ASP.NET applications that don’t depend C++ code, and very little ASP still exists in people’s code base if they have adopted ASP.NET as their platform. Mono can do these things really well without the need for full implementations of WCF or WPF and other recent additions to .NET.
Sean: What challenges do you have in trying to shadow the .NET development process? We talked to the head of the Wine project, and it was interesting to hear about the challenges that surround shadowing the Win32 API. What challenges have you faced, and what observations can you make about the evolution of the framework, given how close you guys have to follow the development process?
Joseph: To rewind back to the beginning of the story again, initially the goal of the Mono project was not to emulate what Microsoft was doing; we really just wanted access to the runtime and the C# language. ASP.NET 1.1 was very small and very simple, and it was implemented by very few engineers in a relatively short amount of time.
ASP.NET 2.0 grew a lot from that. It definitely added a lot to the library and the APIs increased by something like 10 fold, but we still had a working ASP.NET 2.0 implementation becoming complete by the end of 2006 when ASP.NET 2.0 had come out in 2005. Even though we are releasing Mono 2.0 today, the 2.0 release has largely been held up by our WinForms implementation rather than the ASP.NET implementation.
Ultimately, we had to add WinForms to the project because we saw increasing demand for it. When we first released Mono 1.0, we didn’t really have a WinForms story, even though we had an ASP.NET story.
We weren’t even seeing that much of an uptake of WinForms or a large desire to try to emulate it, but as more customers writing desktop applications began to adopt the Windows Forms platform, it became evident that people expected Mono to have that.
That was when we really saw the need to make the decision to start chasing the API. My personal view is that it creates its own set of problems, and I’m sure we have a lot in common with the Wine project in that regard. Things don’t always work as they are supposed to or as advertised, but you have to match the implementation and the behavior of the existing implementation.
WinForms applications tend to have more of a legacy than ASP.NET applications, where somebody had a desktop application and desktop components that may have been around for a lot longer than the company’s adoption of .NET, and those components tend to live on.
Sean: Do you guys have to rewrite every assembly from scratch? On the one hand, there is the low level stuff that is going to be called into the API, but then on the other hand, in the .NET framework there are higher level control libraries, and they are not calling directly into Win32 APIs; they are just calling to other parts of the framework.
Do you have to re-implement those as well, or are you able to just carry some DLLs that are part of the .NET framework on Windows as part of Mono?
Joseph: From a licensing standpoint, that is not allowed, so we write our own implementations for all of those. That does cast light on our WinForms implementation. We took a couple of stabs at it, and the first time around, it was going to be a wrapper around Wine, actually. There were various difficulties with coordinating changes that we had to make to Wine to get our implementation to work right, and it was complicated getting those patches accepted upstream.
Scott Swigart: That’s interesting, because I have wondered whether you ever considered just building something on top of Wine–maybe focus building an IDE and the higher level abstraction while letting them figure out how to make the framework talk lower down.
It sounds like you eventually found it easier just to take it on yourself.
Joseph: That approach let us avoid that dependency, and leveraging Wine for what we are doing was also a bit architecturally convoluted, relative to the 100% managed implementation that we ultimately arrived at. Basically, we draw every component using System.Drawing, which means we have an unmanaged GDI implementation, and we call into that from System.Drawing.
All of our components are managed, whereas Microsoft’s were all wrappers around existing Win32 controls. That ultimately gave us the benefit that, once you have a System.Drawing implementation working on a platform, you are capable of running WinForms on that.
So, dropping that Wine dependency actually worked out really well, because now we have WinForms running on Mac without a Wine dependency. All you need is Mono and GDI, which we make available in our Mono installation, and then you have access to WinForms.
Sean: What do you think about the potential impact of virtualization on the desktop? Do you see a possible future where you would focus more on IDE development and interprocess communication between two OSs’ different apps, and less on trying to build a portable dev platform and framework?
There is still benefit to that, even in a world where everybody is drawing a virtualized set of partitions on a machine, but do you guys ponder that from day to day? Do you wonder what the impact of KVM on the kernel will be, how you leverage it, and that kind of thing?
Joseph: I wouldn’t say we think about it from day to day, although of course, we keep an eye on adoption and how the Linux desktop is enabled or hindered by virtualization