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.