I've noticed the same. For example, for Rust embedded Hardware Abstraction Libraries, I had to abandon the existing ones and start a new one: The existing ones

I've noticed the same. For example, for Rust embedded Hardware Abstraction Libraries, I had to abandon the existing ones and start a new one: The existing ones were missing features, had bugs etc. I initially attempted to fix them with PRs, but couldn't get anything merged due to complaints such as those in the article! It's as if the maintainers would rather have a sparse debate over the course of months trying to get things perfect than fix the problem or add the feature. If you don't like the code style of the PR, just do the fix yourself. It would be a lot easier than arguing! It was easier to start fresh than get PRs merged. This happened even for clean kill bug fixes. For my own projects, my bar for merging is "Does this improve the project". If there's a code style issue I don't like, I'll merge, then make the change myself after. If it's an idea I don't like, or determine is out of scope, I'll state clearly that I have no intent to merge it. Sometimes these are an issue of available maintainer time. Eg, the maintainer may be busy, and doesn't want to dedicate time to a project. So, you end up in code-style debates, where response take weeks etc. It's mismatched expectations between maintainers and users. Or if the maintainer doesn't have time to test or evaluate a change in all cases, a conservative call is to not take the risk of unforseen consequences. Overall: I also agree with the points others here make about the owner-maintenance burden of PRs, no obligation to merge code you don't agree with, validity of safety concerns etc. It means you need to treat these on a case-by-case basis. In the case I outlined above, it would have been preferable not to fragment the embedded Rust OSS community by introducing a fresh HAL, but I had to to meet project requirements.