Open source projects are inhospitable to designers because they come in and arrogantly blast their opinion into an establishment. The establishment knows its userbase better than a designer will.

The designers then crawl off and blog whinge about it.

Open source doesn't work the same as 'business' where change drives sales. That's the misunderstanding.

Wow - a very 'us and them', aggressive attitude you've got there.

It's clear that for any app, site or OS to have mainstream success, it needs to have a well-designed interface, a good user experience. Apple, Google and others have all invested heavily here, and the big winners all have interfaces that are easy for a non-technical user to use.

If open source projects want to gain mainstream usage, they also need to invest in usability, and like any skill, there are people who have more ability and more experience. As these people are not necessarily programmers, it can be hard for them to contribute to open source processes that are centred around code contribution.

Regarding the us-and-them attitude, it's a vicious circle.

A person who is a self-defined designer often means it in opposition to coding. That means that they've defined themselves as someone who can't get anything done on their own. That works in a corporate environment, because they can talk somebody into letting them boss around developers on the payroll.

However, that leads to weird power dynamics and resentment on both sides. It also creates a situation where are lot of developers are discouraged from thinking about design, meaning they appreciate it less.

Where I depart from your analysis is the notion that open source projects really want to gain mainstream usage. I'm sure many would say they do, but I doubt many actually care enough to do something about it.

I think this is only going to get better in ways that erase the corporate line between designer and developer. E.g., developers who have some design skills doing more open-source work. Or designers buckling down and learning to submit patches like everybody else. If usability is the itch they want to scratch, they shouldn't wait for somebody else.

Otherwise, I think designers have to limit themselves to producing research and inspiration. E.g., doing well-supported usability studies on a popular open-source apps. Or producing design treatments as in a positive, here's-one-way-you-could-do-it spirit.

You miss the point: success in the traditional form at least is 100% irrelevant.

Consider Linux, tex, emacs, vim, apache, mutt, x, postfix.

All successful, yet no traditional form of usability.

Many of these are very usable for their target audience:

Vim: adds such user-friendly features as syntax highlighting and WIMP while keeping an interface (vi) that is already well known to it's users, thus preventing them from having to learn a new set of commands from scratch

Emacs: Clearly the most programmable text-editor currently used. The ease of usability for extending it is the reason it is adopted.

mutt: synthesized interface from several already existing mail clients, most notably pine and elm

Apache: If you consider the user to be web developers, it (NCSA HTTPd which is what Apache grew out of) introduced CGI, which was a huge usability step for making dynamic web-pages.

Linux: Not sure. It's essentially a clone of SVR4; probably just the fact that among it's always had the best driver-support on commodity hardware is the win here.

Postfix: It's more usable than sendmail; not really a glowing review though.

X: Yeah, I can't think of a single good thing to say about X. I've heard that Motif was the "killer app" for it that kept it around, but I wasn't there so not sure.

All those you mentioned are highly configurable and accessible through the command line interface. For the target audience, they are highly usable. 'Traditional' (if we speak of the same thing) does not care if your users are general users or engineers.

In my experience programmers are often the worst people for designing the interface to their own product. Their designs are based on their own mental model of the product, which is in turn based on how the product is engineered.

Their intuitions of how end users will use a product is skewed by this same biased mental model. End users lack the in depth knowledge of how the product is constructed.

I've seen products I've built be run through formal user testing and A/B tests and the most important thing I learnt was that my intuition about user behavior is always wrong.

The truth is that a product needs both good engineering and good design to succeed. If it lacks either then it is going to fail. Engineers tend to be oblivious to bad design so if you are ignoring critiques then you are throwing away valuable data.

The thing is that most open source software was designed for use by engineers for engineers and doesn't have a success criteria other than 'makes problem disappear'.

formal usability testing is irrelevant on such things so stop muscling in your own concerns and slating them for a job done.

How is that so? A pretty standard part of usability testing is say heuristic evaluation. You pick the heuristics applicable to the target audience - engineers, like be accessible through CLI. No response means the app executed without problems, man doc etc and test. Usability != pretty interface.

In fact, sometimes you might not want a beautiful interface, because you want people to get the job done. I think the issue with the original article is that it paints broad suggestions so it is easy for me, you and everyone to argue their point.

What about "makes problems disappear with a minimum of effort"?

It is true that powerful systems require some learning, but there also are a lot of things that programmer's would not have to learn if UIs were better.

As an example, consider the time wasted to learn the idiosyncrasies of the various Unix tools. Standardizing simple things such as the way to query a program's version (-v, -V, --version, probably others), or the features of the regular expression grammars of tools X, Y, and Z would have made live quite a bit better. And yes, it would break existing code, but sometimes, the price of change is worth it for the benefits it brings, accumulated over the years.

I think there's more to it than that. The problem is, when you understand a piece of software well, you cannot, try as you might, put yourself in the position of someone who does not yet understand it. Developers who aren't aware of that are naturally going to be hostile to the suggestions of designers. Even as a developer who is aware of it, I have to force myself to listen sometimes to people who are telling me that some aspect of my app isn't as obvious to others as it is to me. I'm sure this experience is not unusual.

At which point I show the next person how I learned it. It's called training. The best way to do this is documentation.

Usability nazis want people to be able to ride a bike after 5 seconds. They devalue learning and understanding most if the time rather than achieve an equilibrium.

"Usability nazis"? I'm afraid your choice of words is leading me to suspect that it's not the designers' arrogance that is the problem here.

It's not that they devalue training, it's just that they're realists. You seem to believe that people are willing to learn how to use software slowly over time but the reality is that when a user gets frustrated they simply stop using the product and find an alternative even if it lacks features.

One thing I think we're all confused about is our definitions of users and target audiences. Obviously the users of CLI programs and other "power user" software are willing to take the time to read the manual and educate themselves. Software for these users doesmt require the kind of attention to design the article talks about. Then there are the average users and software they use. Things like word processors, GUI file managers, etc. Those users need their hands held with "dumbed down" and "pretty/glossy" design. You can still provide complex and powerful features to them but you have to design their software in a way that makes their first introduction very easy to use. Meanwhile you can provide options within settings menus and customizable toolbars for the veterans who already know how to use such tools. It's the best of both worlds and everyone wins.

There's also some software that you'd think only power users would use but then someone comes along and makes it accessible to the average user in a way that's easy for them to get into while still useful for the power user. GitHub's GUI app is a great example of that. They took something that we all assume only programmers and savvy users would get and designed it in such a way that makes it easily accessible for total newbies. Because of that there now people you'd never think would use a VCS like Git making heavy use of it. People like writers, graphic designers, bloggers, scrapbookers, and all sorts of "average users" are now using the thing that we thought only the power user's would touch. The best part is that even those familiar with the command line use of Git now use it because it makes their life easier too! We can totally take a lesson from that and apply it to these tools that we think don't need better design.

which projects are you talking about?