There is something unhealthy in this relationship only if you project "no warranty" into unrealistic expectations.
cURL also offers paid support and also paid access to the rock-solid (LTS) version, with guaranteed response times, and the blog post states that there's still people to respond to these.
In most cases this is extremely impractical.
Then you send the patch upstream, they incorporate and maintain it for you. Congratulations, you just FOSSed.
Firing patches upstream is still adding burden to the (likely already over-burdened) maintainers.
In an ideal world, if you want a patch upstreamed, you would be contributing to upstream maintenance (or at least donating to the upstream maintainers)...
There is nothing unusual about this, businesses face this all the time, the only difference is that you do have some agency with FOSS.
What's the alternative when it is not FOSS? Eg. build it yourself from scratch (and maintain it too), or move to a competing product.
If you're using any complicated FOSS professionally and you have SLA with your customers to say fix issues within day or two you don't have a choice anyway.
Because it's a ton of unnecessary work. And because of the other reasons I said.
> If you're using any complicated FOSS professionally and you have SLA with your customers to say fix issues within day or two you don't have a choice anyway.
This is true. I always try to upstream patches anyway though.
You are already benefiting from getting the tool/library/system for free, so you can still compare writing the thing you need (necessary?) from scratch or adapting the FOSS solution — maintenance comes with both options.
When you invest enough and are lucky, someone else might just fix the thing for you or pick it up and maintain it for you — but do not count on it, and you are good.