- High visibility: The game was featured in the website sidebar. So I thought it'd be neat to contribute.
- Easy as HTML: Extract game zip file, edit Python files in a text editor, plug in my own filenames instead of the default ones. Start game, see my graphics.
- Developer was very open and friendly. Just an IT guy with a hobby.
- I knew about the Pygame website already because I followed FOSS stuff.
I don't know how many UI designers are browsing sites like that, but my guess is not many. But imagine if they did: what are the chances their workflow would be as easy as it was for me? In a compiled language, forget it.
I remember a few years back when suddenly it seemed like everything was on GitHub. My UI designer peers _hated_ this and many still do. So it's far from inviting in many ways for a UI person, though I don't mean to suggest they couldn't hack it if they wanted to.
What about it do they hate? I ask as a non-designer, to whom their perspective may be foreign.
Imagine code diffs, but for visual designs instead. Showing you which palette colors have changed, which margins have been tweaked etc. - Github doesn’t do any of that.
In any case, is it that insane to imagine a visual diff tool? Illustrator files are basically just SVG, it’s all very parseable.
https://github.com/makezonefablab/MakersBook01_MusicBox/comm...
In general one should not use PSD in an open source project, because it requires costly proprietary software. Also does not run on Linux
But that's different from helping an (OSS) application look good. For that, you have to make tons of mockups, iterate again and again, until you have something that looks good and consistent across the entire application. Ideally, you'd also want at least one other person to bounce ideas back and forth, and have an opinion about what you're doing.
This is real work, which requires a lot of commitment upfront. The equivalent of requiring a programmer to lay out the entire architecture before they write a single line of code. That's also something that mainly happens in a corporate environment, whereas for hobby projects it tends to lead to frustration.
In the case of Audacity, I remember that I have to google how to silence a selection every time I get back to it after a break of several months. I guess this means that the primary goal is somewhat missed.
There's always a cost to contributing. The cost gets bigger as the project gets bigger. This is totally unsurprising.
This is why people contribute more to software they use. You don't generally jump ships and help random projects for the sake of it.
You don't need experienced UI designers to fix these low hanging issues, yet.
Having some side projects or helping OSS is somewhat expected from a programmer. From other professions not so much.