I'd be happy to pay for their ibuprofen if they can prove the adverse effect my comment had, and if it continues having adverse effects, I'll make sure to take my comment down or improve its quality so as to stop causing the adverse effect.

Publishing information has both externalized benefits and externalized costs, and we don't have a good way of internalizing the benefits or the costs, but if you only internalize the costs you're surely going to deter things that were net positive.

It's also assuming that the unrecoverable positive externalities correlate with the deterrent. But because they're unrecoverable, they wouldn't -- something with an enormous net benefit can be deterred by a small cost because the benefit was going to someone other than who pays the cost.

That's a good question that I don't have a good answer to. I would encourage people to strive less towards publishing what they want to be "production ready" OSS, and direct the efforts more towards building smaller building blocks with clear indication it's not to be used in production and extensive documentation on what work needs to be done to productionize the software for given applications. These are just my immediate half-baked thoughts on that question. I had not considered that there might be a demand for medium quality software.

> Publishing information has both externalized benefits and externalized costs, and we don't have a good way of internalizing the benefits or the costs

That is an incredibly well formulated point. This raises some interesting thoughts that I'll need to mull over.

> if you only internalize the costs you're surely going to deter things that were net positive

I think that's fine, right? Unless you are demonstrably deterring a ridiculously outsized net positive, that's just the unfortunate cost of risk management.

This is the opposite of how it usually works, and there is a reason for that.

Having something that actually runs is when you start building a community. The crashy pile of garbage that only works 80% of the time will get people interested, because it does work 80% of the time, as opposed to 0% of the time for the most well-tested and documented component that can't be used for anything because the rest of the system hasn't been built yet.

The early adopters knowingly put up with the flaws because the alternative is to wait until it's finished, and they choose not to. And then they make contributions and make it better, which is the only way it ever gets finished.

For the same reason there is no clean demarcation between "in development" and "production ready" -- people will be using the "in development" version in production as soon as it suits them regardless of what you tell them. And the people who do that knowingly do everyone else a favor by polishing the rough edges. The better the code gets, the more people use it, the more contributors you have making it better. It's not a line, it's a spectrum.

> I think that's fine, right? Unless you are demonstrably deterring a ridiculously outsized net positive, that's just the unfortunate cost of risk management.

That's exactly what happens with software, because the externalized benefits have unlimited scale. It's a serious problem even before this -- there are many open source projects with only one full-time maintainer, or only a part-time maintainer, that are used on a billion devices by everybody in the world.

But that is not what this regulation would have you do. It would require you to actively monitor your HN comments for adverse effects and proactively publish up-to-date fixes and disclaimers on how to avoid those negative outcomes. The affected parties don't need to prove harm, they only need to prove that you failed in your support/maintenance duty.

Don't blame me for not building the house to code, blame the guy who made my nails, fasteners, and lumber.

^this is what you're endorsing, because any failures generally occur at the stage wherein the End User is adapting the component to integrate into their own systems.

Responsibility falls on the composer of a system to deal with the composition's quirks. Anything that tries to put it up a layer is just trying to pass the buck. The Software Author has a particular case in mind. Yours is probably not it, but might become so. If it fits, go ahead and ship, if not, smooth it out. Nothing is stopping you but your unwillingness to wrangle the code.

I'll blame you for using poor quality nails, fasteners and lumber.

> If you make something publicly available for use, you should be liable for maintaining it and any damages that software causes due to bugs.

Also lets be very clear here - software bugs aren't really capable of causing damage by themselves. If I set up a lone machine running a decades old Swiss cheese Linux distribution on a publicly accessible IP, the absolute worst that can happen is its bandwidth being used to create denials of service. It's those who create real-world reliance on inadequate software systems that deserve most of the blame for damages.

No modification whatsoever is intended to have to happen to integrate that particular package with the rest of a person's house. This is completely different to how most software works, whereby dynamically linked libraries actual implementations of particular symbols can be changed out from under the user at any time. Therefore, legally speaking the demarcation of liability is far simpler to demonstrate/self-evident.

>Or electric one that have live connected to case...

Governed by electrical code.

>Surely the user is responsible not the manufacturer?

Technically yes, the user is ultimately responsible for final detection of, and escalation of the defect. If you don't engage the legal process around a defective, non compliant appliance, nothing happens/changes to fix it. The rest is implementation detail.

This is insulting beyond words. We think together with open source. Ideas are shared. The world iterates forward & we learn & improve, together. Saying we cannot open our mouths unless we have only the voices of the angels is a demonic silencing. Hard disagree.

If you're not certain and unwilling to fight false claims, just don't publish it for public use. It's kind of that simple.

> We think together with open source. Ideas are shared. The world iterates forward & we learn & improve, together

Indeed. And we have, and continue to produce plenty of resources for that.

> This is insulting beyond words

My sincere apologies that I insulted you by stating you shouldn't be allowed to hand out home-made fire extinguishers to the public and expect no repercussions

Developers of greatest talent are experts at finding doubts and potential weaknesses. They see accrued depth of complexity far beyond what the minds of simpler beings floating only on the surface of interface see. They can imagine all kinds of complex interactions. And they are never certain. That doubt is a doubt they work against, guard against ad best they can, but live with.

It feels like such a ridiculous silly alien voice, such absurd naivety, to say, oh, just be certain. Just make it flawless. Whatever happens, it must be perfect. It's a juvenile fantasy, that only one ignorant to the complex nature of reality, unthinking of the combinatorial explosions of possibilities that happen as layers of systems & libraries intersect, unseeing of the absurd misuse by users of technology, that any and all difficulties could be conquered by just demanding someone making something make it perfect or never ever share it with the world, never allow users.

I am not advocating that it should be illegal to publish OSS unless you can mathematically prove it is faultless. I am advocating that if you are going to publish software for public consumption you better be damn sure it wont cause harm, because you will be (should be) accountable for any harm caused.

Yes you should be able to say "don't use this", "for education purposes only", "this is a demonstration", etc.

It'd be the same result as California's law leading to 'this may cause cancer' printed on so many items no one even cares any more.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Noone's going to force you to provide guarantees for goods you did not produce.

I never said anything about software I didn’t produce, should I interpret this as you agreeing that you will force me to provide guarantees for open source software I do make?

Yes. However, the way you use the term "force me", at least to me, implies an unjust enforcement of a law, post-publishing that was not made clear pre-publishing.

The idea that software engineers can 'guarantee' against this is fantasy and precisely what integration testing is for. It has to be the case that those who deploy the code take responsibility for its behavior, not the original authors, since only those deploying have the full picture of the system.

Legislation like this is missing the real problem. Reminds me of when legislators tried to redefine Pi to be exactly 3.