02.28
It’s generally not the functionality of FOSS software I take objection to – generally its the neglect to put any thought into usability. Sure software package A can do everything software package B can, but how intuitive and easy is it?
I’ve had many debates on this subject with another developer at my work and we have basically come up with a formula to identify and rate usability of a piece of software. It goes like this (from memory)…
U = (T * R) + M
U = Usability
T = Time taken to perform action
R = Number of repetitions of an action
M = Time spent reading the manual or researching
The basic idea is that for a piece of software to be considered ‘good’ in terms of usability U should be as low as possible, when R is equal to 1, and as R tends towards infinity. Estimates for R should also be factored into the design. For example if you have instructed a user to edit their xorg.conf file and instruct them to use either Emacs or Vi, the initial value for M will be extremely high with R being 1, which is incredibly bad usability. Sure as R approaches infinity the high investment in M pays off – but unless your a sysadmin or hardcore it will never be an effective use of your time.
The problem is the Linux approach tends to favour an initially high value for M in the theory that it’ll get balanced out by R and while largely true, nowhere near enough effort is spent minimising the initial M, with new users getting pissed off at the learning curve. I use regexp based search/replace on a regular basis on documents and it lets me do in seconds what may take someone else hours to do without it, but I would not dream of suggesting to anyone that isn’t a developer to do it this way as M will easily dwarf (T * R).
Back to the subject – if you develop software for it to be considered ‘usable’, initial M needs to be as low as humanly possible, with it possible to invest in M as time goes on (and R increases), such as…
(M + 1) = (T – 1)
So if a user is truly going to perform an action repeatedly it should be possible to learn how to do it more efficiently. These savings usually come in the form of shortcut keys but can also be plugins, advanced modes and other alternate ways of achieving a goal.
Needlessly high values for U occur when the user is asked questions that they do not have the knowlege to answer. This can often be cured by providing advanced aids, better information or suggesting sensible defaults. You get the idea.
So what’s this about Bugzilla?
Unfortunatley the bulk of feedback in terms of FOSS software tends to be through bug tracking software – namely Bugzilla. As I have discussed earlier, listening to raw user feedback isn’t a strong point, and the distro’s just generally package up software written by thousands of different groups of users effectively acting as a shield between the developers and end users.
Usability problems do not factor into bug tracking software though. Bugs that cause crashes and glitches, despite the potential to affect only a small percentage of the userbase are often classified as severe, while massive usability blunders at best will never be given anywhere near that attention. In theory I am sure as soon as all the critical bugs get ironed out usability will be given attention, but who has ever witnessed an empty bug tracker?
As a result FOSS code is largely stable, efficient, portable, but the usability pretty much always sucks. This is why.