The Mono Project over at http://www.mono-project.org/ really needs help, mainly with quality control and distribution maintenance.

For a long time, I have been very glad for Mono, always smiling when I see it mentioned in the press such as SD Times articles or in announcements and Internet buzzes like the one about Moonlight, the Silverlight-to-Mono port project. It has always annoyed me when people would dis the Mono project as being nothing but an intellectual tinkering, something or other, because I thrive in .NET and as much as I admire Linux I need a transitional environment before I can embrace it. I have full confidence in the Mono team's ability to write excellent .NET-compatible code that runs on Linux.

But there are some painful quality control issues going on with Mono, and personally I think it just needs one or two people to jump in and help out, if the team is willing to embrace another helping hand. Otherwise, they need to get their own act together.

The biggest issues I believe are with GTK# and with the Mono-Develop IDE. While the Mono team would likely argue that an IDE does not make up a programming SDK like .NET, one must appreciate the fact that in the Windows world, .NET and Visual Studio are like peanut butter and jelly--they can be eaten on bread alone but the experience is incomplete unless they are together.

I have no problem with Mono or MonoDevelop being incomplete. My issue is with the broken installation process. The whole idea of .NET on the Microsoft front was to eliminate "DLL hell" by allowing folks to both install multiple versions of DLL side-by-side and GAC them, as well as to enable and even encourage software developers to distribute non-GAC'd distributions of libraries that can execute revised functionality for objects being called by an application that expects an older version.

The MonoDevelop solution, or at least the one that is disributed by the Fedora project's Extras repository (yum install monodevelop), installs all of the dependencies, but with incompatible versions of GTK# (et al). So when you fire up MonoDevelop, in addition to getting an error about MonoQuery.addin (not sure what that one's about), if you start a new GTK# project, despite GTKSharp clearly showing up in the References, you get a compile error saying that the Gtk namespace cannot be found.

I have installed Fedora at least five times in the last week or two, in VMWare, trying different yum / rpm installation sequences, trying to figure out where I went wrong. I have reached the conclusion that I wasn't going wrong--the MonoDevelop and/or Mono teams are the ones who did wrong.

One might argue that it's Fedora's problem since they were doing the distro. Wrong again; the Mono project's web site's download links are distribution-targeted, such as for SuSE and Fedora, but the Fedora links are for Fedora 5 (that's TWO major releases old), and are strongly versioned for Fedora 5 when installed. When I use the noarch installer, at the end of installation you get an error message, "it appears that some graphics applications might not run correctly, please install those libraries individually", and MonoDevelop still doesn't "automagically" fix itself.

GAC is overrated. Backward compatibility support for future-versioned libraries inherent in the CLR is as key to Mono's success as side-by-side version installations. This is a fundamental problem with using RPM technology with Mono. You cannot install an older version of GTK# when a newer version is already installed. You can do a force install, but at what cost? What breaks?

I'm still trying to get this stupid thing going. But be sure, I would rather drop Mono than drop Fedora 7 for Fedora 5 or for SuSE (which I also have installed on a VM, and I'm unimpressed with it).