> And like it or not, your next car won’t be as repairable as your current 15 year old car, because it will require custom software and bench access and updates

> And like it or not, your next car won’t be as repairable as your current 15 year old car, because it will require custom software and bench access and updates that most mechanics will not pay for or maintain. Noting that the automotive market is increasingly opening itself up to the kind of obsolescence problems the software industry has never bothered to come to grips with (indeed, is to some extent actively against solving, from incentives at the business level to personal disinclination on the part of most programmers) isn't exactly a resounding counterpoint to worries about how software problems are affecting less crucial hardware devices. > Legit question: how long should any company/service be required to add backward compatibility to old, obsolete products? There's a point in here that's legit: perpetuity is a high bar, most products don't last forever. But there's also an extent to which this question is largely a dodge of the real question: what is "old"? Why do we accept or feel forced to accept a decade or shorter timeline? > we should be building for longevity and serviceability, but that isn’t always possible. The platform and stack the CR100 was built on is not modern and cannot be easily maintained. You know how we talk about code smells? (Or maybe we don't anymore, it was always a weird term and maybe it's so early 10s now). Pretty sure the word "modern" when it comes to software should be understood as a "thought smell." Every platform/stack any software is built on will be "not modern" by software standards in well under a decade, and is quite likely to grow more difficult to maintain over time. An acknowledgement of the value of longevity and serviceability doesn't mean much while implicitly accepting software-related value choices that mean longevity and serviceability remain not only difficult to attain but difficult to conceive of. > And even if the software was open source (which would be great), that doesn’t change the fact that if the endpoints on the services it relies on change, nothing can be done. If the software were open source, when endpoints change, the threshold for continuing utility is whether there's a developer out there somewhere who cares enough to work on it. Or could be made to care by consumers bearing cash.