Software should absolutely come with expiration dates, if they can be determined in advance. There are many practical problems, however. Here are a few that c

Software should absolutely come with expiration dates, if they can be determined in advance. There are many practical problems, however. Here are a few that come to mind: (1) Upstream components/API's often don't have explicit end-of-life plans or expiry dates. (2) Often, when or whether you shut down or breakingly change an API depends on business conditions that are impossible to predict in advance. (3) If you publish an expiration date and your competitor doesn't, people might (usually mistakenly) believe their software is meant to last forever. Honesty about your product's shortcomings, while ethical, can cost sales if not everyone follows the same ethical standards. Regulation can help; nutrition information on food, for example, is federally mandated in the US to be present in a specific format. (Although I believe this only applies to food sold in interstate commerce.) (4) A "best before" date may force a company to use resources to support a failed product. If you learn the hard way on launch day that only three people and a dog are willing to buy it, normally you would just discontinue the product and move on to something else. But if you've promised it will work until 2016, you're still going to be spending development resources supporting new OS's, library versions, upstream API changes, etc.