Comment by necovek
14 hours ago
You'd be surprised to learn this about free and open source software, but if a maintainer is unavailable, you have both full rights and full source code to... wait for it... fix it yourself (or pay someone to)!
There is something unhealthy in this relationship only if you project "no warranty" into unrealistic expectations.
This is true for the majority of open-source projects, but the most serious ones, on which a lot of software/businesses/infrastructure depends, are controlled by foundations or some kind of other management entity.
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.
You don't really though. Sure you can fork it and fix your issue, but then what? Are you going to maintain your fork in perpetuity? Are you going to patch all the software that depends on the code you fixed to use your version instead of upstream? Are you going to get your users to do that too?
In most cases this is extremely impractical.
> but then what?
Then you send the patch upstream, they incorporate and maintain it for you. Congratulations, you just FOSSed.
> Then you send the patch upstream, they incorporate and maintain it for you
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)...
3 replies →
We are talking about a case when maintainer is unavailable to do the work: what would happen if this was a proprietary dependency and the maintainer is gone (eg. bankrupt, moved on, incapacitated...)?
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.
Yes, you can maintain your fork for perpetuity if you can't/will not get your changes upstream. Why is that a problem?
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.
> Why is that a problem?
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.
1 reply →