| > Apple isn't expected to fix bugs in a third party's app using their APIs, but they're totally expected to fix those APIs, should they be faulty (conceptually or in their implementation). The problem is what we expect to be fixed for a software product and a hardware product are two different things. If you buy a car, and the next year the car company discovers they can get even more fuel efficiency with a different piston design, or they can improve crash safety with new airbag locations, we don't expect car manufacturers to recall all the current model year cars. We only expect recalls for failure to perform the expected functions that were expected at the time of sale. On the other hand, when a new version of SSL or TLS is released, when root CA certs expire or change, when new Wi-Fi encryption standards are released, we expect those updates to our old devices, almost always expected gratis and for many years after the initial sale. Look at the substantial amount of complaining every time some software company like Apple or Google announce the end of software support for some old hardware. We treat these devices differently from a tool you buy at the hardware store. And yes, Apple is expected to issue fixes bugs that 3rd parties bring to the table. Which is exactly what expecting updates for things like stronger encryption cyphers and the like are. They sold you a device that can speak Protocol X, developed by a 3rd party. You use that device to speak Protocol X to another 3rd party device or service. Yet another 3rd party invents some way to exploit Protocol X to do nefarious things. And everyone who bought the Apple device last year absolutely 100% expects apple to release an update when Protocol X++ is released. And to be clear, I'm not saying this is unreasonable, but it's worth noting as you point out that software updates used to cost money (remember the annual "why is apple charging us for a point release?" song and dance?). And we should remember that developing software for platforms used to cost money too. A lot of money. How much were Visual Studio licenses? Code Warrior? A MS developer network license? Or check out Qualcom's BREW program for the multi thousand dollar up front process to put "bejeweled" on a flip phone. When companies stopped charging for OS updates and developer kits and SDKs, the money needed to make those things didn't stop needing to be made. We talk a lot around here about the lack of funding for open source projects. Well software and software development has a value. How much is it worth, and how many new things are we allowed to demand before the price has to go up somehow? >To stick with the Home Depot example: Why should the manufacturers of third party paint cartridges pay for Home Depot's product safety obligations? I suspect that if a paint company wanted to use Home Depot's credit card terminals to do sales for a custom sales process of paint accessories to Home Depot customers that Home Depot would want a cut of that. |
In a hypothetical world where I bought a car, and the next year the car company discovers that they can get even more fuel efficiency with a different piston, or they can improve crash safety with new airbag locations, and if these already-developed changes could somehow be implemented for no more cost than a bit of Internet bandwidth, then:
I would be ABSOLUTELY LIVID if the car company extracted a tithing every time I used my car to make a delivery or a visited drive-through (or otherwise used my car for commerce).