I’m excited about today’s CS849 class — it’s the first class all semester that specifically deals with usability issues that emerge in FOSS software and culture. I’m leading the discussion of several high profile blog postings on this topic. These blog postings, and their connections to one another are as follows (notably not in chronological order):

The story begins with Eric S. Raymond trying to configure CUPS (Common Unix Printing System) to print to a shared printer cue on a remote machine. In the process, Raymond became frustrated with the usability issues of this process, and so he decided to write the essay “The Luxury of Ignorance: An Open-Source Horror Story“. In this essay, Raymond describes some legitimate usability issues; but the tone of the essay was highly condescending to almost everyone. Repeatedly he describes the need to better design interactions to make Linux more accessible to “dumb clueless users” (his words, not mine). As we will see in the other blog posts (not yet mentioned), it is actually quite challenging to attract good designers to open source projects. Perhaps attitudes like Raymond’s are part of the problem: above all, a good designer knows to respect their users. This can be contrasted to Raymond’s suggestion that designers “sit down at the system like a dumb user who’s never seen it before”.

Anyways, I digress from the story. So a few days after posting the aforementioned easy, Raymond post a follow-up entitled “The Luxury of Ignorance: Part Deux”. In this essay, Raymond described positive feedback to the first essay, and notes that he received numerous emails with comments such as “Gee. And all this time I thought it was just me.” At this point, Raymond’s essay get the attention of John Gruber over at Daring Fireball. Gruber’s reaction is more inline with my own. Specifically, he notes:

“Developing software with a good UI requires both aptitude and a lot of hard work. Raymond acknowledges neither.”

And later,

“If there’s a glib, nutshell synopsis for why Linux desktop software tends to suck, it’s this: Raymond and his ilk have no respect for anyone but themselves.”

But it’s more than that. Gruber goes on to point out that it wasn’t just the “dumb users” who had trouble configuring CUPS, it was Raymond himself, along with other UNIX geeks who read his blog. The problem is certainly much deeper than Raymond realizes. On this note, Gruber wonders how Raymond could write an essay on FOSS usability problems but not mention Matthew Paul Thomas’s (apparently well-known) blog post “Why Free Software usability tends to suck“. This is where things get really interesting.

In Matthew Paul Thomas’s (M.T.P) blog post, he describes 9 hypothesis or observations why might help to explain some of the usability issues common to many free and open source software projects. While these are interesting in their own right, M.T.P’s follow up essay “Why Free Software has poor usability, and how to improve it” expands the list to 15 items, and represents six years of reflection on this topic. As such, I will be focusing on this later piece. In brief, the 15 reasons are as follows:

  1. Without monetary reward (e.g., salaries), there are few incentives to do usability work in FOSS.
  2. It is difficult to attract good designers. (Noted above)
  3. Related to 2., design suggestions are not welcomed by developers.
  4. It is difficult to measure success or improvements to usability.
  5. In FOSS, projects are started by Coders. Design is tacked on later.
  6. With many people voicing design decisions, it’s hard to maintain a unified and consistent design trajectory.
  7. FOSS software tends to simply imitate proprietary interfaces.
  8. Developers work on parts of the system that they are interested in. Design is often not of interest.
  9. Small usability errors are often assigned low priority, and fixes are delayed.
  10. Project leaders often agree to add new options and configurations to placate the many volunteer contributors.
  11. Every developer want to have their “15 pixels of fame” on the GUI.
  12. FOSS communication channels are not suitable for doing design work.
  13. Release early, release often means that early adopters get used to poorly thought-out designs.
  14. Developers often code “back end” functionality, assuming usability issues will be addressed by those writing a “front end”.
  15. FOSS software often interacts with other FOSS software from different projects — but the communities rarely communicate.

Ok, that’s the long list of M.P.T’s points. I’m sure I’ll be discussing some of these in more detail in future posts.