[oblio]

Ah, that one, too. Sometimes even if you're:

A. A developer

B. That is familiar with the software stack used by the application

C. Has enough time and energy to investigate the root cause of the bug or a proper design for the feature

D. Has enough time and energy to design the fix/feature, implement it properly, write tests, jump through all the hoops

E. Send the pull request

... sometimes the PR still languishes for years or the nightmare scenario, is discarded during a big rewrite that doesn't actually cover this requirement...

So even the code being out there isn't a silver bullet.

[raincole]

Sometimes people really do that. There is a "UI reskinned" Blender fork called Bforartists.

Whether it's a good idea is debatable.

[The_Colonel]

Sending a PR is the easier part of development, the real work is maintaing that code over the years / decades.

Connected to this is the fact that many PRs are kind of misaligned with the project vision, that's at least the main reason I'm rejecting PRs.

[wizhi]

Then don't just send a PR: maintain your own fork.

I think that's the bigger part of open source. You can fork it, change it to your needs, and not give a damn what anyone else thinks about your changes.

[oblio]

Oh, that other open source trope, I should publish a book.

Because maintaining an entire fork of any non trivial software is... trivial :-)

Let's just admit that these are complex problems and frankly after watching the hype for almost 20 years, open source proved to be an alternative and a good refuge for many things but on the end user side the early hype until 2008 or so was 80% wrong.

[wizhi]

If you truly believe it to be trivial, you should just do it rather than complain.

If you don't, then you can't justify putting more work onto the maintainers of upstream for changes they may not even care about.