Janet Haven

If the Open Source community wishes to truly prosper and have their tools used by the general public, it is fundamentally necessary for them to recognize that the majority of the users will never know that they happened to invent a particularly clever algorithm for synchronizing the multi–threaded editing of their complex data structure. What the user will see — and what they’ll judge the project based on — is the user interface. If it’s inadequate, no one outside of other geeks will touch the program.

Oh, Michelle, you're so right. I know Michelle through her work as a lead developer of open source solutions at the CitizenLab in Toronto. So while searching around for information on usability and open source software, I was delighted to find her article in First Monday from a couple of years ago that touched so accurately on some of the problems open source software faces.

In my work at the Open Society Institute's Information Program, I've been involved in funding a number of open source software projects aimed at a range of civil society constituencies. The prettiest of the lot, by far, is LiveSupport, developed by the Media Development Loan Fund's CampWare project in Prague. LiveSupport is open source radio station management software "that provides live studio broadcast capabilities as well as remote automation in one integrated system". Not surprisingly, it seems to be enjoying fairly enthusiastic uptake -- part of this is due to the clear definition of the intended audience (community radio stations), as well as the strong network that MDLF has built up over the years. But I also think that the enthusiasm I've heard for the software is due to LiveSupport's excellent set of user interfaces. They're intuitive, restrained but colorful, and make you want to use the software. It shouldn't be a suprise, then, that CampWare worked with the Parson's School of Design on LiveSupport's look and layout.

In The Usability of Open Source Software, David M. Nichols and Michael B. Twidale argue that a number of factors contribute to the lack of focus on usability in open source software. The most obvious problem is the lack of involvement of usability experts in the OSS development process, but Nichols and Twidale point to social/cultural issues as well:

• Developers, they point out, are not typical end users. What seems obvious to a developer is far from obvious to my mother when they look at the same software interface.


• OSS development tends to happen when programmers are "scratching their own itch". Thus, if we accept the point above, functionality is usually prioritized over usability.


• Open source software, the authors theorize, tends even more towards code bloat (and thus confusing and event competing functionality) than proprietary software. They explain further:

  Given the interests and incentives of developers, there is a strong incentive to add functionality and almost no incentive to delete functionality, especially as this can irritate the person who developed the functionality in question. Worse, given that peer esteem is a crucial incentive for participation, deletion of functionality in the interest of benefiting the end user creates a strong disincentive to future participation, perhaps considered worse than having one's code replaced by code that one's peers have deemed superior. The project maintainer, in order to keep volunteer participants happy, is likely to keep functionality even if it is confusing, and on receipt of two similar additional functionalities, keep both, creating options for the user of the software to configure the application to use the one that best fits their needs. In this way as many contributors as possible can gain clear credit for directly contributing to the application.

  Wisely, the authors note that "This suggested tendency to 'pork barrel' design compromise needs further study". Indeed.
• I'd add one more issue to the usability question, based on my work with teams of developers in commercial software. Developers like to do their own thing, and many engage in volunteer OSS projects for that very reason: during the day they're developing banking software to make a living, and volunteering on a project at night or on the weekend provides a creative outlet. The whole point is not to have to code to someone else's spec.

Nichols and Twidale point to two further issues which, for those concerned about software usability, should be most troubling. The first is the thing we all know but ignore anyway: design for usability should take place in advance of any coding.. This is like commenting software code: you always think you can go back and do it later. The truth is, you can't. Or you can, but it'll take a lot of time, and be a big pain, and it still won't be as good as if you'd done it when you should have.

The second point is more subtle, but perhaps the most important: usability problems are more difficult to articulate than functionality problems, and are extremely difficult to distribute for correction to a far-flung group of developers. This is because usability issues are not necessarily neat packages, but may cut across the territory of several different developers, with potentially different styles or approaches.

In poking around online, it seems like there's a lot of writing on the issue of OSS usability, but not a lot of action aside from personal initiative (information architects or usability experts volunteering on OSS projects). One project based in Germany, Open Usability provides an online matchmaking service for usability experts and open source projects. Currently OU has more than 100 open source projects registered looking for usability expertise -- but far too few usability experts signing up on the other side.

Aspiration, one of my favorite techy NGOs, organized a FLOSS Usability sprint last February and a second one in August with Blue Oxen Associates. The August meeting helped to defined the concept of ExtremeUsability, and applied it to three civil society-focused open source projects: Social Source Commons, CiviCRM, and Hallway. I'll be interested in finding out how that experience has shaped the evolution of each of those projects.

No big conclusions here, except that this is an area which clearly needs inventive solutions. It seems that there's a problem from both sides -- somehow, usability experts and information architects need to be pulled into open source projects, and leaders of open source projects need to begin with usability design rather than tacking it on at the end of a project, if at all. I'd certainly welcome thoughts on ways to approach this (and on other projects that are addressing the issue).