Hacker News Reader

> A developer can absolutely make an agreement in which he takes on the liability. He's going to need to be paid to take that liability on, to both spend the time to eliminate defects, but also to purchase insurance so that he isn't bankrupted when a defect inevitably gets through and causes harm.

Hmm... I hadn't though about the implications of this before. Is this a solution to the mythical funding balance the industry is failing to achieve? Enterprise software already operates like this. What if e.g. github reframed its project sponsorship model as something that involved getting maintainers setup with liability insurance and the ability to offer sponsors warranty and liability for their software.

My concern with the rust ecosystem right now is that it goes the way of node and projects just get littered with endless libraries that were fresh and hot at one point in time. Often times you open issues and it takes days or weeks to get a response if at all because the maintainers have moved on.

I'd be super interested in only using dependencies where I could subscribe to liability and warranty service after I've tried them out and they're want I'm going to roll with. And you would even potentially see interesting things like "pure" chains where all software used is covered by somebody.

This model would also have the interesting effect of promoting software design and language selection that results in "easier to warrant" not just "does the job" and maintainers that do a better job at writing good software would bubble to the top since their liability insurance premiums would stay cheap. If you write too much crappy software, at some point it becomes unaffordable and you go work for Facebook (it's a joke! you get the point).

> What if e.g. github reframed its project sponsorship model as something that involved getting maintainers setup with liability insurance and the ability to offer sponsors warranty and liability for their software.

I think it would be much more expensive. The developers of some library are having a hard time judging how much money somebody stakes on that library working perfectly. It might be that they'd lose an hour of work if they hit a bug, it might also be that a huge project fails with gigantic losses - it's hard to insure against that if you still want people to be able to afford it.

It's much easier to buy insurance on the user side where you know the potential impact (i.e. "my wordpress site will be offline for a day" vs "the oil rig I've run calculations for could sink if there was a bug").

Scaling the payment with the importance of the software is already how enterprise software largely works. Often times customers actively want to pay more for software so they can secure more attention from the vendor, if the software is critical to their business.

It's not only about a legit project failing with gigantic losses. A blanket liability insurance would also raise hordes of liability insurance trolls. I.e. organized efforts to collect insurance payments by claiming damage caused by the use of the software.

This just sounds like any mature industry.

> Is this a solution to the mythical funding balance the industry is failing to achieve?

For single projects this is definitely possible, at least theoretically. But I can't imagine it working for large ecosystems.

Who even wants this? No one wants this.

The ones who want this already have it through SLAs and the remainder can't afford it.

Indeed. Nothing would kill free software (and modern development in general!) quicker than mandatory liability.

Package registries would shut down overnight.

Probably the reason the author supports it.

yes. and to add to this, the fitness for use in some safety critical system, and we talk about functional safety here, is strictly regulated. functional safety requires process discipline at the system level, evidence based engineering and evidences for soundness of scrutiny, at the system level and then down to the components.

in that light it is a moral obligation to remind consumers of the technology about their obligations. The legalese may sound just evasive, and motivated by the us environment of litigations by stupid people, but seriously: fitness for use is am obligation of the systems engineer, not the provider of FOSS.

elisa.tech is a community to enable Linux in safety applications. even there, the responsibility is with the consumer of their work, they also just seek methods and inputs for system safety engineering, which, when used by a system safety engineer may lead to a certifiable, and then liability covered device. like an adas system powered by Linux.

> the responsibility is with the consumer of their work

This would also apply to the problem of web search and social network monopolies. The way I see it: let Google and FB develop or host a plurality of ranking, filtering and UI variants, and let the users decide their preferred flavor. Then they can't complain about bias. There would be a Republican Google and a Democrat Google and a EFF Google and a BLM Google to pick from. They are now like single TV channels with unified editorial stance, they should be more like cable networks. Give people the remote for content ranking, filtering and UI.

my google search results should be different from yours already, no? likewise our FB streams...

and you choose your profile not via drop down but with your engagement with and liking and disliking of content?

That's the craziest bit of the whole article.