mpt wrote on Why Free Software has poor usability, and how to improve it. A good read, but a few comments:
On incentivizing usability, he suggests stronger incentives in the form of design awards and a bounty system. I suspect neither would be adequate. I'd suggest identifying a handful of "good" designers who have voluntarily made successful enhancements to some program, and interview them for what motivated them. I'll bet it was something other than the lure of fame or money! Whatever it was, seek to maximize THAT.
On inviting design input, I sort of tend to agree that in general people often don't realize they CAN contribute to open source projects, until someone invites them. However, the approach I'd suggest for fixing this is a bit different. This is an approach I've used extensively on Inkscape and other projects:
Watch for a user offering extensive criticism or suggestions for improving the UI that are well thought out and expressed. Often these guys can be recognized as the one complaining that no one is listening to him. ;-) Next, teach them how to make the changes to the program directly.
mpt would point out that "designers ain't coders", however really these changes tend to be pretty easy. Sometimes, if the program uses Glade or other XML formats for defining the UI, the work doesn't require any programming experience - and usually doesn't require even recompiling the program.
Even in cases where the UI changes need to be coded, the code tends to be fairly easy work as far as coding goes, often achievable by just copying and adjusting other similar code.
You don't need to be fluent in a foreign language to get around in a foreign country - often just knowing a few dozen typical words in the language (thank you, hello, please, toilet, how much, etc.) can suffice. Similarly, a UI designer doesn't need to know all the ins and outs of coding; just knowing the syntax for making buttons, adding menu items, and swapping out icon images can get you a LONG way towards your goals.
Further, an approach we've used quite effectively in Inkscape for people that even the above is too hard, is to encourage them to work up their ideas or proposal as a mockup, using Glade, Gimp, or even Inkscape. This gives something that other users can peer-review. A lot of issues can be worked out this way, before any coder comes near it.
On workflows and workloads, care needs to be taken to avoid proposed solutions that require the core developers to do something beyond what they're already doing. The reason is simple: They're too busy, and your proposed workflow will just bottleneck on them. Often they're still working on "it doesn't work", rather than "it doesn't work as well as it could." It's better if you can construct the bulk of your workflow to operate autonomously from any core developer involvement, or put off required involvement to as late in the process as possible.
In general, it occurs to me that many of mpt's ideas could be achieved by creating a team ala freedesktop.org, which works at a level above and outside particular open source projects. Such a group would focus on creating tutorials and specifications, creating shareable code to solve specific classes of issues, and so on.
I wonder why my critical comment posted more than a week did not become visible??
Pure laziness on my part. I get a crapload of spam comments, so rather than turn off comments entirely I just hide them by default, and go through and weed out the spam from the good once and a while.
a+b agreed, I feel like one of them :-(
c) Imho completely wrong, in the well known bad habit of the gurus to ask for code.
It's not wrong, it's just that you don't like being told it. ;-)
Remember that the vast majority of people who work on open source are doing it in their own freetime, and there is way, way more requests for changes than people to do them. It's a recipe for massive burn-out.
Obviously, the solution involves getting more manpower involved in fixing problems. If even just one person becomes encouraged to learn coding and send fixes, the entire userbase benefits directly.