[Nadya]

You completely misunderstood who was needing the fix. In this case, it was the person who spent time fixing it. They likely fixed it because they need the fix.

Doesn't matter if the entire module becomes deprecated. They'll stay back with their fix (likely). Doesn't matter if another solution is inbound, they needed the fix now and not when a patch lands.

And since they already took the time to fix it - little time is lost sending a PR, regardless if it gets merged or not. If it is merged? Sweet you helped the project out (most likely). If not? Well a small bummer that you'll need to maintain your own patch(es).

[dismantlethesun]

Actually, sometimes people push changes because they intellectually think it's a better architecture or public API, but they can't survive as a fork.

They need the frequent bug fixes and upgrades from the mainline, so they really do waste their time if their changest is not approved.

[greglindahl]

This is an odd way of thinking about it. As a user of software, I like fixing it for my needs but I'd rather make the change in a way that the maintainer will accept, so that I don't have to maintain my patch. That means I'll tend to open an issue first, explain that I'm willing to submit a PR, and see if the maintainer wants to give me guidance.

[rpedela]

I think it depends a lot on context. If I am looking to contribute for the sole purpose of improving the OSS project, then I follow your method. If I am using an OSS project in a larger commercial project and I need a bugfix or feature now, I just build it. If I think it may be useful to the OSS project, then I will contribute back with the understanding that it may not be merged.