Sponsored By

Fixing Broken Usability In Free SoftwareFixing Broken Usability In Free Software

How often do you hear the old canard that someone's done a great job of talking about a problem but doesn't have a solution? I hate that, too. <a href="http://mpt.net.nz/" target="_blank">Matthew Paul Thomas</a> wrote an <a href="http://mpt.net.nz/archive/2008/08/01/free-software-usability" target="_blank">article</a> about why free software often has lousy usability -- <em>and</em> what to do about it.</p>

Serdar Yegulalp

August 18, 2008

3 Min Read

How often do you hear the old canard that someone's done a great job of talking about a problem but doesn't have a solution? I hate that, too. Matthew Paul Thomas wrote an article about why free software often has lousy usability -- and what to do about it.

Matt's article breaks the general problem down into 15 subproblems, with the two biggest ones up front: the incentives for making free software are generally weaker than with commercial software; and there are few people who not only do good design but few places for prospective designers to train themselves apart from school (which costs money). From this he derives other issues, such as how suggestions for how to improve design face much higher hurdles than "simple" bug fixes -- like bug fixes are ever simple, but you get the idea.

Each problem also comes with its own solution. For the first problem -- weak incentives -- Matt suggests a whole slew of ways to make incentives stronger for writing attractive applications. I particularly like the idea of an escrow bounty for implementing a particular improvement -- it sounds like a way to "reverse-monetize" a project, to allow the users to set prices for what they think are valuable features to have. Instead of paying $150 for a program that only has two of the four features you need, you could submit a note to the programmers that there's $150 in bounty money coming from you if you put in these two additional features -- and use the program as it is now without paying a dime, if you choose to do so. (This is something I'll come back to in a future post, I think -- it has broader implications than just what's being discussed here alone.)

One graf in particular, about usability, really stuck out:

Without frequent user testing, volunteer projects rely on subjective feedback from the sort of people devoted enough to be subscribed to a project mailing list. But what these people say may not be representative of even their own actual behavior, let alone the behavior of users in general.

This is akin to a bookstore no longer stocking a given title, because two of the hundreds of people who came in and bought the book went back to the bookstore and lodged some vociferous complaint about the content. It only takes a couple of really noisy people to make a difference -- but that difference may not have anything to do with what's really needed. It might be an "outrider" (to borrow a term from statistics), one which looks a lot more significant than it really is in the longer run.

The whole piece is worth your time, no matter what end of the free software table you're sitting at. Creating free software isn't magic -- it's some of the hardest programming work anyone can do, and it's only now becoming clear just how hard it really is.

About the Author(s)

Serdar Yegulalp


Follow Serdar Yegulalp and BYTE on Twitter and Google+:

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights