Commentary

Serdar Yegulalp
 

Fixing 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. Matthew Paul Thomas wrote an article about why free software often has lousy usability -- and what to do about it.

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.


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

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.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links