Also, anybody who's been to art school or mentored junior developers knows that we get most defensive about the things we're least confident in. Unfortunately, that comes out when trying to address UI problems in FOSS projects.
Also, anybody who's been to art school or mentored junior developers knows that we get most defensive about the things we're least confident in. Unfortunately, that comes out when trying to address UI problems in FOSS projects.
I think you've captured the crux of the issue and the same applies to designers too.
Say I just spent the last eight hours trying to convince a stubborn front-end developer that the reason customers complain about our UI and the product keeps failing usability tests is that it needs a UI overhaul and that telling people to "just RTFM" will not win us any new contracts.
Getting home and having a similar debate with a FOSS dev team where I have even less sway does not sound like a rewarding way to spend my free time.
Imagine encountering a genuinely useful open source software project run by designers that spaghetti coded it in some node-based "nocode" monstrosity. As a competent developer, you know that you could move it to another more capable node-based system that would make it easier for them to use, maintain, and expand upon.
-----------------
a) Start asking questions to get a sense of how things worked and where they could be simplified conceptually. GO TO SCENARIO 1.
b) Fully implement a brand new architecture and submit it in a pull request. GO TO SCENARIO 3.
c) Come up with a complete refactoring proposal that shows them how your changes would affect the project in the end and make people's lives easier, and post it in an issue so you can collaborate with the existing folks. GO TO SCENARIO 2.
----------------------
SCENARIO 1: Unfortunately, that triggers the maintainers' defensiveness about their technical decisions because they're not confident in them. Then the people who have developed workflows around the shittiness get even more defensive. The real problem is that they don't have the technical depth to see how it would work in the end. Say that and good luck getting any responses for anything ever. THE END.
----------------------
SCENARIO 2: Damnit. GO TO SCENARIO 1.
----------------------
SCENARIO 3: Despite the significant amount of effort you expended, your work just sits and collects dust. You ask why, and someone who isn't the primary maintainer responds saying something about their deciding it was too much work to generating new icon sizes. You offer to automate the process. GO TO SCENARIO 1.
----------------------
Even then, having worked extensively on both sides of this dichotomy, I can assure everyone involved that the disdain some developers have for designers is astonishing, and the reverse generally isn't true. Of course there are exceptions.Fundamentally, designers and developers have the same goal with different concerns, approaches, and areas of expertise. It's pretty ridiculous that we haven't figured this out yet.