Tag Archives: Android

Xamarin, Mono, and a not so modest proposal

First things first

Xamarin is an awesome company, and all of it’s Xamarin Studio products are worth the price they charge for them. And Xamarin uses that revenue to constantly pour a ridiculous amount of magic rainbow unicorn dust into their products. The new MonoDevelop redesign for Xamarin Studio 2.0, for instance, is so good that I am actually starting to prefer it to Visual Studio. “Nonsense!” you say, but believe it. It’s that good. Watch the Xamarin Evolve 2013 keynote. Get excited. I really have no bones to pick with the awesome team at Xamarin.

JavaScript is donkey poo

.NET also happens to be the ONLY realistic, production ready competitor to JavaScript in terms of sheer client platform reach. That’s important, because JavaScript is a pile of Donkey poo covered in malaria-infested horse flies, and NO SANE PROGRAMMER WRITES CODE IN IT BECAUSE IT’S THE BEST TOOL FOR THE JOB! They write JavaScript code because it’s the only tool for the job of producing a product with reach across all of today’s client platforms. JavaScript sucks, HARD. But it’s absolutely free, and it runs on anything worth running on. And so you will never have a difficult time finding components, libraries, books, programmers to hire, etc…

But here’s the problem

So, JavaScript sucks, Mono/.NET is awesome and works everywhere JS does. “Just buy a Xamarin Studio license and be happy! What’s the problem?” you might ask. It’s this. While I don’t necessarily disagree with Xamarin’s business model from a philosophical viewpoint, I can’t help but notice a serious flaw. And it’s a flaw on multiple fronts. Mono isn’t just a middleware product, like some set of charting controls or a graphics engine. Mono, or more accurately the .net stack, represents an ecosystem. It is an enabling technology that can drive innovation from many individuals and business. Like any platform, good or bad, you must rely on the ecosystem for components, libraries, community documentation, books, etc… to get any work done. The ecosystem is critically important. Without it, you can’t really use the platform no matter how good it is.

Pay walls are still walls

The problem is, .NET can only be considered ubiquitous if you count mono’s implementation. And the sad fact is that you can’t count Mono, because for all CLIENT platforms that actually matter in 2013 and beyond, mono is locked behind a pay wall, and JavaScript is not. And that fact alone will, at best, limit its use to a niche middleware product. At worst, it will result in a cascading collapse of the entire .net ecosystem for client-side development.

Whoa, surely not?

That’s an extraordinary claim. So, I’m going to try to back it up with some facts. First of all, if you are involved in enterprise development, or really any development at all in the last five years, you may have noticed a growing trend. That trend is that the decision makers at enterprise companies (and indie devs too), have begun to realize three things. First, that open source projects move at a pace that proprietary, closed-source projects are finding it hard to keep up with. Second, that closed source components are a major liability when it comes to the increasingly short development cycles that are becoming normal. And finally, that the cost-to-benefit ratio of paid, proprietary middleware is no longer adding up, when there are free and adequate alternatives.

It’s all about the CultureInfo.CurrentCulture.NumberInfo.CurrencySymbol’s

What this means is that major enterprise development firms, and indie devs alike are both fast moving away from expensive proprietary vendor lock-in towards free and open alternatives, even when they’re not quite as good. That’s a problem for Xamarin. While a company may be perfectly willing to pay for services that immediately saves them a ton of time and money but don’t lock them into a particular vendor, like Xamarin’s new cloud testing services, they are increasingly wary of expensive vendor lock-in (and the vendor longevity risks that come along with it) when it comes to platforms and critical libraries on which to build their own products. Even industry mainstays, like Microsoft’s own commercial .NET implementation, are being looked at with a wary eye as companies move more and more to free but only-just-good-enough alternatives like java, javascript, or ruby.

The LGPL is a broken license

I’m probably going to get some heat for this claim, but in my opinion the LGPL license is well and truly no longer relevant. The LGPL was meant to allow a developer to use an open source library without making their code also LGPL, while still maintaining some control over the library itself. However, with few exceptions, this is no longer possible on almost any client platform that matters in 2013 and for the foreseeable future. Its original writers may not have imagined a world where all applications were delivered as self-contained bundles with all third party libraries packaged along with the app as read-only binaries, rather than shared between apps or user replaceable. Or maybe they wrote the LGPL to help prevent such a future. Either way, the LGPL no longer serves the purpose it was designed for, and is not usable at all on most of today’s client platforms.

Don’t forget the FOSS

For the LGPL, it’s even worse than just not fulfilling its original purpose. Because on today’s modern client platforms, it is ALSO making it more difficult, if not impossible, to comply with the LGPL even when you are yourself an open source app! Not everyone agrees with the interpretation that an open source app need only supply the source or object files to comply with the LGPL for a packaged, bundled app. And so there is uncertainty that it is even possible to use an LGPL license at all on these platforms. This certainly goes against the intent of the LGPL license.

A not so modest proposal

I’m about to make a proposal that is going to sound crazy. But bear with me, because I think the logic is perfectly sound. I think that Xamarin should re-license the core mono runtime and runtime libraries, which are currently licensed under the LGPL. Instead, the core of mono should be licensed under Apache 2.0.

Wait, come back!

OK, if what I just said sounds like “Xamarin should give away the one thing they sell for free.””, then hear me out. First of all, Xamarin now has a secondary revenue source in its cloud testing platform, which after watching the presentation on it, let me tell you I could sell that to any mobile team in any enterprise firm in a heart-beat. That service is a no-brainer, time and money saving miracle. Secondly, I am not including the android/iOS add-ins or build chain in MonoDevelop or Visual Studio. I think Xamarin should still charge for those, and I think developers will still buy them. In fact, I think MORE developers will buy them (but I’ll get to that in a second).

If you build it (and make it free), they will come (and end up buying more)

One thing the MMORPG and app industry has taught us, is that if you start free, and charge for extras and add-ons, you will inexplicably end up with more revenue than if you start off as paid. I believe the same thing will happen if Mono becomes an Apache 2.0 licensed library and runtime. Having an Apache 2.0 license for the mono runtime will give developers the confidence they need that they are not locking themselves into a single vendor. This could greatly expand the .NET ecosystem beyond what is possible with a strictly paid product. And a more robust and diverse ecosystem is better for everyone, especially Xamarin! In the end, while you may lose a few Xamarin Studio licenses to open source alternatives, I think that in fact this would result in a net gain for Xamarin, because the serious devs will still purchase Xamarin licenses, and there will be more serious devs because the overall ecosystem is that much healthier.