Two things:

- Consistency. A good UI requires consistency throughout, which requires a good understanding of the entirety of a piece of software, and a willingness to work at a high level. For open source packages there’s rarely a UI standard to hold individual problems up against.

- User testing. UX design doesn’t work in a vacuum, it requires user testing to be effective. This costs a lot of time and effort to organise, and isn’t something you can hack on for a few nights. It’s possible to to A/B testing to gain data of course, but then you have to persuade your friendly developers to implement a testing framework and have some place to store data while waiting for the results to analyse.

Part of good UX is consistency and getting that kind of requires a consistent team or an all-knowing overlord. My guess is that's why it's hard to get to and keep a good UX in OSS. Once the UX is good there shouldn't be much work for a designer to do and they're not gonna sit around, not getting paid, just to make sure someone doesn't mess it up, that is boring.

I think it's a slightly different issue. A UX designer usually does not have the ability to run a project independently from the beginning. A programmer can, even if it results in a crappy UI.

Successful open source projects don't usually start with teams. They start with programmers with an itch to scratch. It's hard to get investment in a group of people. Everyone is always keen at the beginning, but drift away as the realities of the daily grind kick in.

So if you are non-programming UX person, you are dependent on a programmer who might not stick around. Then you are shopping around for programmers (which never show up). If you are a programmer who wants a UX specialist, the one you start with usually wanders off and then you are shopping for a new one (which never shows up).

The result is that programmers develop a culture of building these kinds of apps and UX designers don't. Even if a UX designer shows up late in the process, they now have to fight all the programmers who have gotten used to making the decisions. And one of the perks of running your own project is not having to listen to other people. If you want to do what other people tell you, you can get paid a lot more ;-).

I have a theory. There's a much weaker positive feedback loop. If a commercial product is nicer looking and easier to use, more people will buy it so there's more money to fund development. Management will demand redesigns and improvements because that creates more revenue.

With open source, the feedback loop from users to developers is much weaker because it's not powered by money. It turns out changes in cash flow are a valuable signaling mechanism. I think this is an issue with many aspects of Open Source development, not just UI.

I'm not in any way saying this is an unresolvable issue or that it dooms OS projects, or anything like that. I just think it's a factor.

My two cents:

- UX designers that are actually good at their job seem to rarer than good programmers

- Hence the pool that would or could contribute to FOSS is smaller

- Getting UX changes in is likely something that maintainers don't really like, because it's harder and more time consuming to review (eg. the code you can just look at, but to review a .XML UI you need to apply patches, compile/build, play with it etc.), also UI changes will almost certainly require a bunch of code changes, so if you're changing a ton of lines to "improve UX", then it's not really a great incentive for a maintainer to invest his time into merging that (because it's "just UX").

UX also tends to be opinionated, the guy who wrote the interface originally probably has no issues using it himself, but is probably somewhat opposed-by-default to changing it (works for me™).

Also, if the UX human isn't also a good coder she probably needs to find someone who works with her to make the necessary code changes to support her UX changes, which would be quite challenging in many projects. (Why would I invest a lot of time to work with someone - that I don't know, has no reputation in the project - on something where maintainers will probably not give some sort of "yeah we'll merge that"-waiver?).

- Good UX has a lot to do with consistency. So fixing up an inconsistent project will mean tons of changes, exacerbating all the issues above. It might be as big a change as porting to a different language or framework. How likely is maintainer acceptance for such changes?

So unless there is a process for doing UX in a project, and all the project maintainers back the process, and the process is actually somewhat sane, it's unlikely that it'll work out. This might mean things like having an UX review queue and UX review for new interfaces. Imposing strict UX guides on code/feature contributions might also deter contributions. So you also have to balance these things.

I'll add another potential reason - culture. Many (most) developers grew around open source, or at least interacted with it in significant ways during their (work and/or hobby) career. Many if not most of the tools they (we) use for programming come from open source too. So we're kind of used to this environment of collaboration. You see a project you like and have some spare time, it's natural to contribute.

I doubt UX specialists live in such a culture. I might be wrong, but from my experience with artists and designers, it's much more of an individualistic culture with stronger commercial interest. I.e. "I do it for myself" and then "want my work - pay me".

If that is true, then there's simply much less UX specialists with spare time and interest in open source than there are such developers.