After watching Windows, Python3, and IPv6 all go through decade long upgrade cycles, I'm hoping we've all learned some valuable lessons about the hidden costs of backward compatibility.
Alternatively, the computer industry forgot about backward compatibility and now has to relearn it.
Color TV was designed to be compatible with black&white. Stereo FM radio compatible with mono, stereo vinyl records with mono. Electricity changes very, very slowly.
When computers become such an essential part of every day life, you cannot make radical changes any more every couple of years.
If your design becomes successful, you may be stuck with it for a couple of decades.
The failure of IPv6 is also the success of IPv4 engineering. When IPv6 was designed in the mid 90s, there were many issues that might hold back IPv4 down the road.
It is only in the last couple of years, that issues (related to the IPv4 address shortage) pop up that basically cannot be solved anymore and make IPv6 an attractive alternative.
> The failure of IPv6 is also the success of IPv4 engineering. When IPv6 was designed in the mid 90s, there were many issues that might hold back IPv4 down the road.
Another big part of it is that all of the features of IPv6 except the address length change were back-ported to IPv4 (e.g. address auto-assignment and IPsec) removing the carrots and leaving only the "stick" of the IPv4 address shortage (which barely registered at all until a few years ago) to push people to v6.
I don't get it. Those long upgrade cycles happened specifically because the new version was not backwards compatible with the old. That's not a cost of backwards compatibility, it's a benefit.
We've not been using IPv6 long enough yet to tell. For all we know today, how many man-hours might get saved just from not having to deal with NAT? How many engineers won't need to learn that STUN and TURN were things? What new apps might get built if real and easy peer-to-peer is possible? We haven't had time to realize the gains.
On Python 3, I'm okay with having more discussions about some line thats failing at a byte/unicode boundary, instead of the "your entire design ignored the unicode/byte distinction, but mostly worked until now, and you've unwittingly built a mountain of technical debt." The language, going forward, encourages the correct behavior. Now if only my co-workers would stop working on that mountain long enough to switch to it…
DJ Bernstein of qmail and crypto fame etc. wrote about this in detail, ten years ago: ``The IPv6 mess''[0]
Designing around an incremental upgrade strategy is hard. It's a very important design constraint for an upgrade though!
The extra, wastefully spent bits in IPv6 make it super expensive to implement routing tables. Compare that approach to the 2^48 effective limit in the 2^64 bit address space in AMD64. Like IPv6, AMD64 is an upgrade from a 32-bit system - but AMD64 included support for the previous 32-bit version and won its war long ago, while IPv6 is still reluctantly limping along.
Upgrades of huge interconnected systems need to be incremental. As a human, invested in the process, it's hard to accept that: the point of the upgrade is to replace the old system :)
For IPv4, wouldn't that be forward compatibility? If they had designed the protocol to support different addressing schemes from the beginning, then we could have transitioned in place.
Additionally, Windows seems to be doing pretty well in backward compatibility. IMHO, its major source of issues.
