I've just read Glynn's post about an article open source issues. While the article's main points is nicely refuted by Glynn, one line got me thinking: "If you can't install it, you don't deserve to use it".

My point: Free software tools are incredibly bad at automatically doing the right thing - or at least don't aid. GStreamer's support for "just working" is a mess - everything requires manual intervention when in fact the GStreamer core should just do the right thing. Examples are autoplugging (There's a "let's just hope nothing breaks" mentality), plugin registration ("it works most of the time and if not, just delete all your config files and try again") or selection of audio and video outputs ("Just try another possibility in gstreamer-properties"). Nautilus still doesn't present me with "network places", my Linux kernel requires manual insertion of the right modules (or alternatively, distro-specific discovery tools) instead of a tool that jsut does the right thing. Even my Debian packages have let me down recently, when I tried to install icecast2 only to figure out that activating it requires editing a config file which it tells you in a one-liner on bootup. Next time, pop up a dialog during install, please? And to finish it all off, gtk-doc is one of the worst tools in the just works department.

The reasons I have identified why this doesn't just work so far are these:

• We (the developers) all know how to get stuff done without automation. So why should we invest time in automation, when we can do without? I believe the fact that most people that are working on automation are company funded might be a good prove for this reason. Also there's a lot less duplication going on everywhere than in product automation. There's less mp3 players in Debian than distros available, which is another proof that automation (in this case installation) is tagged on and not designed into it.
• Automation is hard. It does not only require code that does it, but it requires knowledge of the full system you are working with and adding enough introspection capabilities to the system, so the code can work from within. And especially providing introspection capabilities is an often neglected part, if only because it's boring or people don't know how to do it.

Gstreamer autoplug

Of course there's also a reason why I started to think about such things and it's the new autoplugger I'm hacking on, that's finally supposed to do everything our old autoplugger missed. While I had to write a lot of ugly code to get my automation working, all the features have been implemented and I'm using it on my local Rhythmbox for playback without problems and without all the old workarounds. I think I'll do a first release soon to get more people interested in it, when I have the metadata importing working without the one hack it uses, too. Especially because that will add an important feature: It will automatically add all sound files GStreamer knows about and not just those that are "enabled". I'm already afraid of the day when I'll try to import / just to see if it works good enough. I hope to get this stable enough (including the video part) so we can retire the old autoplugger for the next major Rhythmbox and Totem releases and Gnome 2.8. Hopefully that'll be the first release where Rhythmbox doesn't need to work around any GStreamer issue anymore and just can play any file that has audio in it.