In which we convince ourselves that it is time to use Mono in anger.
I've always been a Mono fan from the early days. Sadly, my career as a Mono developer never amounted to much - not even a committed patch - but I remained a loyal lurker and supporter. It's not so much because I thought it was going to change the face of Free Software, but because I wondered if it would allow Linux to gain a foothold in Windows-only companies. Having been working for this lot for such a long time, I desperately yearned for a bit of serious Linux interaction in my professional life, so I kept on playing around with Mono technology to evaluate progress. For instance, a few years back I wrote Adventures in F# Land Part 1, Part 2 and Part 3, based on my experiences in setting up F# in Mono1. I continually did this kind of mini-experiments, mucking around with tiny programs to query the state of the world. But what I really wanted to do was to test the whole infrastructure in anger2.
As you can imagine, I was extremely excited when I read Miguel's tweet:
Microsoft has open sourced the new generation of http://ASP.NET http://github.com/aspnet
Another blog post had more details: ASP.NET vNext. Microsoft was to start testing code against Mono, at least for ASP.Net. To me this was nothing short of revolutionary. Not to the average Linux developer, of course - barely a yawn from that camp. But to the average .Net developer this is - or should be - earth shattering news. When you couple this with the .Net Foundation announcements, it signals that Microsoft now gives the official blessing for developers to start thinking of .Net as cross-platform.
It may surprise you, but the average .Net developer does not spend days and nights awake, worrying about how to carefully design their architecture to maximise cross-platform code. They do not have Mono on their CIs. They tend not to care - or even be aware of - all the latest and greatest features that the Linux kernel sports, or how cool Docker, Chef and Puppet are. Those that are aware of this are in a minority, and most likely have been exposed to the other side via the Javascript infiltration that is now taking place. A fairly recent comment in a Castle issue should give you a flavour of this thinking:
I don't think anyone is actively pursuing Mono support at the moment. Reality with Mono historically has been that no one cared enough to properly bring it to parity with .NET and keep it that way.
Having said that, we're more than happy to improve our Mono support (…)
For those not in the know, Castle is an Open Source project that provides an IoC (Inversion of Control) container. It is really popular in .Net circles. As we shall see later, Castle actually works really well with recent versions of Mono - but the fact that the Castle team didn't have a CI with Mono is indicative of the state of the world in Windows .Net.
This is not to say that Linux is not on the Windows developer's radars - quite the opposite, and the progression has been nothing short of amazing. During my working life I've spent around 70% of my time working for Windows shops; to be honest, I still find it surprising when look at the past and compare it to the present. Things went from "Linux, what's that?" to "Linux is a nerd's toy, it will never make it" to "That's for Java guys" and finally, to "We run things on Linux where it is good at, but not everything". Things being Java and Coherence, Grid Engines, Javascript stacks and so on - no mention of .Net.
In fact, the .Net revolution hampered the Linux strategy a lot. Java was a good Trojan horse to force developers to think cross-platform, and many a Windows shop turned to Linux because of Java. However, once you had a competitive (read "enterprise-ready") .Net framework, Java receded in Windows people's minds and it was back to business as usual. Even a strong and capable Mono was not enough; a lot of the .Net code was so incredibly intermingled with Windows-only code that portability was impossible without great effort. Many a hero tried and failed to compile massive code bases on Linux.
Things started to change over the last five years. Three separate trends unified. First was the new focus on SOA. Windows developers finally found out what the UNIX geeks knew all along: that services are the way forward. And because their view of SOA was closely linked to REST and Web development, suddenly the code bases became a lot less Windows dependent and a lot more self-contained; no more WPF, no more third-party closed-source controls. The second important development was that Windows developers found Free and Open Source Software. A lot of the libraries they rely on are open source, and thus much more Mono friendly. The final trend was the rise and rise of Javascript and Linux-only tools. Every other Windows developer is now familiar with Node.js, Mongo, Redis et al, and have at least rudimentary knowledge of Linux because of it.
However, the Linux developer on a Windows-land is still stuck, and all because of a tiny little detail: IIS and ASP.Net are still a pain in the backside. Mono has provided ASP.Net support for a while now, but to be honest, the applications I've seen in the wild always seem to use some features that are either not yet supported or not supported very well. There is just so much coupling that happens when you pull in IIS that is hard to describe, and a lot of it happens without people realising - it's that lack of cross-platform mentality all over again. So for me the one last little piece of the puzzle was IIS and ASP.Net. This was anchoring the entire edifice to Windows.
Now you can see why having a fully open source ASP.Net stack is important; especially one that does not depend on IIS directly, but uses OWIN for separation of concerns and is tested on Mono by Microsoft. Code bases designed on this stack may be able to compile on Mono without any changes - or, more likely, with a few small changes - opening the floodgates for Linux and OSX .Net development. Of course, don't let me get too carried away here. There is still much, much to be done for a totally cross-platform environment: Powershell, KPM, etc. But this is a very large step in the right direction, and it covers a large amount of use cases.
A final point is worth making about the corporate ecosystem that evolved around Mono. This is not really a marketing ploy, although I do wish them all the best. Companies such as Xamarin, Unity and projects such as MonoGame are instrumental in the progress of Mono. By creating funded start-ups around Mono, with products that are used by a large number of developers, they engineered a dramatic increase of quality in the entire ecosystem. And in turn this raised its visibility, bringing more developers on board, in the usual virtuous circle of open source.
So for all these reasons and more, it seemed like Mono deserved another good look. As it happened, I was trying to develop a fairly large test tool for work in my copious free time. Since I needed to code from home, I thought this would be the right project to give it a far old whack. And you, dear reader, will get to know all about it in this series of posts.
Footnotes:
1 Mind you, all of it is to be ignored as its now trivial to setup F#.
2 For the non-British speakers out there, using something in anger just means "to give it a good go" or "to really push it" rather than writing a hello world.
1 comment:
Very good analysis. I also should point out, as you did, that Java was pivotal in moving from an enterprise software model to an open, modern web model.
The number of frameworks that has grown around the web is nothing short of astonishing. Yet, all these frameworks seem to converge to greater attention being given to cross-platform instead of less. "Platform-specific" has almost become sort of a curse word, an uncomfortable "someone will handle this" footnote in world-domination plans.
Java's cross platform seed ideas, in one way or another, are present in the fabric of the web. And the web has found ways to go around the limitations of Java (and its tendency to be the One Hammer to Rule Them All). Some ways are good, some are bad, as everything.
MS, on the other hand, should really think about the benefits of running in Linux. The types of benefits that spring from that are orders of magnitude more important than say, "deciding to use another Javascript framework for your product". These are huge low-level gains here, and they should be taken by someone who can.
Post a Comment