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
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.
