Understanding open source Part 2

Open source software (OSS) is consistently gaining strength as a movement and a viable software development paradigm. If you've heard of it but don't quite know what it is, you may want to read Part 1 of this article, which appeared in the February issue of KMWorld.

In the past, OSS has typically been the province of hobbyists, tinkerers and techies. Some open source projects--such as Apache (apache.org) and MySQL (mysql.com)--are server-side technologies that can reasonably expect technical expertise from their users. Others, such as Linux (linux.org), could be of use to less experienced users but have historically been too technical to be accessible to them.

There's a good reason for this: Usability engineering is difficult in open source development environments. But the usability landscape is changing. Linux and its core applications are easy and complete enough to be a viable alternative to MS Windows for non-technical users (while retaining their traditional advantages such as stability and security). Other open source products are ready for general consumption, too, such as the Mozilla Firefox Web browser, the Mozilla Thunderbird e-mail client and the OpenOffice.org office suite. All provide similar user experiences to their commercial counterparts, and are largely compatible with them. (You can work on the same document in OpenOffice and Word, or use Linux to connect to shared Windows folders.)

So is my belief about OSS and usability engineering wrong? I don't think so. But there's more than one path to usability.

User types

It is helpful (though simplistic) to think of computer users in two categories: power users and end users. A power user has a significant amount of technical knowledge and is willing to spend time learning about and tinkering with his or her computer. Power users prioritize power, flexibility and customization over out-of-the-box ease of use.

An end user sees his or her computer primarily as a tool: It should just work, and should require minimal training and maintenance. The vast majority of computer users are end users. Until recently, most OSS wasn't appropriate for them, but that's changing.

The case against usability

Like all commercial concerns, software companies must make a profit. If their products sell, they succeed. If their products are hard to use, customer support costs rise and customer retention may fall. Usability--or at least perceived usability--is critical to revenue growth, particularly if neglecting it causes user dissatisfaction. Thus, companies have an important incentive to hire usability engineers, do usability testing and respond to customer complaints. User experience is probably more important to the bottom line than stability or security--a fact that Microsoft has demonstrated repeatedly by prioritizing enhancements to the user experience over stability and security (though such enhancements don't always result in increased usability).

Traditionally, open source projects rely on a network of volunteer developers, running at least partially without a direct revenue stream. There are many reasons why that is good, but drawbacks as well. People, no matter how altruistic, are largely motivated by self-interest. So developers who work on OSS are most likely to focus on aspects of the software that interest them or affect them directly as users. While that has positive implications for security and stability, it is also likely to result in a user experience tailored to the needs of power users (the developers themselves).

Even when an OSS project is actively interested in accommodating end users, there are hurdles. Usability testing, evaluation, user interface design and other usability engineering services are expensive, and OSS projects often don't have large budgets. Volunteer projects that do raise capital may be reluctant to use it on usability engineering, because the impact on product development is indirect and developers may not want to implement the resultant recommendations. And while a usability expert could volunteer his or her services, there is less motivation to do so than for developers because:

• The impact on the final product is indirect and thus less satisfying.
• For there to be an impact, developers must choose to implement the expert's recommendations, but they may not be motivated to do so as described above. And developers may simply disagree with designer recommendations. That's difficult enough when a corporate structure exists to enforce roles; without that means for enforcement, resolving such a dispute is much harder.