Merging that PR can take a lot of time for testing, and also risks locking in some feature into the project, which the maintainer does not need or use, but they're now stuck supporting (owning) from here on.

Typical conversation:

- contributor: I need feature X for my big client, it's super important, please support it.

- maintainer: interesting, I'm not familiar, but I'll take a few hours to review. Can you help maintaining it? write tests? help fix other bugs?

- contributor: no. corporate does not allow me to. I am too busy, have other paid projects to work on, why would I do things for free?

Don't get me wrong, everything I do is FOSS, but it's easy to be brunt as a maintainer.

Why do maintainers owe you support? I assume by your comment that you're a company, in that case, since you're making money off the value added by that OSS project, financially support the developers to get support in return. Then you can act entitled :)

I often have to use open source projects in my work (Backend Software Engineer), there are projects that are popular, many of them backed by companies themselves and there are small one-person projects.

As an engineer/developer, you may have an issue with one of these libraries, tools, etc and you'll put in a ticket with all of the details your development expertise can coax out; sometimes you'll get responses of thanks for a clear report, sometimes you'll be ignored, and other times they'll disagree or be unwilling, and now you're stuck.

You'll go to management and ask if they'll pay said company/developer to fix it and they might, or they might not.

You either look for an alternative, write something yourself, or you fork it internally, fix the issue and move on; now you and your peers have another piece of code to maintain because nobody on either side of you would budge.

I've never been abusive to an OSS developer, I've certainly been frustrated, and I'm an FLOSS advocate myself.

Some projects I've worked with, and I won't name names, have turned around fixes in literally an hour, are greatful for a good thorough report and want their software to work for you (and I'm talking large internationally used enterprise grade tools), and others will just be rude or dismissive, but you still have to solve that problem, it's your job.

When I have a job to do I'll just move on from projects that make it harder, and I'll advocate harder for the projects that make it easier, if it's small and generally unmaintained, we'll just fork internally, improve 8t all we want and move on, now nobody in the wider community benefits.

There are other projects that are larger, and we pay them decent recurring sums to be able to ask for a fix or feature to be turned around quick, and it'll end up in their open source code, so everyone benefits from that money this company spent.

When you're a small start-up developer you have far fewer options available to you compared to a large company who can or will throw money at people inside and out to get things done.

>if it's small and generally unmaintained, we'll just fork internally, improve 8t all we want and move on, now nobody in the wider community benefits.

Everyone can still benefit, just make your private fork a public one. Of course you now have the same problem as the original maintainer in that people will make requests of you or fork it

Maintainers do owe fixing bugs to some extent. Otherwise they are not maintainers in the first place. It is also the nice thing to do.

If some project does not fix bugs handed on a silver plate it is good to warn others against using it. I.e. self-entitled whining.

They owe you nothing. They are posting code, not a promise to work for free for you forever.

Exactly, they're just posting code, but, simultaneously, if they put it in the public domain, they probably expect that the code will be used by others and from that moment, well, they are at least responsible for replying to PRs or close the ones they don't care about merging.

Once it's public and gains "customers" the responsibility grows a bit, otherwise don't post it at all publicly, after all, if you're not going to care about real world use cases, it's just as valuable as any toy project that hasn't seen the light of day.

This type of almost "passive gatekeeping" is the reason why we've formed several OSS projects we rely on. Yes, we incur maintenance burden but the predictibility gained is Invaluable.

I dunno, I’ve recently made significant contributions to both sonarqube and openreplay, both backed by a company, and both were accepted.

Of course both start out as forks since we need the change now, but that doesn’t mean we can’t contribute it back.

A project being backed by a major company like Google is no guarantee of a well run project. For one project by Microsoft employees on GitHub, they don't appear to even read issues or trivial PRs.