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.

▲

ValdikSS 11 hours ago | parent | next [-]

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.

▲

IshKebab 11 hours ago | parent | prev [-]

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.

▲

spiffyk 10 hours ago | parent | next [-]

> but then what?

Then you send the patch upstream, they incorporate and maintain it for you. Congratulations, you just FOSSed.

▲

swiftcoder 8 hours ago | parent [-]

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

▲

necovek 3 hours ago | parent | next [-]

I believe both are valid: sometimes upstreams are not set up for donations, and sometimes your org will make it easier to submit a patch or to financially sponsor a maintainer.

▲

spiffyk 7 hours ago | parent | prev [-]

Fair, but it is less of a burden than just submitting a report with no proposed fix. Also, submitting quality patches regularly seems to be a good way to eventually become a maintainer, provided that both sides are interested (cURL generally is – at least that seemed to be the vibe at the last year's cURL Up event I attended).

	▲	3 hours ago \| parent [-]
		[deleted]

▲

necovek 3 hours ago | parent | prev | next [-]

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.

▲

megous 5 hours ago | parent | prev [-]

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.

▲

IshKebab 3 hours ago | parent [-]

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

	▲	necovek 3 hours ago \| parent [-]
		How do you define unnecessary work if this is... necessary for you? 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.