Thursday, February 12, 2009

On the Inability of this whole system to actually help you in any useful way

Howdy, Nixettes and Nixers!

In my article "Bug Bang II: Revenge of the Devs" I was unfair; boldly, plainly unfair, but you'd have to dig into Fedora/RedHat strategy of dodging the bullet to learn how misplaced one can be when ones submits a bug, sees it discarded, and shamelessly, rudely even, makes a fuss about it.

Doing so, you are hitting the wrong person. I was crawling the fedora quite obscurely organised sphere of "community" websites (Join! Get! Communicate! Wiki! Planet!! - ??) and realised this: They've build their own Community Firewall of volunteer bug-bashers. Who are they? They are not RedHat people, they are volunteers that commit self-sacrifice of their free time in reviewing bugs, tasked by their masters with one duty in their faithful lives: bash them, squash them, write off a maximum of them 'cause so much of them aren't really bugs. You know that, they aren't bugs, they are features. duplicates,... Or temporary shortcomings. Or, mainly, they are Someone Else's Problem. And certainly, you can't waste precious Devs time reviewing them.

And so if for one moment you felt you did your community job of End User by taking the time to register to a website, search for duplicates, submit and document your issue, all because it's not because you can't code that you can't participate, you are wrong.

Users are such a pain in the ass. Why should Devs, the semi-Gods of OpenSource, have to bear with them? They are incompetent, they cry over the littlest of glitches all the time (469045: No DVD Drive! 251080: Laptop doesn't switch back on!). EndUsers can't compile code anyway, let alone commit a patch: Pussies!

The fundamental concept of SEP (Someone Else's Problem) is one that allows our SemiGods to focus on the all-important matters of providing us with a new version of their almighty, sacred Code, again and again in their imaginary world of up-to-date-bleeding-edge novelties, as soon as possible, so that they don't feel left behind, outdated, discarded (and disrupted in their Sacred Workflow); and to do that, you have to be protected from them, and also you have to distract them by coercing these fucking users into upgrading their whole operating system every six months (for as utterly crazy as it sounds), and download gigs of all-important updates in the meantime. I can actually understand that, from the human side: Who, seriously, likes to have its failures documented, published, and be publicly requested to amend and fix them? Nobody, of course.

One thing may explain the other anyway: Obviously, why focus on a bug in code that has an official life expectancy of barely six months? (and hurting someones' valuable self in the process?) The first to answer "So that the next release is bug-free", please go back to whatever FairyTale world you happen to live in: I upgrade my desktop, webcam ceases to work; I upgrade the laptop, Compiz crashes the system twice a day.

And when will NetworkManager actually remember my fucking password? When will Gnome restore autologin? When will they really come around a real one-click solution to mp3/DVD reading that doesn't involve buying stuff from the Internet or discarding multiple hypothetical patents warnings? You can hardly do that in one click. Will my Syntek webcam die when the kernel starts to include drivers for it, while it works perfectly if I compile the module myself, like it happened with my Logitech STX? When will Linux systems start to use the same amount of battery power as XP does?

When will they start committing and releasing code with an actual life expectancy of more that a few moths?

When will they start pushing code up & downstream when it is actually ready for production?

No comments: