Un Poème Pour les Petites Poules Perdues

The “Mono War” is unproductive.

For some, I’m sure this comes as a startling realization, and for others, it’s stating the obvious. However, the point needs to be reiterated – the “Mono War” as-is serves no practical purpose.

From my diamond-encrusted Microsoft-supplied throne, here is what I see when I survey the “War”:

  • Immovable, entrenched, irreconcilable viewpoints amongst combatants
  • A degree of outright lunacy exhibited by both sides – but (sorry) mostly by some on the “anti” side
  • A willingness to canonize anyone with a matching viewpoint, rather than use of independent thought and research
  • Demands from the “anti” side that they be obeyed
  • Demands from the “pro” side that the “anti” side shut up and go away. With added smugness.
  • No fear of bending, distorting, or even denying reality to support an opinion
  • An embracing of collateral damage as long as the main goal is achieved

It is these points which I consider unproductive. Nobody is going to change their positions based on angry or smug blogging, nobody is going to drop everything to work on things for kids with entitlement complexes, and nobody is going to give up on their freedom to kick up a fuss.

So, here I come to save the day. You’re welcome. I’m going to give the “anti” folks some suggestions on how to wage a productive war, one with results rather than recrimination. I even took the first step myself, although it was hardly well covered in the media. I’ll get to that a little later.

Step 1: Accept that some people feel differently to you

I know this may be hard to stomach, but no matter how much you shout, no matter how many times you point to assorted legal submissions from the 1990s, no matter how many times you cite cases such as TomTom or Buffalo, nobody is going to take your arguments and change their behaviour. Some people simply don’t have the same scale of concern or fear as you. Accept this. Don’t attack people because they don’t see things the way you do, as it’ll only make their resolve stronger. Simply accept that they don’t agree. If it makes you feel better, write them off as stupid in your mind. Not that I ever do this for anyone. *cough*

Step 2: Understand why people do what they do

Not everybody contributes to Free Software for the same reasons – although by and large the biggest motivator is “to make it better for myself”. People package stuff they use themselves – or should damn well do if they expect package quality to be maintained. People write apps for themselves, they submit patches to add features or fix bugs for themselves, and so on. This is not the only motivator, but it’s the primary one. There is no ulterior motive – unless you consider “improving this for my own use” to be ulterior. Yes, that even includes the recent Hyper-V drivers – where it was in Microsoft’s interest (for selling Hyper-V to displace VMWare) to “contribute” according to the rules of Free Software contribution. Imagine, if you will, that people like, say, Banshee because they genuinely prefer it to Rhythmbox – not because they’re secret dark agents of teh Micro$haft trying to “spread Mono”.

Step 3: Understand governance

One of the biggest mistakes made by the “anti-Mono” team is the belief that abuse on forums, blogs, mailing lists and newsgroups is how change happens. I hate to break it to you, guys, but it’s not. Every distribution of Linux is put together by an individual or team, and every distribution has specific processes in place which determine what constitutes a package in the repository, a default package, and so on. Some distributions are dictatorships, some distributions are direct democracies, some are lead by layers of bureaucracy. If you want to fight against something, you need to do it within the system. And some systems make it easier than others to fight.

Here are a couple of examples, to get you going: In Debian, the final decision to include a package in the archive or not is made by the ftpmaster member who audits the package. This audit is re-done every time the package changes the binary .deb files it produces (but not for every upload), and that overall control of what is in the archive remains with them. The decision is made on a simple basis – does the license of this software permit its inclusion and distribution in Debian, under the terms of the Debian Free Software Guidelines. The decision over which packages to depend (or not) in a given metapackage is at the complete sole discretion of that package’s maintainer – so for the GNOME metapackages, that’s the GNOME team. And the decision over which packages to include in the default install image are made by the installer team, heavily influenced by (but not necessarily exactly the same as) the prior decisions of the GNOME team. Packages are solely owned by their maintainers, remember that – meaning the only way to remove Mono (or to reclassify it as non-free or whatever is today’s favourite attack) without cooperation of the package maintainer is… well, there’s a way to do it, but it’s a nuclear option. A Debian Developer (and only a DD, as per the Debian constitution) can call for a General Resolution. It’s detailed in this page right here. But in essence any vote to remove Mono is a vote of no confidence in the abilities of the (thorough and hard-working) ftpmaster team – and a vote that developers should no longer consider their packages to be their own property. Good luck passing any such resolution, especially without mass resignation from the Project. There’s the Debian route. First, contribute enough to be advocated as a Debian Developer, then become one, then file and win a GR to remove Mono. Good luck with that.

