Start developing or contributing to the project does not mean you need to know how the whole system works. If there is a problem you can digg into it and try to fix it. To do that it is NOT necessary to code a single line, simply find out what is going wrong, check the service config files, try to manually fix it, test it and open a bug report with a detailed description what is going wrong and how to fix it. The code to finally fix that can be done by someone else with deeper knowledge.
It's clear that this kind of help is currently possible, not denying that. But there's really a lot of place for improvements, mostly in the part about actually fixing (or implementing) things. The problem in this project is with the so called "someones with deeper knowledge". There's not a lot of them, and that seems to be a big bottleneck. And it's not only about the base project itself, it also applies to the plugins, which as we know, need a solid interface coming from the base project. If the project is supposed to be extensible via plugins, but making plugins is not easy, then we end up in a situation like we have now, where plugins are barely kept alive. There's a lot going on with the proposed dockerized solutions, which I personally really like and I'm fine with, but even with that I still think there's a lot of place for plugins (even if they would be used as simplistic frontends for dockerized services).
But do you know how often this happens? ZERO times. No help from the community. Nothing. Only complaining that feature x or y is not working.
Well, in the next post you've pointed yourself to a community provided PR, so that's clearly not true. But I get what you are trying to say - that these sort of contributions are really rare, which after all this time must be a huge disappointment. However, don't forget that there's always the other side of the coin. Your point of view, your view on the code, its state and its documentation is from a perspective of the original author. It's obvious that for you it's all well (or good enough) written, everything is clear and shiny. But that's not necessarily the case from the point of view of an "outside" developer such as myself, a new commer who maybe wants to get to know the project better, try to improve it. However, when I saw the sad state of this community, I was really disappointed myself and simply backed out of any development in the plugins that I wanted to improve. And just before anyone accuses me of being an ungrateful bastard (looks like someone already said that, just not explicitly...), I really do appreciate all the fine work everyone has done so far, but my dev experience so far was not that great and simply made me rethink my further contributions and even further usage of OMV (because I'm not 100% sure if I should trust it to keep my data, if the development process is not stable itself; I know that a lot of people have only the positive opinions, which is great, but the developer inside me does not let me ignore the mentioned secondary flaws). OMV 5 and some of the rumors have brought back my hope, but I'll see how it goes...
But I digress, back to the topic. It's pointless to constantly reminding everyone that it's "just about reading the code", because it's not. This is a big project, with a lot of technologies involved (frontend, backend, OS-level configuration, that's quite a lot), with a quite complex, somewhat outdated architecture and old libraries. There's a lot of indirections going on, a lot of things people might simply not understand from the get go. And don't forget, that same as you, every outside contribution is also made in the spare time of any constributor, so it seems crucial to not waste that time on long analysis, and instead get to work as quickly as possible. And before anyone says that documenting things might also be a waste of time, just consider that there's also a chance that this "waste of time" might possible bring new developers which will in turn use their time to make up for the previous loss. It's not a guarantee, but in my opinion it's worth the risk.
It's definitely possible to track down all of the complexities and finally have the bigger picture, but it would be so much easier if it was already written down somewhere in a concise way. Then, once the initial "get to know each other" is done, the argument about "just reading the code" makes more sense, because one can then infer a lot by comparing it to something they've already seen before.
As with a regular job, it's usually good to introduce the new coworker by sitting with them and explaining the key concepts of the job they are supposed to do. This usually lets them to get up to speed more quickly, be more productive within a few days, rather than weeks. And isn't that what what you would like as well? More developers who quickly catch up and can do something in the code? This obviously is not just a "regular job", so it's harder to onboard new contributors, but it's definitely not impossible.
To sum up my thoughts - I get that what I just said is a ton of work and is not that simple, but doing nothing about it is the reason why OMV and more importantly, its ecosystem, is not as good as it once was. I guess this is still a fine product, not implying that it will fall apart or anything like that... But it's not very appealing to new developers, hence the lack of contributions and the stagnation of plugins. And no, I'm not writing this to pick up a fight or personally annoy anyone. I'm writing this from a perspective of the said new comment, trying to present my point of view.
I'm not saying that everyone will immediatelly stop being jerks about bug fixes, I'm not saying that there will be a surge of new developers joining the community, it all might be just a big ball of cliche ideas, but from my perspective it seemed like a lot of people involved live in denial about the situation. This might be an open source project, no guarantees, no obligations to support anything... but the existence of project's momentum reflecting on the community and the users cannot be denied, and should be taken into consideration.