- 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.
«to review a .XML UI you need to apply patches, compile/build, play with it etc.»
That's also assuming that you have an XML or designer friendly UI toolkit at all. A lot of Open Source is built with GUI toolkits that use essentially 100% code and don't have good designer-friendly tooling (because the programmers were busy scratching other needs first). That definitely narrows a lot of designer input to designers that also can code.
A lot of people give Electron flak, but if there is one benefit to Electron becoming more common in the wild for open source projects, its the relatively much more designer friendliness of HTML/CSS(/SVG/etc) as opposed to classical C++ macros and duct tape UI toolkits.
For that matter, and bringing things a bit more on topic, I'd think Inkscape could be a good application to "dogfood" their own tool and own code a bit further and build more of their UI/UX elements in SVG itself. (Maybe even in a way that others could piggy back off of for future applications.)
"Don't have good designer-friendly tooling (because the programmers were busy scratching other needs first). That definitely narrows a lot of designer input to designers that also can code."
This is essentially the case with GTK+. Glade, though it has potential, is practically useless in it's current state. I've searched far and wide to find a mature project using it - so I can learn how to use it on the next level - and came up empty handed. There is no next level.
As far as it goes with GTK+, the only people designing UIs are programmers. It's all either hard coded in C or Vala (or sometimes C++), or defined in XML using tons of features that aren't implemented in Glade at all, and require an intimate knowledge of the GTK+ API.
As a free software enthusiast trying to work on a GTK+ application, I'll be the first to say, things could be (need to be) much better here! Beyond a couple trivial examples, the reference, and a couple dated books, documentation is extremely scarce. The tooling is incomplete, and it seems that the majority of people working in GTK+ have either grown used to working like this, or moved to another UI stack. Making GTK+ programming more accessible doesn't seem to be a priority (and adding more language bindings, or entirely new languages don't help nearly as much as a couple solid books on GTK+/GTKmm and a first class Glade would).
The only way to really learn the ropes seems to be by meticulously dissecting dozens of free software projects. No one will ever invest their time do this commercially when they can hit the ground running with Qt. It only seems remotely possible for stubborn people who write software as a hobby, and people who have matured to the point they can sell their knowledge. For a UX designer to end up here, they would have developed much more valuable skills in the process.
- 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.