Over the last few weeks, I've interviewed several thought leaders in usability and open source software. I'd like to take another opportunity to recognize Ginny Redish, Eric Raymond, Richard Stallman, Chad Fennell, Dave Rosen, Greg Laden, and others for their time, and for their input to my study.
What did I learn?
In general, all agree that open source software provides a unique challenge. To be sure, many programs (including "commercial" or "proprietary" programs) may view usability as a final phase effort - going through a usability study only at the end of a project, right before go-live, intending to "validate" design decisions made earlier. That's if they consider usability at all during the project.
However, open source programmers tend not to think about usability. Open source programmers, to borrow and paraphrase from Raymond, tend to "scratch an itch," to create programs that are interesting to them or solve a particular problem. The functionality and features of the open source program are key. How the program looks is secondary.
To put it in another context, writing an open source program is like baking a cake. The interesting part of the process is putting the ingredients together, mixing them, to assemble the cake. Once the cake (or open source program) is "baked," the look and feel is less important. Appearance is like putting the icing on the cake. It's window-dressing, and thus carries less value.
But we also (generally) agree that usability is important. How a program is used and how it appears are both key items. Truly technically-minded folks may not mind that a program is difficult to use, as long as it does the job. (For example, many folks responded to my "what programs have good usability?" question by suggesting very specific programs, with the caveat that the program may be difficult to pick up, but once you figure out how to use the menus - or once you get past a particular, quirky design choice - the program is fairly straightforward.) However, the general user with average knowledge will not be able to accomplish tasks with the software if it is difficult to use. If menus are obscure, if the workflow is convoluted, or if other aspects of usability are poorly implemented, then these users will not adopt the program.
Interestingly, thought leaders also suggest that there has been very little - if any - experiential study done on the usability of open source programs. This seems to be a largely unexplored area, save for a few high-profile projects (such as the Gnome desktop environment) where a key partner (such as Gnome's Sun Microsystems) invested effort to examine usability.
With a few exceptions (Drupal is one), the open source community at large does not include usability in their development process. As mentioned earlier, these open source developers do not see the value in studying the usability of their programs. They have little interest - or indeed, little knowledge of how to go about it. Thought leaders (Raymond, etc) suggest that open source developers would be more likely to mimic successful usability from other programs, rather than apply the rigor of usability study to their own work.
So that is the launching point for the rest of my project. I want to do a study of programs that demonstrate good usability and provide an analysis for why these programs "work" successfully. Of course, I've been advised by at least one thought leader that successful usability may not be very transportable to other programs - what works for one program may not be good usability in another. My results will need to carefully discuss what makes for good usability in each of the test candidates, and how this might be applied as "lessons learned" for open source developers to adopt - with the caveat to apply the lessons carefully to other projects.