Xamarin will ensure that .NET developers can continue to use MonoTouch and Mono for Android for iOS and Android mobile app development
Editor's note: Welcome to .NETRocks Conversations, excerpts from the .NET Rocks! weekly Internet audio talk show. Hosts Richard Campbell and Carl Franklin chat with a wide variety of .NET developer experts. This month's excerpt is from show 693, with Miguel de Icaza and Nat Friedman of Xamarin, a company they founded in 2011 to market and support the MonoTouch and Mono for Android .NET-based mobile development environments. Miguel, CTO of Xamarin, and Nat, Xamarin's CEO, discuss Xamarin's founding and where the company's products fit in the .NET development world.
Carl Franklin: Welcome, guys. Some changes have been happening around .NET, and mobility, and Mono, and all that great stuff. Who wants to catch us up on what's happened with you guys?
Nat Friedman: Miguel, you want to take it away?
Miguel de Icaza: We started Mono a few years ago because we wanted to get the same sort of rapid development and benefits that .NET had. Now all of us are running around with these tiny computers, and some of them are programmed with Java, and some of them are programmed with Objective-C, and we felt that there was a very natural path for Mono to grow. We brought Mono, we brought .NET to the iPhone and the Android platforms.
What has happened with the mobile space is just incredible. This is measured in the thousands of developers, and the users are measured in the millions. So we knew that the space was hot, but it wasn't until we started building Mono for iPhone and Android that we realized just how hot this thing was and how exciting this mobile space was.
CF: So we all heard the news a little while ago that Novell was sort of scrapping the Mono project, and we didn't really know what was going on. Can you tell us the story about what happened?
MD: Yeah. We had internally discussed at Novell that the Mono project was not really aligned with the enterprise and IT focus that Novell had at that time. While this was happening, Mono started to shine in the mobile space. It started to have this growth that I just described, a very big growth in the mobile world, and that's really a developer place, and it wasn't really aligned with what Novell wanted to do.
CF: So basically they didn't see mobile coming?
MD: It's not that it's not coming, but I think it's important to keep focus in your company, and you can't really try to do everything at once and hope to do a good job there. So there was already talk, even before any of this happened, of spinning Mono into a separate company. Then this whole almost a year-long process that started with a bid from a finance firm to the actual sale of Novell. That kind of put things on hold.
MD: And the new owners, I think... they wanted to go into the businesses that Novell was [in], and Mono is a developer story. Mono is not really part of a bigger enterprise story.
CF: Well, it's just weird because Microsoft has always had the idea, and rightly so, that
developers make a platform. So Novell, I guess, didn't have that philosophy, or is it because they couldn't monetize it? I mean, obviously that's what you're doing now.
MD: Right. We're selling to developers, and Novell was selling to the system administrators and CIOs.
CF: So you got back together with your Ximian folks, called it Xamarin, and now you're open for business. Tell us about the difference between Mono the free product, and MonoTouch and Mono for Android and the things that you're now selling at Xamarin. Is it the product we know and loved that we've been using all along?
NF: It is.
CF: MonoTouch for Apple products and Mono for Android.
NF: Right. When Miguel and I joined forces here on Xamarin, we knew that the big interest was around mobile.
NF: Miguel and his team previously built these products, MonoTouch and Mono for Android, at Novell. There had been a lot of interest and some amazing success stories of people building great apps with them. So I said, that's what we need to do. But though Mono is open source, those products are proprietary, and they were owned by Novell. So the key question was, how do we get these things back? There were two choices. We could rewrite them from scratch, or we could acquire them from Novell in some way. We could come to an agreement with Novell that would allow us to use the intellectual property and build on it, build a real company on it. So we pursued both paths at once. We tasked Miguel's team with rewriting from scratch these products in a clean-room way, and at the same time we started a conversation with Novell.
Novell had thousands of customers who had bought MonoTouch and Mono for Android and had, in addition to the money they spent buying the product, invested hundreds of thousands or millions of dollars building incredible mobile apps on top of them. So they needed a path forward. Mono is also a key part of SUSE Linux, the Linux distribution from Novell, and there are a number of customers who depend on Mono as part of the Linux server. So Novell needed a way to support them. So we came to a fantastic agreement with Novell where we said, hey, we need this code, so they licensed us the code, they gave a phenomenal license for MonoTouch and Mono for Android and all the Mono intellectual property, and in return we're supporting the Novell customers.
Richard Campbell: So what about MonoDevelop, MonoMac, and some of those other Mono-related libraries?
CF: And what about Moonlight [an open source implementation of Silverlight] for that? It's surprisingly missing.
MD: Right. So the Mono ecosystem of course is very large. Some of those [projects] Novell has contributed to or a third party has contributed to. So the Mono community has been developing those pieces.
Let me take a step back. So as part of the product that we launched, MonoTouch and MonoDroid, we consumed some of those open source technologies; we consumed the Mono runtime, we consumed all the Mono compilers and libraries. We use the MonoDevelop IDE and other assorted components from projects and other projects. Since this is kind of the value that we bring to the table, we continue to maintain and develop the Mono core itself. Unlike our products, Mono continues to be open source, and we'll continue to make all our improvements to Mono open source. We also consumed MonoDevelop, and we continue to contribute and maintain and push MonoDevelop forward.
But none of these projects are really entirely done by us. A larger community of developers improved this. So there's kind of a larger community of people working on different components. Mono, MonoDevelop, and MonoMac, all three of those are parts of a commercial offering, so we actively maintain those three. So now, as for Moonlight, it's a little bit of a Linux desktop thing, so development on this continues as communities send those patches or we improve the Mono runtime, but we're not right now focused on the Linux desktop. We're focused on the mobile space, and that's where all our energies are.
NF: I was just going to say the reason is that mobile space is the giant space for software. I mean, 1.6 billion mobile phones shipped in 2010, and the rate of growth of mobile shipments is unbelievable. We're moving to a world where most of the software that users actually see will be running on mobile devices, and significant new client software will be written on the mobile device first. But a lot of the focus has really been on the end-user experience and on designing a great system for OEM. No one has really said we're going to sit down and build an incredible mobile platform for developers. The developer experience in the leading smartphone environment today is just not stellar, and that's where we're excited. We are really passionate about developers. We want the developers to have the best tools possible.
CF: I would argue that developing for Windows Phone 7 is about as stellar as it gets. However, it is Windows Phone 7, and it doesn't have the market share.
NF: Well, I would agree with you. It's a great platform, but if you want to build an app that can reach 1.6 billion a year, you're going to need to support more than that.
NF: And what's great about our product is it allows you to use .NET -- the language you know, the skills you've developed, the code you've already written -- to run apps and to build apps on iOS, on Android. You can use the same Windows Phone app you've already written and port it very easily to the platforms, and it takes full advantage of the native capabilities of those platforms.
RC: I wonder if Moonlight couldn't be a key to that as well, the same way that Microsoft dragged Silverlight onto the phone. If you guys implemented Moonlight against Android and iOS, then we actually have a common development environment for all three.
MD: Well, yeah. I agree. But the one thing you have to keep in mind is that we have to keep reminding this to our users: These devices are . . . they're fabulous devices, though they have memory constraints and CPU constraints, and there are people still deploying stuff to iPhone 1. These things do not have that much memory, and they're very under-powered devices, and we need to keep reminding our users about these limitations. I mean, we had a guy saying, "I'm trying to download 500 megs of data over a WCF service, and I run out of memory." You have to point them to the fact that these devices don't have half a gig of memory. We don't want to use XML to send data and keep it in memory and then apply mixes of de-transformation and return that.
Instead, what we've done is, and again we're going to be in a position where we crack Microsoft, and I think that right now we're in a much better position. Let me tell you what it is. I think that Mono really shines with its own developer stack. So instead of following Win Forms or following Moonlight, what we're doing now is giving you native APIs to iOS's fabulous and amazing Cocoa Touch. So everything that you can use for Cocoa Touch you can use for C#.
MD: We're doing the same thing with Android. Everything you can consume from Android APIs, we can give you. If we tried to wrap this around Silverlight we would end up with an abstraction layer; we would end up with extra code that you run. I think you would end up in a position where your app would be at a little bit of a disadvantage versus other native apps.
CF: And you've been through this with Windows Forms, so you know.
MD: Yeah, we've been through that, and I don't think it's impossible. I just think that the opportunity right now is incredibly hot, and we want to make sure that people use .NET even if it's not the UI pieces. We think we can make a lot of people happier by bringing them garbage collections, lambda [expressions], asynchronous method, the fabulous XML libraries and Web Services libraries, REST libraries, and so on that they could use with .NET, and it doesn't necessarily have to be tied to using Silverlight. So that's where we are right now.
RC: You know you're walking a narrow line here, Miguel, because you're introducing an abstraction to simplify programming and at the same time saying we don't want to introduce so many abstractions to simplify programming.
NF: It's not an abstraction. It's more powerful; it's a more powerful platform. You get strong typing, you get garbage collection. You get a real environment. Objective-C is really foreign to a lot of programmers.
NF: And you've got millions of .NET developers out there who wanted to get started writing mobile apps, and they can do that with our tools. So it's more than that, it's familiarity. We actually think the blended approach is good. What people really want is something that runs great everywhere. Whatever back-end network protocols or synchronization or whatever they're doing, they can share all that code, and then they can write a truly native user interface that feels like, you know, it feels like a world-class iOS app when you're running it on your iPad, and then when you get it on your Honeycomb tablet, it works great there, too, as opposed to something that just looks alien everywhere. So we think that's really a big advantage.
There's much more! You can find the full interview at dotnetrocks.com/default.aspx?showNum=693.
Richard Campbell and Carl Franklin (both Microsoft Regional Directors) are the voices and brains behind .NET Rocks! (www.dotnetrocks.com). They interview experts to bring you insights into .NET technology and the state of software development. They're more than dry technical interviewers -- they have fun!