Remix.run Logo
laszlojamf 12 hours ago

as much as I feel for the maintainers here, this sort of (again) puts the spotlight on our collective dependence on a handful of individuals basically working for free _with no backup_. Most normal organizations stagger vacations to avoid these things. Most normal organizations _have_ to do this, because their customers require it. Here, we're all customers of curl, but not really. It's a weird, IMO unhealthy, twilight zone that isn't good for anybody. And it surprises - and saddens - me that not even friggin curl has the financial muscles to have somebody on-call for one month...

necovek 12 hours ago | parent | next [-]

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

ed_elliott_asc 12 hours ago | parent | prev | next [-]

They do, he said at the end if you have a support contract then they will respond and deal with security issues.

I guess the whole point of the article is to show that people should buy a support contract if they need support.

Nnnes 12 hours ago | parent | prev | next [-]

They do.

> Everyone with a paid support contracts will of course still get full and appropriate service even during this period.

4ndrewl 12 hours ago | parent | prev | next [-]

It does. The article clearly says that if you have a paid support contract they will be on-call as per usual.

simjnd 10 hours ago | parent | prev | next [-]

And I'm assuming you're not going to pay for them to have that someone on-call, even though you're worried about this scenario

bawolff 11 hours ago | parent | prev | next [-]

> And it surprises - and saddens - me that not even friggin curl has the financial muscles to have somebody on-call for one month...

Is it that they can't or don't want to. I'm sure curl is popular enough that it could attract a co-maintainer if it wanted to. Of course there is a cost to that. Software projects done effectively by a single person are often more focused and designed more coherently. I'm not sure curl would be as good a product if there were multiple maintainers with potentially conflicting visions.

12 hours ago | parent | prev | next [-]
[deleted]
simooooo 11 hours ago | parent | prev | next [-]

I wonder how far we are from the agents just maintaining the packages

inigyou 6 hours ago | parent [-]

We have some packages like that, starting with rsync which distributions are having to roll back because it turned into a pile of garbage overnight.

eviks 10 hours ago | parent | prev | next [-]

Consumers, not customers

andylynch 11 hours ago | parent | prev | next [-]

They do. You just seem to expect that it will somehow be free.

serial_dev 7 hours ago | parent | prev | next [-]

Reminder: ‘the software is provided “as is”…’.

It’s not their problem that you, or anybody else, think you are owed 24/7/365 emergency support.

Imustaskforhelp 12 hours ago | parent | prev [-]

The thing which bugs me is that OpenAI (which is an unprofitable company) is spending around what 100k$ per month for an completely AI generated slop called Openclaw. (All because of Hype)

I have seen there to be an more influx of open source software as people are starting to create more software with vibe-coding and other things and just open-sourcing it, which while good in OSS'ing it but its mostly less valuable as compared to the curl codebase which was created by hand and over the years improved itself.

Yet the funding is going towards making more and more (OSS/non-OSS) AI slop by people, companies and dare I say countries yet we are unable to take the same wealth and money into, say, the curl project (and the likes)

There is also an visibility issue. We all know curl and this is the state of curl. Imagine all the projects which we all don't know that much about or aware about going through same issues.

l23k4 11 hours ago | parent [-]

>The thing which bugs me is that OpenAI (which is an unprofitable company) is spending around what 100k$ per month for an completely AI generated slop called Openclaw. (All because of Hype)

For whatever reason, real people seem to desperately want Openclaw regardless of it being AI generated slop.

OpenAI is certainly not wasting the money they're spending on Openclaw, even if I personally wouldn't want to touch that particular piece of software.

Imustaskforhelp 10 hours ago | parent [-]

> For whatever reason, real people seem to desperately want Openclaw regardless of it being AI generated slop.

I can agree with it but I am unsure how much the desperation is out of FOMO or out of real use-cases.

Surely curl has more use-cases and projects relying on it than OpenClaw.

The demand seems to be generated out of hype rather than sustainability. Openclaw project isn't even an year old and from my time hearing about it, it isn't safe or sustainable in any fashion and it seems that the hype around Openclaw has now started to slow down as I hear less about it (which to me is actually a good thing imo) but it shows what the market reality of these tools currently are (at the moment).

l23k4 9 hours ago | parent [-]

>I can agree with it but I am unsure how much the desperation is out of FOMO or out of real use-cases.

I frequently run into people using it, they seem happy with it. I remain highly skeptical about this being a good idea, but I'm quite convinced that many people genuinely really like it and find it useful.

Imustaskforhelp 9 hours ago | parent [-]

> I frequently run into people using it, they seem happy with it. I remain highly skeptical about this being a good idea, but I'm quite convinced that many people genuinely really like it and find it useful.

That can be the case and good for them, at the very least its open source software that they are using and it raises more awareness about them.

But I think that we have strayed a bit afar from my main premise that I think we both agree on that although the value of an project is always subjective and its up to the companies on how they direct the funds to. It's Okay for OpenAI to sponsor Openclaw if they absolutely want to.

But the question is if its entirely reasonable as to a project like Curl getting less funding overall, simply because everyone is using curl underneath but the tech is boring (as I think it should be), but this makes everyone think that curl is well-funded when it isn't.

I think that its a reasonable decision for a company to give a very small chunk if it has massive profits to curl to sponsor the project to be more sustainable, but I am not the one at the decision-making involved in that said company, so I don't know what is the rationale behind blocking or not sponsoring Curl.

Is the rationale that they can get away with not sponsoring curl in the first place and use it with its permissive licenses in its code so why invest/donate the money in first place, but this practise doesn't seem sustainable to me!?

l23k4 7 hours ago | parent [-]

>But the question is if its entirely reasonable as to a project like Curl getting less funding overall, simply because everyone is using curl underneath but the tech is boring (as I think it should be), but this makes everyone think that curl is well-funded when it isn't.

I think the returns fall off really really quickly when you increase investment in a boring, mature project like this.

It might be nice if people sponsored curl more, but the software isn't going to significantly improve because of it.