Mistakes happen, texts go out of date, and topic foci change. OER are uniquely positioned to react to issues such as these. As the saying goes, With Many Eyeballs, All Bugs Are Shallow. One of the key differentiators among OER and open source projects is how well they deal with these many eyes.
High quality projects will have a deliberate process to develop and support an active constituency. This user community will fulfill at least two important roles, feedback and advocacy. Interestingly, feedback and advocacy are essential to both the user community and the OER provider, they just view them through slightly different lenses.
There is a lot to talk about here because issues, in developer speak, includes enhancements.
Once you find a resource that fits with your class, or is at least represents a step in the right direction. Start thinking about becoming part of the community, contributing to the ecosystem. Especially in the beginning, it could be something as simple as a comment on improving the product to better meet your needs.
The OER provider should welcome your feedback, and let you know how it will be incorporated into their process. You don't know if your suggestion will be adopted. For example if only a few ask for one feature, but many ask for a different feature, the feature that will effect the wider audience is more likely to be adopted. However, if you don't contribute, then you know your desires will be unknown and probably unmet.
From the provider point of view, this feedback is important. It is a significant contributor to understanding the product market fit, that is understanding how large the market is, and how well the product fits the needs of that market. It's not that other products don't pay attention to this feedback, but open source projects are unlikely to have large budgets for advertising and marketing and will naturally focus more on organic feedback.