> Often the new boy on the block had emulate all the previous ones to have a hope of being adopted.
> ...
> Once it's out there you can't change the API without breaking all the deployments. Yes, a successful standard means it's been widely deployed, but it doesn't cause it.
Yes, that was the point. A public API in use by its very nature will have negative impacts on future development of that API. Or as I put it in the original comment: "Open protocols are great but they are also absolutely a hinderance on change"
> Apple has so many watches out there it can't make breaking changes to the API it uses to talk to the iPhone. Publishing that API as a standard doesn't change that.
They can, all they have to do is push out an update for those watches. That's the point. Because that API is private an exclusively used by Apple and Apple's software, they can replace it as many times as they want provided they are willing to push the updates. On the other hand, if hundreds of third parties are using that API independently, even if they push an update they still have to contend with a whole ecosystem of products that will or won't update on whatever schedule those developers feel like operating on. Apple already catches a bunch of flak for the speed at which they update and abandon their current public APIs, hardly an incentive to also open up their private APIs.
> Without those things API's based on Protocol Buffers would be hard to change, and we could never have had IPv6.
I'm not sure I'd call the transition to IPv6 an example of a resounding success of fast iteration on a change to a protocol or API. It's only been 30 years and we're still using IPv4 for most things and slapping band-aid upon band-aid on the problems, never mind the list of headache switching to exclusive IPv6 (for example, unless something has changed recently, you still can't use DHCPv6 to manage IPs for android devices)