Plus, the pool of people who have time to spare and want to do something is different then pool of people who have scratches all around the projects.
Plus, the pool of people who have time to spare and want to do something is different then pool of people who have scratches all around the projects.
Which isn't to say it's impossible, of course -- people getting new jobs working on proprietary software have to get up to speed with programs they probably never used before. It's just time consuming. The "what should I work on?" question implies that the asker has no preference, so answers optimising for what's easier to get started with make sense.
If you don't use it how do you know you're solving actual user problems?
I used to contribute to an OSS project and there were a lot of times where the devs and users had differing opinions on how a feature should work.
There are many (many) ways to contribute to a project that doesn't require you to be solving actual user problems.
I'd suggest just finding new projects, review code, create pull requests for those small mistakes you see. Provide feedback if applicable. Etc.
You can fix uncontroversial bug/feature request from issue tracker. Not everything us contested, most of it is not. Also, I would expect the project to welcome someone doing the work more then just another one that came to argue .