michaeldehaan.net

Before everyone on Fedora Planet gets their love on for Microsoft and Mono (perhaps the worst named project ever?), they should remember that Microsoft still does not have Windows Forms or ADO open, nor their admittedly shiny development tools, and any serious .NET deployment is going to be wanting to use the full enterprise stack. Shiny sells. The .NET stuff looks good in a demo.

What’s the danger?

Half-open or quasi-legal software still serves us horribly as a movement and as a tool, and lending creedence to it is a slippery slope. It is the problem of the Community Edition, the jokingly referred to “Children’s Edition”, the idea that a codebase (or in this case, only part of a set of specifications) can exist, but the “good” bits are held back, because Open Source is not suitable to producing them. This is a dangerous and corrupting belief system to allow to exist. This is worse, actually, because there isn’t even a codebase — just a hint of a specification. By mere virtue of the fact that Microsoft can afford to fund /lots/ more developers on such a project, it’s pretty easy to make a business case for their implementations to be superior — even if that’s not actually at technical factor and not actually true (though, in many cases, it could be). And that’s the dark secret right? The technical factors don’t matter. All sorts of FUD can be raised around quality of implementation, lack of solid support, missing future features, or even, yes, legal questions that probably will never occur. These are things that you open the door to when you say “this is ok”.

The belief, I’m sure, is that folks may start out with Mono deployments, realize how much more is available on the .NET platform (or that the tools look more seductive, or be pressured by customers with Windows deployments, etc, etc), and move to it. Perhaps your project is a little slow, maybe the database layer is a few weeks behind, maybe you had a stupid bug. Regardless of the actual reason, you’ve opened a door.

If I was a business guy and my people were doing Mono development, and struggling with their database layers or trying to put together a GUI for customers, where do you think I’d suggest they go? Hint: you don’t want them playing with the kiddie version. You buy into the Microsoft Development tools. And Windows. You want something supported and fully feature rich. Do you think you are likely to find an employee trained in .NET or trained in Mono? Which job experience will the usual C# developer want? This is also an apparent business problem, and is another sign of why this is a slippery slope.

All of this can happen /without/ any action on Microsoft’s behalf. If you were to, instead, say, choose Java (and I’m /not/ a Java fan), you simply don’t have this business problem. You can make a perfectly valid case that you are working with the full suite of tools all the time and that you have the freedom to replace components with other enterprise supported components when you need to. Your Linux OS platform will never be labelled second class. This is also true of most every other tool we have in our software development arsenal — actual Open Source software, that is.

I’ve seen something like this happen before at a previous company — and mono often stands no chance for serious consideration if there’s also a slim chance that Windows stands a chance of serious consideration. Injecting mono into your work projects is an open door into having to replace your OS with Windows a little further down the road because you are vested in the codebase and the codebase needs .NET (even if it doesn’t). If you are ok with that, go ahead. If you are writing simple non-profit desktop apps, go ahead. But know what you are promoting is a double-edged sword (what halfway decent sword isn’t, really? Perhaps I mean it’s a triple-edged sword.) And even adding a few more Mono apps helps percipitate that belief.

If Microsoft were actually selling development tools for Linux and working on Linux implementations, this would be different. The risk wouldn’t be there.
The world is really driven by enterprise software, and without ADO, and without development tools, mono remains analogous to those half-open projects we all dislike, knowing full well that they do /not/ get it. Every application that claims to be open and holds something back, not being open, is saying “this model doesn’t work, hint, hint, you should be using proprietary bits”. Here is the case with the data access bits, with the development tools, with the quasi-open stack.

Perhaps Microsoft really means well, and there’s a saying that if you always act like a good person you become one, even though it is eventually hypocritical. Perhaps that’s true here, or perhaps they are really being good… however… it’s not good. It’s especially not good for the platform.

And really, are you that enamored with C# to not find something better? It’s not /that/ great of a language, folks. It may be Java without a few warts, but it’s still not uber-productive or anything. Even cross-platform fat clients on Windows can be made to work remarkably well even in something as simple as Python. C# is not the only option for cross-platform Windows applications, and if you are doing pure-Linux apps, there’s not even the appearance of that need for mono.

Watch out for the triple edged sword before you start wanting to use more mono/C#. It cuts three ways.

If you are using it thinking it is open enough (and it may be), you may not get to keep your application stack that way over the long haul.

My long held theory is that mono was never to be considered a legal threat, it is a tool to be used in a strategy of erosion … insert a compelling technology, then provide a migration path by adding on proprietary extensions. It erodes Linux and it erodes OSS… and advocacy for it, even in purely legal/ethical ways, using just the free bits, and so forth, help enhance that position and acceptability.

OSS gets blamed for being a religion. That may not be completely fair, but there /is/ a Golden Path that must be followed to a better software tomorrow. In this way there are tennets to follow that are not always purely technical, because there /is/ a cause and a goal in mind. One of those tenets is making sure we advance things that promote true and complete openness, and that we look at half-closed software as more dangerous than proprietary software. Proprietary software can be defeated on technical merits, half-open things slowly erode our very definition and purpose and threaten what we hope to accomplish.

If you thought it was just about code or the tech and the law, it’s not. The code is a side effect.