Next is Ubuntu. And here, you have an equally tough fight, but for different reasons. Ubuntu has a similar role to ftpmaster, called an Archive Admin – but by and large, Ubuntu trusts decisions made by ftpmaster in Debian. As a result, arguments beyond mere licensing are delegated upwards to a committee type organization called the Technical Board. The TB is the highest law in the land – it’s made up from Canonical employees (including Shuttleworth) and community members – and according to the paperwork, the only extra power Shuttleworth has here is the casting vote in a tie-breaker situation. The TB meets on IRC every couple of weeks or so, and discusses topics raised with them, rendering “final for now” verdicts. The TB have the authority to remove Mono from not only the default install (which would override the Desktop Team’s wishes), but also the entire distribution. However, the TB has already recently reached a near-unanimous verdict that Mono is fine. Sorry, but see step 1 above. If you want to change their minds, then the path is clear – join the TB. They had a nomination period recently (I don’t think any anti-Mono folks signed up), and will be doing so again every now and again. Become a big enough contributor to Ubuntu to make a successful bid to join the Technical Board, and then once on the board, discuss with your peers why you feel Mono should be removed – and win that argument.

Noise on forums is just noise.

Step 4: Understand the relative value of contributions

There are those who have characterised this war as a war between “users” and “developers” – and to an extent that’s true. Everybody is free to make their own decisions regarding their computing experience, and to act upon those decisions. However, the question of who makes that decision affects how far-reaching those decisions are. If a developer makes a decision, that has more wide-reaching results than if a forum poster makes a decision. If a packager decides on something, the effect is wider than if a “mere” user decides something. Those decisions may not be the same as yours (see, again, step 1) but you need to understand that those decisions, those contributions, are far reaching not because of some conspiracy, but because the person doing those things, has been assigned a greater degree of impact by the community at large. If someone is elected to a packager role, then their decisions affect anyone who uses those packages – which may include users, or other packagers, or other developers. If you are not a customer (see step 2) then they will behave however they like, and contribute however they like.

You cannot win a war with a packager with flames. You cannot win a war with a distro team with attacks. If you can’t beat ‘em, join ‘em – and make contributions which outweigh (e.g. render irrelevant) the contributions of those with whom you disagree. Contributions don’t need to just be programming or packaging – many other roles are often overlooked but of vital importance to Free Software’s success, such as artists, translators, documentation writers, and so on. You can contribute in many ways – and whilst your contribution may not directly “hurt” what you don’t like, they can help what you do like – and indirectly win the “battle”.

Step 5: Pick your battles

I have seen it suggested in certain areas that some feel it is their “duty” to try to elicit global change in a single shot – to have their demands met absolutely everywhere at once, and they do so by fighting absolutely everything at once. I’m sorry to tell you this, but the “community” is bigger than you are (and don’t kid yourselves, Mono has a genuine community surrounding it). If you want to elicit change, then focus your efforts. Pick some specific way to contribute which will help your point of view, and only move on when that specific fight is won. Don’t want to see Banshee as a default music player app? Then focus on that – and do so in a positive way. In this case, that means things such as contributing to competing apps like Exaile or Rhythmbox such that they are definitely better and nobody wants Banshee to be the default.

Step 6: Lead by example, not by shouting

If you really, fundamentally feel that your needs are not met by contributing positively, or trying to elicit change via the right governance channels, then  do better. That’s all there is to it. The folks behind, say, Linux Mint felt that their needs were not met (and could not be met for one reason or another) by “real” Ubuntu, so they lead by example and made their own distro. If you really feel your needs are not being met, then you can do the same. Make other apps better, or if push comes to shove, make your own distro. It’s really not hard!

