Re:European Legislation Could Create Liability for Free-Soft...
by AnthonyMouse on Saturday September 30, 2023 @06:51PM
(#37720715)
> 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.
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.
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.