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.

Advertisements

7 thoughts on “Xamarin, Mono, and a not so modest proposal

  1. Roman

    Spot on about why I use JavaScript, and also what I think about it!

    Unfortunately, *lots* of people quite literally love JavaScript and hate compiled languages. To each their own, I guess…

    I think I effing hate when my event handler does nothing (due to a syntax error) exactly as much as those people effing hate being told where they screwed up before they even get to see anything run!

    Reply
    1. sleepydaddysoftware Post author

      People who love JavaScript don’t love JavaScript. Not really. What they love is fast compilation (javascript IS a compiled language – it’s just compiled really fast by the browser), and they love structural typing (as opposed to nominal typing). Those things tend to correlate strongly with runtime typed languages like JavaScript, but you don’t need runtime typing to have those things.

      You can, for instance, implement an “interpreter” for every compiled language. Some even do have this – I remember reading of a C# scripting tool a while back, that did exactly this. You can also implement a “compiler” for every interpreted language, like JavaScript. Programming language and compiler-vs-interpreter are two completely separate things that have no causal relationship with each other – just a strong correlation caused by implementation bias. Of course, some languages like C++ would make terrible interpreted languages, but that’s only because the language’s grammar makes fast compilation nearly impossible. Also, a good incremental compiler and a build-tool that watches for changes to source files and rebuilds automatically for you in the background tends to be fast enough for me 90% of the time. Maybe I’m more patient than most?

      As for structural typing, that deserves its own post, but to summarize: structural typing is something most dynamic languages have, but very few statically typed/compiled languages have. It is in truth the primary cause of any actual productivity gains with dynamic languages, either real or imaginary. Structural typing is a good thing most of the time. It trades off either runtime performance or complexity (all dynamic languages, or statically typed languages that use runtime reflection to implement structural typing) OR compiled code size (C++ templates, which sometimes generate multiple copies of code for different concrete type arguments) for productivity gains, but tends to be a good tradeoff on the productivity side. Structural typing is however completely independent of the runtime/static type checking debate. You can have statically typed and/or compiled languages with structural typing (typescript, go, C++ templates). In reality though, most people don’t even use JavaScript’s type system in a structural way – instead most really just need strong global type inference (strong global type inference in combination with structural typing would be very powerful indeed).

      All of that aside, even if one were to admit that there’s a place for interpreted dynamically typed languages (I’m willing to admit this – though I personally wouldn’t ever use them by choice), then you’d still have to admit that even among interpreted dynamically typed languages, JavaScript is just about the worst designed language AND runtime in that category (excluding languages designed to be stupid – you know the one), and even more-so if you factor in how much it is actually used.

      Reply
    1. sleepydaddysoftware Post author

      I have. They disagree, to say the least. I would be open to the idea that the revenue supports development on mono, which on non-locked down should still be usable for free. Except their strict interpretation of the LGPL with regards to app stores puts into question under what possible terms any software could use mono under their interpretation. Apparently they disagree with the free software foundation, Apple, Mozilla, and Google about what constitutes compliance with the LGPL.

      If that’s their interpretation of the license, they are quite clearly wrong. However, I’ve been advised that their stated interpretation of the LGPL could, in a court case, represent a de facto “modified license” – in other words Mono isn’t LGPL, it’s LGPL with their stated custom extra restrictions such as no use on app stores, no including it in the installer, no downloading and installing it separately, etc… So no, I can’t trust Xamarin not come knocking on my door so to speak if I try to actually make money with a mono application without a commercial license, even if technically the app complies with the LGPL. Even if the app is open source.

      After reading how they interpret the LGPL, I very much lost a lot of respect for the company. I don’t think they’re being truly honest about Mono being LGPL, and I think they are openly hostile to open source development with Mono.

      Reply
  2. Joe

    A very nice read. I can’t say I disagree with any of it. Here’s my thoughts:

    The Xamarin products are quite nice, and yes worth it in the long run. The company seems great, and in it for the long run. That said, I am highly concerned with their LGPL interpretation.

    Your JavaScript paragraph was right on the mark. I loathe it with a passion, yet understand that it does run practically everywhere. That’s why if I ever have to do something with JS that takes more than a few dozen lines, I go straight for the Saltarelle compiler. Which leads into a proposed solution…

    Though C# and .NET are seen by a lot of people as tightly coupled, both technically and legally, it’s actually nicely separated on both fronts. We need some entity to take the BCL, and setup a retargetable base so that it can compile with Saltarelle, Vala, and Stab/Cn. Mono will become the upstream, and we’ll have huge swaths of C# code available to everyone. Granted, things like reflection might be… interesting… but that will be a small task compared to what will instantly become available.

    Reply
  3. ivo@nevron.com

    I think Xamarin should be funded by the corporations that want .NET to run on their OSs, The .NET framework should be free on all OSs and Apple and Google should pay a buck or two to ease the lives of the poor creatures that are forced to deal with their APIs in C++ or the even worse – Objective C,

    In this way .NET development will become mainstream, There are no doubts that C# is the best language as of today. JavaScript is… well you said it – donkey poo – and I have written tons of it. So we all want to code on C# and deploy everywhere – but the cost for that is very different.

    You omitted to say that .NET currently lacks a single presentation layer, which JavaScript actually has in the face of HTML. This is actually the huge PLUS for JavaScript – it is not the cost for developing with .NET alone. Making everything that HTML does for you out-of-the-box on all ,NET based environments is a REALLY HUGE task.

    We at Nevron (https://www.nevron.com/products-open-vision.aspx) started to do this more than 5 years ago with a relatively large team of developers and to be honest it was quite complex to implement all the browser-like details in C#. You simply can’t image – imaging, typography, DOM, PDF, CSS, graphics – all in pure C#.

    So C# developers will have their HTML equivalent on all platforms (be it developed by us or another company) and JavaScript developers will no longer have that huge advantage on their side. If the .NET framework is free on each OS – then I guess we will live in a better world.

    Reply
    1. sleepydaddysoftware Post author

      Yeah, a lot of open source projects are “funded” by way of companies spending resources (salary) on employees that make contributions to the library. The problem with Mono is that all contributions must assign copyright to be accepted by Xamarin and then those companies that would contribute must then still pay licensing for their own work. Copyright assignment clauses and the LGPL actively discourage contributions from other commercial entities, which is the source of the majority of open source contributions to begin with. Xamarin, here, is capitalizing on the difficulty and rarity of virtual machine implementations, especially bytecode VMs. There simply aren’t enough programmers in the world with expertise on bytecode vm implementations. I think this is a mistake though, because companies like those behind the spring framework, or node, are doing significantly better business than Xamarin despite having a permissive license.

      Thanks for your reply. Cheers!

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s