Interviewers: Scott Swigart and Sean Campbell

Interviewee: Joseph Hill.

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 solutions. From Miguel’s standpoint, enabling other operating systems to be virtualized carries with it a certain amount of overhead. It is nice that you can solve a lot of problems with virtualization, but that doesn’t necessarily make it the best solution for everything.

Scott: I could see someone thinking of Mono as being just an on-ramp to Windows. They might see it as a way to get people hooked on the .NET framework and C# so they might eventually just take the easier route and use Visual Studio running on Windows.

I see an opportunity in the other direction, though, and I wonder if you have seen much interest from vendors who sell hardware appliances or virtual appliances. For a Windows developer, building an appliance that runs full Windows might not be as attractive as using Mono, in some cases.

It is kind of a heavy weight operating system, and the server core of the .NET framework doesn’t currently run on Windows Server Core. A lot of appliances use Linux as an operating system, and it seems like low hanging fruit for a Windows developer to build a .NET application for deployment with just enough Linux OS with Mono on top of it. Do you see any interest in that?

Joseph: Absolutely. It’s relevant to both the appliance story and to development more generally that we are all big fans of Visual Studio. As somebody who has been doing ASP.NET development and .NET development in general for several years, I think it is a great IDE.

One great thing is that building an application and compiling it in Visual Studio leaves you with a binary compatible assembly that should be able to run on Linux. To the first part of your question, as much as it is about bringing tools like C# to people developing for Linux, we are also opening up the possibility for Visual Studio developers to develop for Linux.

As to the second part of your question, people who have been developing for Windows are considering Linux because of the opportunity of virtual appliances and appliances in general. We see that as a real advantage for Linux and for Mono.

To that end, Novell participates in the JeOS project, which stands for “Just Enough Operating System.” We have a product that has been demonstrated–SUSE Studio–that allows people to create appliances through a web interface. It allows a .NET developer to take their ASP.NET application and use the SUSE Studio to create an ASP.NET appliance or .NET appliance that they can turn around and take to a virtual host or distribute as a singular piece.

Sean: Have you ever thought that it would be nice if the Visual Studio field reps would like to promote Mono, or develop some other type of relationship? Do you feel like there is any potential for you to work closely with the Visual Studio team to support customers who want to develop cross platform, or do you feel that the gulf just hasn’t really been bridged yet?

Joseph: Some people who work on the .NET framework, including some of the decision makers, are interested in Mono on a personal level. Some individuals there see certain aspects of the potential of .NET being realized by Mono, although the company as a whole doesn’t say a whole lot about it.

The Moonlight opportunity has been really the strongest endorsement we have gotten from them; they see it as a .NET implementation on Linux that can be used with Silverlight, and Microsoft wasn’t going to deliver that.

Both Microsoft and Novell need to provide what customers want, and in the long run, I guess they will decide to collaborate where it makes sense. It would be nice to see more collaboration; we really like a lot of those guys there.

Sean: They see Moonlight as a really nice counterbalance to Adobe, since you can’t run Flash on multiple platforms, and they don’t have to invest development team resources, either. Do you feel that this is primarily a way to combat Adobe without having to form a formal alliance?

Joseph: That is probably part of it. Microsoft going after Adobe is obviously what Silverlight is about, and with their initial plans to only go after Windows and Mac, I think they felt like they had addressed enough of the desktop world’s needs.

What I think Moonlight brought to the table more than anything was an opportunity to address people’s concerns about the open web, which has become more important in the time since the Silverlight announcement.

Silverlight’s design already had a lot that was open about it, and Microsoft really had no intention or business need or desire to put something out for Linux. I think allowing us to make the official solution there complemented that open story more than anything else.

Sean: Catering to the developer community’s needs in terms of what they want in the language, compiler, and feature set, as well as platform issues and support is one whole thing, and building an IDE that makes them happy is a whole separate undertaking.

Why did you choose to go down the road of building your own IDE as opposed to just plugging into something like Eclipse or some other direction? That seems to be a massive investment, while at the same time you need to catch up to the afterburners-driven .NET framework without getting left way behind.

I imagine that, no matter how well they may be communicating with you, they may still not communicate something important, for strategic reasons, which could leave you in a difficult position. The IDE seems to make that situation even harder, so you must have had some really good reasons for going in that direction; could you speak to that?

Joseph: Well, I wish that were true.

Sean: [laughs].

Joseph: Like I said, I am a Visual Studio aficionado, so I like the fact that we are enabling Visual Studio development, and I think we have a good story there. But early on, all the Mono hackers were using EMACS and VI, and Eclipse plugins do exist for doing C# development.

But, MonoDevelop was born as a fork of SharpDevelop, which was an open source IDE for Windows that the community outside of Novell decided to implement. It provided a lot of nice features for GTK+, and it was simpler than embracing Eclipse.

What happened as MonoDevelop matured and began to see adoption was that it took on sort of a public face of Mono that we weren’t able to control without contributing to it, so over time, Novell invested resources into making sure the MonoDevelop story is a good one. It is a pretty good looking IDE now, and it supports a lot of great features. I think its major benefit over Eclipse is that it behaves in a very Visual Studio like way.

People that are comfortable with Visual Studio but want to transition their development to a Linux desktop will be more comfortable working in MonoDevelop than they would be in Eclipse. It also offers the benefit of letting .NET developers work in C# running under .NET, rather than trying to get them to switch to a Java based IDE; that is definitely an advantage.

Scott: I think it’s really interesting that you are an avid .NET developer and you saw C# as an improvement over Java. I think it’s pretty clear that Microsoft looked long and hard at Java and C++ when they were designing C#.

Then Microsoft came along with Silverlight, and a lot of us thought that, since Flash is so entrenched, it would be nearly impossible for it to get traction. And then I went to NBCOlympics.com to watch some Olympics videos, and what did the site make me do? It made me download and install Silverlight.

That convinced me that maybe Silverlight has more legs that I thought. Do you feel that Moonlight and Silverlight could be the next evolution for that kind of rich web application, in a similar way to how C# is regarded by many to be an evolution beyond Java?

Joseph: I believe that Silverlight definitely has the benefit of learning vicariously through Flash’s history, and I also think that at the same time, a lot of people have seen it as trying to take on Flash, which they see as an impossible task.

Early on, looking at what Silverlight was trying to do, I even felt that way, since Flash is so firmly entrenched. But what the Olympics site and other sites doing cool things in Silverlight today are showing us is that rich Internet applications can now do some of the things that they have been trying to do for years but have been limited by performance of the desktop and bandwidth issues.

Flash has been fighting an uphill battle for years, to overcome the implementation, and now the advent of YouTube and things like it shows that RIA development has really come of age. Silverlight had the benefit of waiting for Flash to discover that the market was ready, and at the same time, it can add benefits over Flash that both developers and consumers will hopefully find valuable.

The neat thing for Silverlight is that, for it to be successful for Microsoft, it doesn’t have to beat Flash. Customers don’t have an either/or situation in terms of which control they want to install in their browser. Both plugins and additional RIA plugins can be installed in the browser with virtually no cost to the user, and it really is going to come down to developers’ preference.

As more customers begin to expect the kinds of experiences that Flash is able to deliver and now Silverlight, more .NET developers are going to be asked to add this kind of functionality to their web sites. The fact that a whole legion of .NET developers will now be able to write applications for Silverlight when they probably would have far less incentive to learn how to write applications for Flash could mean that you are going to see a lot of Silverlight adoption being enabled.

Scott: This was just a great conversation, and I really appreciate you taking some time out to chat with us.

Joseph: Thank you.

Bookmark this: