We had a chance to catch-up with Miguel de Icaza, founder of the Mono project and it’s new parent company, Xamarin. Some of the topics we covered include the future of ASP.NET MVC on Mono and the end of the Moonlight project.
InfoQ: Mono has supported ASP.NET since the early days. Do you see it as just a checkbox feature or is there a lot of interest in ASP.NET on the Mono platform?
Miguel de Icaza: We have not done a survey in a while, but on the last survey that we ran, ASP.NET on Unix was still a feature that people cared about. I would say that the interest declined when Microsoft fixed their licensing for Windows Servers, so the financial appeal of Mono was reduced in those cases. Nowadays, the main driver is to run ASP.NET when the rest of the stack is mostly centered around Linux.
InfoQ: ASP.NET MVC has been open source for a while now. In the past, how much effort was needed to make it compatible with Mono?
Miguel: It was very easy to get MVC 1 and MVC 2 running with Mono. With MVC3 things changed, since MVC3 was open source, but took a few dependencies on libraries that were not open source at the time, or were transitional libraries. So supporting MVC3 was easy, but deploying it was. It was a very rare to see an MVC3 site deployed with Mono, it was just too difficult.
With the recent opening up of the Microsoft ASP.NET libraries this has changed, and we managed to make MVC3 work out of the box with Mono.
Finally, for MVC4, we won’t be able to run this for a while, since MVC4 requires us to upgrade the core ASP.NET engine to support the new async pipeline and currently nobody is working on it. It will be a matter of whether people care enough to contribute those changes to Mono and make this run.
InfoQ: Do you see the ability to contribute directly to ASP.NET MVC as a significant advantage for maintaining compatibility?
The main benefit of the open sourcing of ASP.NET MVC is for its own community: for too long innovation, bug fixing an extensions has been limited to what the developers at Microsoft did, could do, or were able to specify. This will bring ASP.NET in line with other open source frameworks that evolved quickly and responded quickly to change.
InfoQ: Right now, there are four different XAML-based UI technologies: WPF, Silverlight, Silverlight for Windows Embedded and Silverlight for Windows Phone. With the introduction of Windows 8, we will be seeing a fifth version? What is your opinion of this diversification?
Miguel: We are currently focused on C# for Android, iOS and Mac so we do not tend to interact much with XAML based frameworks.
There are interesting parts to XAML, but I was never completely bought into XML for the markup. I wished for a very long time that they had adopted something simpler for humans to produce, like using Json for the markup, or the markup that was part of JavaFX. It was just as easy to consume and maintain with tools, but it was also easier on the eye for programmers and easier to type.
At one point we implemented an open source rendering engine that was capable of rendering Silverlight 3/4 markup.
These days we tell developers to split their application in two: one reusable layer of code that can be used across all .NET/Mono platforms and another layer that implements the presentation layer. Either a native UI for iOS, Android, Mac or Windows, or an HTML version of it.
InfoQ: A lot of developers are turning to platforms such as PhoneGap to standardize their UI code across platforms. Do you ever see a point where C# will likewise have a UI library that can work across iOS, Android and Windows Phone?
Miguel: There will be a blend of those.
Sometimes you are on a short budget, and you use a write-once-run-anywhere presentation layer. This has proved popular for Java and we are using it ourselves for some or our tools with the Gtk# and Xwt libraries.
But sometimes you want to deliver a best-of-breed user interface, and you need to write custom native code. We have also been doing this with some of our tools, like our new documentation system for Mono which is now native on each platform
Particularly in the Mac and iOS space, users place a high value on the finished quality and native UIs, so a cross platform UI would not really deliver the best experience to users.
InfoQ: Before Novell was bought out, there were some people working on getting Moonlight to run on Android tablets. Is that effort still underway?
Miguel: We have abandoned Moonlight.
InfoQ: I'm sorry to hear that, Moonlight looked very promising. Was it just a lack of manpower or do you there is no longer a future for browser-based Silverlight/Moonlight?
Silverlight has not gained much adoption on the web, so it did not become the must-have technology that I thought would have to become.
And Microsoft added artificial restrictions to Silverlight that made it useless for desktop programming.
These days we no longer believe that Silverlight is a suitable platform for write-once-run-anywhere technology, there are just too many limitations for it to be useful. These days we believe that in the C# world the best option is to split the code along the lines of the presentation layer. The user would reuse a core part of their application across all platforms, and write a new UI specifically for each platform they target: iOS with MonoTouch, Android with MonoDroid, Mac with MonoMac, Windows with WPF or Winforms or Mac, Web with ASP.NET and Windows and Linux with Gtk
It is not write-once-run-everywhere, but the result are applications that can exploit the native facilities and create native experiences on each platform.
InfoQ: If you had more volunteers for the open source parts of Mono, which areas would you most like them to work on?
Miguel: I would say work on the upcoming 4.5 API as well as WCF.
Microsoft has updated many of their APIs in .NET to be C# 5 async-ready. Although we have done the work on the base class libraries, I would personally love to see both our System.Data (and derivatives like our Sqlite providers) become Async-ready as well as the ASP.NET stack which now also sports an async pipeline that developers can take advantage of.
The ASP.NET improvements are necessary to take advantage of all the code that Microsoft recently open sourced for ASP.NET. Without these changes, Mono will not be able about half of the new open source code, or will be limited in how much it can reuse.
InfoQ: I assume you have been following the Oracle/Google lawsuit over the Android API. What's your take on the situation?
Miguel: It looks like a war, and after the first round of shots have been fired, nobody is innocent and nobody looks good. It has damaged the reputation of both companies.
InfoQ: Are you concerned that, if APIs are found to be copyrightable, that Microsoft may threaten the Mono project?
I am not.
In the Google/Oracle debate the issue is over some core APIs, because none of the high-level APIs reached the point that they would be useful in this multi-billion dollar fight. Google basically chose to not adopt the high-level bits because they needed a different set of APIs suited for the Android form-factor. In the Mono/.NET world, the copyright of the core APIs was granted to ECMA/ISO for distribution and the high-level APIs remain of dubious use for a multi-billion dollar industry. If a multi-billion dollar business emerged around .NET/Mono, it would likely use the core, and rip out all the high-level stuff, very much in the same way that we did for MonoTouch and MonoDroid: we use the core, but do not expose any of the high-level Windows-y APIs, and instead replace it with native Apple or Android APIs.