In fact, to illustrate the point, I made one myself. It’s called “Chicken Little Remix” (absolutely not Ubuntu Chicken Little Remix as that would mean worrying about trademark policies), and you can download it from The Pirate Bay in i386 and amd64 formats. As a first cut, it’s simply a Jaunty Alternate ISO with all Mono-related stuff cut away – and it took me an hour to do. Imagine what the combined energies of the entire anti-Mono community could produce, with a little direction. CLR is my attempt to provide some direction – I’m happy to provide advice on how to modify packages and customize the Alternate ISO (something I have experience doing) as long as the name remains in place, but perhaps it could even be treated as a way for people who are “only” users to learn how to become “contributors” too, and make their voices in the greater community louder. Make the distro you wish those idiots in the Technical Board and Desktop Team were producing, and show them how it’s done. Set up a project on Launchpad, a website, make some art, tinker on packages, and make CLR 9.10 the most awesome distribution ever – without need for any of that messy Mono nonsense. The first cut took one person one hour – how much time does that give for the next release? Fill it with Gnote and Solang and AWN and $DEITY knows what else, and demonstrate through tangible contribution how unnecessary Mono really is.

Because when all’s said and done, simply shouting that the sky is falling won’t get you anywhere.

33 Responses to “Un Poème Pour les Petites Poules Perdues”

  1. CLR seems not to be a very adequate name for a Mono-absent distro ;)

    [reply]

  2. I admit I don’t want to rely on MS-tech or encourage its usage, but this was a very cool post. No doubt about that.

    Will every Ubuntu version get a CLR?

    [reply]

    directhex Reply:

    @Tom, That depends on whether a community can be formed around the concept to take up the challenge. I don’t want to keep doing it forever

    [reply]

  3. Great post. Wish I had written it. Really sums up my feelings on the entire issue.

    [reply]

  4. Chicken Little Remix made me chuckle. Thanks.

    [reply]

  5. This post is adding to the noise. Take your own advice and STFU.

    [reply]

    C.J. Adams-Collier Reply:

    Yeah, @Jeremy! STFU!

    [reply]

  6. @Jeremy – this isn’t just noise, he actually produced a mono free distro. Thats a physical tangible outcome.

    [reply]

    C.J. Adams-Collier Reply:

    Enough of your facts, @Daniel. Your a noise-making $hill and you need to hush it.

    [reply]

  7. [...] http://www2.apebox.org/wordpress/rants/163/ [...]

  8. Well said, Jo!

    [reply]

  9. [...] Shields posts a blog entry about the “Mono [...]

  10. Where is the source code for this Chicken Little Remix?

    [reply]

    directhex Reply:

    @foo, on archive.ubuntu.com, other than ubuntu-keyring-2008.03.04~dhx1 which I have right here. Do you want it?

    [reply]

  11. Great post. I have a mild issue with “and a vote that developers should no longer consider their packages to be their own property”, however. Well, it’s true, that would be a vote in that direction, but there’s an increasing slide in that direction anyway, and in general this will probably be a *good* thing.

    [reply]

    directhex Reply:

    @Jon, I don’t necessarily disagree (I bouth only team-maintain packages, and have my eye on a package neglected by its sole maintainer) but I don’t see a thousand DD’s giving up their sovereignty just like that

    [reply]

  12. Great post. If you want something to be done, changed, etc do it. Show me the code, not talk the talk.

    That’s what drove open source to where it is today.

    [reply]

  13. >> I’m going to give the “anti” folks some suggestions <<

    I could at this point claim that your being a smug bastard just with that one line, that's certainly how you came across. and despite how you claim to feel Jo, you still jumped in with that ridiculous meme, you still have to keep on wading in with your clown shoes into this debate that should be allowed to die so we can get on with actual development.

    This post has the white-wash of balance but none of the actual substance. It's so obvious that you want desperately to outright attack the anti-mono camp, but so long as you can throw in a few 'everyone's in the wrong' no one will mind you adding 'especially the butter side up guys'

    Forgive me if I look else where for a more balanced report.

    [reply]

    directhex Reply:

    @Martin Owens, I would be curious to hear where you decide has a “balanced” viewpoint.

    [reply]

    messy Reply:

    i agree – it feels like some whitewashing, but at the same time, i don’t see how the anti-mono side can say anything against this post – put up or shut up. if balance means weighing 50 pounds of shit against 50 pounds of honest work, i don’t want that balance. great post Jo. Martin Owens – time to put up – what’s your view on the issue? You seem to think there is something else that will make this more balanced – so it stands to suggest that you have something to base that on. otherwise it’s quite literally baseless, isn’t it? Jo gave several very legitimate ways to “attack” mono – yet i guess they just feel a bit too much like work.

    [reply]

  14. Excellent post!

    It’ll be interesting to see how many follow your advice (although I don’t have much hope: flaming and ranting is easy, doing something useful is a whole different thing).

    [reply]

  15. Nice, great, and well-written post !!
    This “mono war” can be productive if the anti-mono people do it in more competitive way, like promoting other technology that they think is better than mono and write (or improve) the software that is based on it.
    Flaming and ranting isn’t bring any good to our community. Its only bring HATE between member of community.

    [reply]

  16. http://video.google.com/videoplay?docid=1274983729713522403

    [reply]

    C.J. Adams-Collier Reply:

    that guy’s nuts. ;)

    [reply]

  17. Thanks for the post. Keep it up leading by example. You said that,

    “…I’m happy to provide advice on how to modify packages and customize the Alternate ISO (something I have experience doing) as long as the name remains in place…”

    How do you do this? I am an Ubuntu user and not a developer or programmer and an enthusiast in making a linux box customized for my own needs. I tried Ubuntu Customization Kit but it can only use the dekstop ISO.

    [reply]

    directhex Reply:

    @jdetras, Sorry, I forgot to reply to this. I’ll try and find the time this weekend.

    [reply]

    directhex Reply:

    @jdetras, Okay, alternate customization 101.

    * Copy the contents of an existing ISO to disk
    * Remove any packages you want to remove, or add new ones in the obvious place in pool
    * Edit the preseed file to add/remove anything that needs to be altered to change the default install (not needed if you add/remove things which are a Recommends: of another package already on the install list)
    * Go to an empty folder, extract the source package for ubuntu-keyring, import it, and re-export it with your own key added. Build the package, replace the CD’s copy with your edited copy
    * Go to http://archive.ubuntu.com/ubuntu/indices/ and download the override files for your release (override.$FOO.main, extra.main, restricted, main.debian-installer and restricted.debian-installer)
    * Create a file called apt.conf someplace with the following contents (fix values as appropriate):

    APT::FTPArchive::Release::Origin "Ubuntu";
    APT::FTPArchive::Release::Label "Ubuntu";
    APT::FTPArchive::Release::Suite "warty";
    APT::FTPArchive::Release::Version "4.10";
    APT::FTPArchive::Release::Codename "warty";
    APT::FTPArchive::Release::Architectures "hppa";
    APT::FTPArchive::Release::Components "main restricted";
    APT::FTPArchive::Release::Description "Ubuntu Warty";

    * Create apt-ftparchive-deb.conf:

    Dir {
       ArchiveDir "/path/to/staging/folder";
    };
    
    TreeDefault {
       Directory "pool/";
    };
    
    BinDirectory "pool/main" {
       Packages "dists/warty/main/binary-hppa/Packages";
       BinOverride "/path/to/override.warty.main";
       ExtraOverride "/path/to/override.warty.extra.main";
    };
    
    BinDirectory "pool/restricted" {
       Packages "dists/warty/restricted/binary-hppa/Packages";
       BinOverride "/path/to/override.warty.restricted";
    };
    
    Default {
       Packages {
          Extensions ".deb";
          Compress ". gzip";
       };
    };
    
    Contents {
       Compress "gzip";
    };

    * And again in apt-ftparchive-udeb.conf:

    Dir {
       ArchiveDir "/path/to/staging/folder";
    };
    
    TreeDefault {
       Directory "pool/";
    };
    
    BinDirectory "pool/main" {
       Packages "dists/warty/main/debian-installer/binary-hppa/Packages";
       BinOverride "/path/to/override.warty.main.debian-installer";
    };
    
    BinDirectory "pool/restricted" {
       Packages "dists/warty/restricted/debian-installer/binary-hppa/Packages";
       BinOverride "/path/to/override.dapper.restricted.debian-installer";
    };
    
    Default {
       Packages {
          Extensions ".deb";
          Compress ". gzip";
       };
    };
    
    Contents {
       Compress "gzip";
    };

    * Inside your staging folder, run:

    apt-ftparchive -c /path/to/apt.conf generate /path/to/apt-ftparchive-deb.conf
    apt-ftparchive -c /path/to/apt.conf generate /path/to/apt-ftparchive-udeb.conf
    apt-ftparchive -c /path/to/apt.conf release dists/warty | tee dists/warty/Release
    gpg --default-key MY_GPG_KEY_ID --output dists/warty/Release.gpg -ba dists/warty/Release
    find . -type f -print0 | xargs -0 md5sum | tee md5sum.txt
    mkisofs -r -V "Chicken Little Remix" -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o /tmp/clr.iso .

    [reply]

  18. Jo- Good one, I get the joke–ROFL–but scanning blogs, it seems that not everyone does. Too bad for them!!

    Your blog post: well thought-out, measured in tone. CLR: a master stroke, WELL DONE. Your roadmap for world domination of Debian/Ubuntu: I doubt any anti’s will take you up, but if they do, they can only thank you for providing step-by-step instructions instead of shouting you down again!

    Overall, I hope the tone and volume of this issue start trending down. You’ve certainly done your part in pushing things this way.

    –dB

    [reply]

  19. very funny, calling it “CLR” — I like your sense of humour!

    You need to understand one thing. Just as “developers” can’t be swayed by shouting and abuse on forums, “users” can’t be swayed by blog posts that mis-characterise them. “Patronising” is the word that comes to mind. Maybe even “preachy”.

    Let me explain.

    [In the rest of this comment, I say "I" but I'm pretty sure this applies to many, many others who may not want (or care) to post, but think similarly.]

    Step 1: Most people in real life don’t have a problem accepting that people are different. I don’t even try to convince anyone of anything unless I know them personally or they were *asking*. I don’t even “write them off as stupid in my mind” either :-)

    Step 2: Ulterior motives? See step 1: if I accept that you’re different, why do I care about your motives? [Anyway, I hardly ever ascribe ulterior motives to individuals. Corporations are a different matter ;-)]

    Step 3: lots and lots of detail. Nice. Good to know. But totally useless; I’d never even dream of getting into things at that level. Doesn’t matter why. You can, in your own words, write me off as stupid if you like :) And again, I’m sure there are thousands like me.

    Step 4: Contributions: same thing. I’d never be able to do anything remotely worth someone else picking up and using. I’m just not going in that direction. My “contributions” to open source are much smaller than yours — I install and maintain Linux for a bunch of non-tech friends and relatives around my city. I’m geek enough to manage a lot of things, but I don’t code much anymore. Other people may have other contributions. Many may not have any at all, and that’s fine. In your book they don’t have a vote, and that’s fine too… hey it’s *your* book!

    Step 5: I’m not even fighting this one. You go your way, I go mine, is my attitude. I actually said that somewhere on this topic.

    Step 6: See Step 3 and 4.

    End result: people like me will start following some of these steps only when there is NO distro without mono. Hopefully that will never happen. Until then, please don’t bother fighting us. We’re not actually fighting you. You have enough on your hands dealing with the shrill screams from borderline crackpots like BCN, who are such a convenient whipping boy in this debate that no one realises we quiet folk exist.

    [reply]

  20. Why not Vala ?

    [reply]

    directhex Reply:

    @3po, It’s something rather different. For new projects, sure, why not, consider it against the alternatives, as per usual

    [reply]

  21. As a Fedora Mono packager, I must say I have seen anti-Mono sentiments discourage people from improving our Mono stack, which is a shame. Great article!

    By the way, do you intentionally pick a name that abbreviates to CLR (cf. Common Language Runtime) or is that just an added bonus of starting with a “chicken little” theme?

    [reply]

    directhex Reply:

    @Michel S., a happy coincidence which I’ve embraced fully.

    [reply]

Leave a Reply