Archive for July, 2009

The technical argument against Mono in Debian

Thursday, July 2nd, 2009

Richard Stallman, and others, have explained rather well important legal and social reasons for why clearly Mono should not become a default part of a Debian GNU/Linux install, or similarly used for core applications of the GNOME desktop. This is especially true I think in regard to the Debian social contract which is meant to assure that core packages are built from and use free (as in freedom) software, that is without encumbrances or surprises. The ECMA process allows for patent surprises even in the core language specification itself, which can be patent licensed under RAND terms. I happen to believe there are additional valid technical reasons for not including Mono as a core part Debian.

While some may be surprised I should speak so strongly on this topic, given my involvement with Debian and Ubuntu, I found it an ethical requirement to speak out about this, and especially given my past involvement in dotgnu, I have come to feel that the community is being deliberately mislead by some about the what I think the role of Mono probably should have been. While I can see why Mono can be an important tool for promoting and enabling cross-platform development, a role that has been neglected, I believe in fact for this very reason Mono applications should NOT be used to build core required applications or be part of the default install of a distribution, just as for example Java applications are not used to build default core Solaris specific applications for Solaris, or (shutter) Visual Basic was used to build default applications shipped with Microsoft Windows (I am assuming they never did that…).

Hence, I do not see Mono as particularly useful for developing GNU/Linux specific free software applications, but rather in better enabling legacy proprietary ISV’s to build cross-platform add-on/value add applications and migrate to the free world. In this role, there would then be pressure from these ISV’s, many of whom may participate in Microsoft development, to keep Mono/.NET honest and truly cross-platform compatible. When we use Mono to build core GNOME applications, such as Tomboy, Banshee, and Beagle, we remove this pressure, and encourage what should be a cross-platform technology to be used as a single platform one, making it easier for Mono and platform specific GNU/Linux free software written with it to be more effectively ghetto’d by Microsoft. The greater there is this dependency on Mono for core parts of the GNU/Linux platform, the greater the vulnerability to those risks Stallman outlines.

Furthermore, if only a few “core” applications require it, and there are alternative applications that do not, why drag a 40 or 50 meg dependency onto everyone? Mono dependency might well be enough to be the difference between a single live CD distribution or one that requires DVD media to fit. While Microsoft’s proprietary legacy platform is tied principally to Moore’s Law and desktop computing, GNU/Linux is not. GNU/Linux is a free software platform for current and next generation hardware such as smartbooks, and is platform agnostic. Just getting Mono to sorta run on ARM has been a major distraction that should not have been necessary in the first place.

I also think an important goal of a default core distribution should be a GNU/Linux experience that is both GNU/Linux specific (unique) and works well for users. If, as we see in tomboy vs gnote, or tracker vs beagle, there is such a large discrepancy in performance and resulting user experience, then I think clearly Mono is the wrong choice to make even for purely technical reasons alone.

Part of that user experience is a consistent packaging and operation within the rest of a GNU/Linux system. In this respect, I have read the Debian packaging policy for Mono applications, and it highlights the fact that fitting Mono on a Debian GNU/Linux system is actually more awkward than packaging Java for Debian. Essentially, it suggests one creates a /usr/lib/progrname directory, and fill it both with the applications libraries and executables, and then write a wrapper script for /usr/bin. This is because Mono carries certain policies and expectations one finds on Microsoft Windows, where applications and dependent libraries were often bundled together under a private directory because binaries were never shared between vendors. This wasteful inefficiency and inability to cooperate that is the hallmark of proprietary software practices creates to me a very unnatural packaging policy requirement for Debian.

I know of course this viewpoint is at odds also with at least some others that are involved in Debian and Ubuntu, but it represents what I do think and feel is the best course of action. I personally do not fear nor dis-favor Mono, I simply do not personally believe it belongs in a core or default install of Debian or Ubuntu GNU/Linux distribution, and should not be used to build critical or default applications for GNOME. Other use cases individual developers must separately consider, however putting free software platforms at risk of Microsoft extortion simply because certain individuals and Novell made a large investment in Mono is to me a very selfish motivation.

Of course at the time Mono first appeared, Java was not licensed as free software and there was uncertainly around it. That being said, I do of course feel more comfortable with the present licensing situation of Java than with that of Mono. However, I would not suggest, even on purely technical merits, writing core parts of GNOME in Java or requiring Java as a core part of any GNU/Linux distribution, just as strongly, and for many of the same reasons as I would not with respect to Mono either.

Finally, I recognize a lot of excellent work has been put in making Mono a viable technology, and I believe this work has it’s best chance to endure with it being far more clearly and honestly presented in the role of a cross-platform enablement technology. That also is the best way I see to reduce the risk of potential patent traps by Microsoft.