Food is not really that similar to software. Food going bad is a universal problem of food, we should optimize our handling of food (and write all our laws) un

Food is not really that similar to software. Food going bad is a universal problem of food, we should optimize our handling of food (and write all our laws) under the assumption that it is always in the process of going bad. Code doesn’t just turn dangerous on its own. Good code is good code, it can be turned bad by conscious effort on the part of somebody, but that’s an active decision that somebody makes and is responsible for. Also, all food is for eating. Code has different uses. Most is not hardened against security threats, because it is only designed to be run locally by the user, and it is total fine in that use-case. Designing code that is appropriate to be exposed unprotected to the internet is unbelievably difficult, so most code won’t be up to the task. We shouldn’t lose useful code just because it can be used out-of-scope dangerously. The risks with food are also generally higher, because almost everyone is able to ingest it. And potentially get very sick or die. So, bad food is a big risk. Bad code is not such a big risk because anyone who knows what to do with it has already passed some skill hurdles as far as understanding it goes. And it is rare to get sick or die from code. Most code should be left up, maybe with a note that says it is unmaintained, if it is unmaintained.