Well, most design people also have side projects, be it a Tumblr page or an endless supply of drawings that they just do to improve their drawing skills.
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.
I agree this is a big job. Overhauling an existing application means a ton of work for both the designer and the developer. However the primary goal of designers should be making users work effectively. Building something that also looks good is a secondary goal. Great designers achieve both goals. If skills or budget are not great, go for the primary.
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 is plenty of work that can be done incrementally though. Contributing as a designer into an OSS project is no different in commitment than another programmer/translator/contributor would.
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.
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.