I'm the creator of Jenkins.

Without fully knowing the context, I wonder if this is just a simple disconnect.

In Jenkins, we collectively cover wide-ranging use cases not by making one existing plugin (say Git plugin) do everything, but by making it extensible so that other people can define additional semantics and behaviours as separate plugins on top of it.

We learned this in the early days of Subversion plugin, back when that was the most popular version control system. Everyone uses a generic tool like that very differently, so as we kept adding individually valid use cases to the Subversion plugin, it became this giant hair ball not just for devs but also for users.

This mode also works better for those who do not want to spend time explaining why their use case is a good/important one, as they can simply code up their idea as a separate plugin and move on.

With all that said, I'm sorry for the frustration you had. Do you still have some pointers to tickets/PRs, etc? I'd like to look into it.

Yeah - it is a "problem"[0] with open source - you need to deal with people that may have completely objectives to you.

It is easier with a closed source / paid service to ask for feature requests. Remember that the maintainers probably get hundreds of similar requests a week, and have merged things in the past that they didn't like and later caused issues.

This causes confirmation bias for them "The last time we allowed code not aligned to codeing styles / test requirements / feature direction / $reason it all went badly", so it is easier to ask for things to align to their world view before merging it.

Being a maintainer is hard - you are damned if you do, and damned if you don't. People give out about not merging code, but they also give out if the code that does get merged breaks things. Finding a balance is hard.

0 - I don't personally think it is a problem, but it potentially requires a bigger time investment, and can be infuriating when you have a small change that really scratches an itch for you.