Why Free Software usability tends to suck

# Why Free Software usability tends to suck Source: [https://web.archive.org/web/20030201183139/http://mpt.phrasewise.com/discuss/msgReader$173](https://web.archive.org/web/20030201183139/http://mpt.phrasewise.com/discuss/msgReader$173) The Wayback Machine \- https://web\.archive\.org/web/20030201183139/http://mpt\.phrasewise\.com:80/discuss/msgReader$173 I’ve been having a discussion with someone from[IBM](https://web.archive.org/web/20030201183139/http://www.ibm.com/)about whether it’s*ever*possible for for Free Software to have a nice human interface\. In theory, I think it is possible\. But in practice, the vast majority of open\-source projects are also volunteer projects; and it seems that the use of volunteers to drive development inevitably leads the interface design to suck\. The reasons are many and varied, and maybe one day I’ll turn this into a long and heavily\-referenced essay\. But in the meantime, here’s a summary\. 1. Dedicated volunteer interface designers appear to be much rarer than their paid counterparts — and where they do exist, they tend to be less experienced \(like yours truly\)\. 2. First corollary: Every contributor to the project tries to take part in the interface design, regardless of how little they know about the subject\. And once you have more than one designer, you get inconsistency, both in vision and in detail\. The quality of an interface design is inversely proportional to the number of designers\. 3. Second corollary: Even when dedicated interface designers are present, they are not heeded as much as they would be in professional projects, precisely*because*they’re dedicated designers and don’t have patches to implement their suggestions\. 4. Many hackers assume that whatever[Microsoft](https://web.archive.org/web/20030201183139/http://microsoft.com/)or[Apple](https://web.archive.org/web/20030201183139/http://www.apple.com/)do is good design, when this is[frequently not the case](https://web.archive.org/web/20030201183139/http://iarchitect.com/mshame.htm)\. In[imitating the designs](https://web.archive.org/web/20030201183139/http://www.rhythmbox.org/about.php3)of these companies, volunteer projects repeat their mistakes, and ensure that they can never have a*better*design than the proprietary alternatives\. 5. Volunteers hack on stuff which they are interested in, which usually means stuff which they are going to use themselves\. Because they are hackers, they are power users, so the interface design ends up too complicated for most people to use\. 6. The converse also applies\. Many of the little details which improve the interface — like focusing the appropriate control when a window is opened, or fine\-tuning error messages so that they are both helpful and grammatical — are not exciting or satisfying to work on, so they get fixed slowly \(if at all\)\. 7. As in a professional project, in a volunteer project there will be times when the contributors disagree on a design issue\. Where contributors are paid to work on something, they have an incentive to carry on even if they disagree with the design\. Where volunteers are involved, however, it’s much more likely that the project maintainer will agree to add a user preference for the issue in question, in return for the continued efforts of that contributor\. The number, obscurity, and[triviality](https://web.archive.org/web/20030201183139/http://bugzilla.mozilla.org/show_bug.cgi?id=136665)of such preferences ends up[confusing ordinary users immensely](https://web.archive.org/web/20030201183139/http://developer.gnome.org/projects/gup/ut1_report/customization_tasks.html), while*everyone*is penalized by the resulting bloat and reduced thoroughness of testing\. 8. For the same reason — lack of monetary payment — many contributors to a volunteer project want to be rewarded with their own fifteen pixels of fame in the interface\. This often manifests itself in checkboxes or menu items for features which should be invisible\. 9. The practice of[releasing early, releasing often](https://web.archive.org/web/20030201183139/http://tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/x147.html)frequently causes severe damage to the interface\. When a feature is incomplete, buggy, or slow, people get used to the incompleteness, or[introduce preferences](https://web.archive.org/web/20030201183139/http://bugzilla.mozilla.org/show_bug.cgi?id=52154)to cope with the bugginess or slowness\. Then when the feature is finished, people complain about the completeness or try to retain the preferences\. Similarly, when something has an inefficient design, people get used to the inefficiency, and complain when it becomes efficient\. As a result, more user preferences get added, making the interface worse\. Where a project is heavily influenced by a company under commercial pressure to ship a usable product \(such as[Netscape](https://web.archive.org/web/20030201183139/http://netscape.com/),[Eazel](https://web.archive.org/web/20030201183139/http://eazel.com/), or[Ximian](https://web.archive.org/web/20030201183139/http://ximian.com/)\), you’d expect the interface to improve as a result\. But in such projects so far, it would appear that the opposite has happened\. I think this is partly because the companies involved aren’t large enough to employ designers who are both smart and stubborn, and partly because the business model of the companies involves maximizing the revenue \(rather than the user satisfaction\) gained from the interface\. \[2002\-05\-07: See also[Why Free Software usability tends to suck even more](https://web.archive.org/web/20030201183139/http://mpt.phrasewise.com/discuss/msgReader$182)\.\]