My attitude towards complaints about open source projects is that if you think the errors are rudimentary then just submit some patches. If there is not enough test coverage then add one. This applies especially if you believe that the project is critically important.
I think what might be happening here is expert syndrome. People may be told that if they're not experts then they shouldn't be reviewing or changing the code.
Even if you work on a commercial project, where there is a reasonably stable core team, people just committing stuff, even if it's in itself pretty good stuff, won't result in good overall code quality. You need to have a systematic process, including a detailed coding standard, requirements about test and documentation coverage for submitted code, precise guidelines for contributing, rules of code review, and you need people who understand the whole project, review pretty much all of the code changes, have an overall development schedule in mind including refactorings and technical improvements, and all the time putting work into maintaining overall integrity of the project:
This is pretty much a must for any project where there is more than one person working, and the more people contributing or the more mission-critical the project the more of this kind of high-level coordination is required. Some open source projects with strong leadership do get to this kind of integrity, but most don't. It's easier when there is a relatively small team of very dedicated individuals, but some large projects have succeeded to some extent in building a real development culture in an open source setting, like Linux.
back in 2010, my business partner, marco peereboom, submitted a patch to openssl to add support for aes-xts. it was coded by joel sing, now a google employee and golang dev. they _didn't even respond to the mailing list email_ and after marco nagged for a reply the response was "we have a different plan for how to implement XTS" (i'm paraphrasing). _2 years later_, they added XTS support.
the openssl dev team is not responsive, doesn't accept contributions and generally speaking suffers from "you're not an expert" syndrome. look how expertly they've managed their project!
A while back, I tried submitting a patch to OpenSSL. It was a 3-line change (IIRC) related to the build process - in a particular esoteric setup, the build failed. Got literally zero replies regarding the issue on the mailing list, their IRC channel and on my/their github pull request.
I'd love to contribute more often to other OSS projects. But this behavior is more common than not.
I've also submitted patches to OpenSSL and been entirely ignored[1]. The latest of which strictly improved testing, documentation and included a detailed study and write-up of actual bugs in OpenSSL and downstream code[2].
My conclusion was that the OpenSSL project is not interested in external contributions.
This has not been my experience. I've contributed to many different projects, large and small (chpasswd, sendmail, apache, git, gerrit, openconnect, homebrew, msmtp, textmate, ...) and never had trouble getting a patch accepted.
Those projects don't suck, though. When projects (continue to) suck, it's usually because their maintainers suck. When maintainers suck, it's hard to get patches in.
The failure mode with this approach is that it disallows coaching.
There may be some bug in a library that's similar to what I do for my day job, and I spot it immediately. Or perhaps I've seen the inevitable results of certain design decisions play out in multiple organizations.
I may not have time to code up a patch. Frankly, I've got about 5 projects on the go besides work and kids.
So, FOSS projects may lose out on that kind of expertise that could easily be crowd-sourced if it didn't ask so much of contributors.
Well, I can code myself out of a hole I have coded myself into. But I guess the world is a better place because I don't try to help crypto projects by contributing.
I think what might be happening here is expert syndrome. People may be told that if they're not experts then they shouldn't be reviewing or changing the code.