At Microsoft BUILD earlier this month I arrived early to hear Anders Hejlsberg talk about the future of C#, and found myself next to Miguel de Icaza, co-creator of the GNOME desktop and of Mono, the open source implementation of Microsoft .NET. I took the opportunity to ask a few questions, which I have his permission to post.
I recall that when .NET was first announced in 2000, it was not long before de Icaza announced Mono. I was interested therefore to know his reaction to Windows 8 and the new Window Runtime which powers “Metro-style” apps. Will we get an open source implementation of Metro-style on Linux?
I don’t think so. To be honest, with Linux on the desktop, the benefits of open source have really played against Linux on the desktop in that we keep breaking things. It is not only incompatibilities between Red Hat, Unbuntu, Suse, but even between the same distribution. Ubuntu from this week is incompatible with the one nine months ago. And then there are multiple editions, the KDE version, the Gnome edition, the one that is the new launching system.
When you count how many great desktop apps there are on Linux, you can probably name 10. You work really hard, you can probably name 20. We’ve managed to piss off developers every step of the way, breaking APIs all the time.
I’m heartbroken, that’s the bottom line.
What about compiling your Metro app for iOS or Android?
I think that Linux has a tough time on the desktop. And the desktop is starting to not matter any more. On the other hand, building WinRT is going to be a significant amount of work. A large chunk probably could be reused from Moonlight. But it is a lot of work, to be able to reuse existing Windows apps, and in the case of iOS they already have their own stack, and Mac has its own, Cocoa is really nice and we have .NET bindings for it.
So I think we’ll learn interesting lessons from Metro. There is stuff that will be useful on other platforms like the JSON reader. But I’m not going to spend any time on WinRT for other systems.
And we can speculate about how well Metro will work in the market …
They are Microsoft, it’s going to succeed. In three years they are going to have this thing on half a billion computers, so it will be out there.
It seems like they are going to use their muscle for two things. It’s going to be a tempting space [for developers], but if you want to go into the right distribution channel for that half a billion computers, you need to abide by the Metro guidelines. They are not going to give you full API access, they are going to give you the sandboxed version. Which is good, because it can finally fix the security problems on Windows. They are going to use their muscle to reset the rules for Windows.
Especially on ARM
Right, and it is needed, they definitely need to fix this mess, a lot of malware, spyware, and the fact that everybody is sysadmin, and has to reinstall their machine every so often.
I’ve heard the word “safe” a number of times.
Right, and think of an iPad, you don’t need to be a sysadmin.
Now, you could argue that by WPF not being available to everybody and being bound to .NET they limited the effect WPF would have had, whereas Metro gives this to C++ developers, but they’re saying, hey, you can’t call Win32, there is all the Win32 stuff you can’t call. You have to use Metro. So they might be repeating that [mistake], but maybe it’s eclipsed by the fact that there’s going to be a rush to the app store. It seems like there is a big enough carrot now.
How are you getting on with the Windows 8 tablet?
I have to say, I actually like Windows 8. I am not a Windows user. It’s probably the first time that I would use a Windows machine.
Miguel de Icaza is now at Xamarin, providing cross-platform tools for using C# and .NET to build apps for Apple iOS and Google Android.
- Miguel de Icaza on eight years of Mono, its future, and the Silverlight desktop
- Miguel de Icaza on ODF vs OOXML
- Windows on ARM: Microsoft can write Desktop apps, but you cannot
- What’s in Windows 8 client for desktop users who do not need Metro?
- Using Windows Runtime (WinRT) APIs from desktop applications