4 ms·

> What if you still want the medium quality comments? That's a good question that I don't have a good answer to. I would encourage people to strive less toward

by lijok 3y ago

> What if you still want the medium quality comments? 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.

AnthonyMouse 3y ago
> 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.

by lijok 3y ago

AnthonyMouse 3y ago

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