It's a tough nut to crack. Open source contributors tend to want to dive in and make the one patch they want without engaging in any design or feedback process. Installing that process means someone has to take up managerial duties. Most projects stumble along with a "one coder army" who expedites these processes by assuming anything they can't do on their lonesome is out of scope, and all feedback, patches or design ideas are strictly suggestion. Switching to a team management approach when a project gets big is a big source of friction since it's rare to have a strong solo dev who is equally capable at giving up direct control and delegating. Usage of a project is often mismatched with development energy, creating unbalanced workloads.
So the tendency ends up being that a lot of projects just stay small and go out of their way not to grow, even when they address a problem that demands more scope than they have.
My suggestion given all of that is to not give up, but focus your design energies on the inspirational: if you produce mockups and prototypes that are hugely compelling, someone will come out of the woodwork to realize some of them: you may not know which ones or when, but you're giving them footholds in approaching the problem.
Yes, I've not tried submitting pull requests or forking code so I don't have any experience of the etiquette or protocols needed like developers must have in spades.
Very interesting point about inspirational mockups, definitely food for thought!
So the tendency ends up being that a lot of projects just stay small and go out of their way not to grow, even when they address a problem that demands more scope than they have.
My suggestion given all of that is to not give up, but focus your design energies on the inspirational: if you produce mockups and prototypes that are hugely compelling, someone will come out of the woodwork to realize some of them: you may not know which ones or when, but you're giving them footholds in approaching the problem.