Protocol transitions are hard.
Yeah, I know the experienced software developers reading that are thinking “Well, duh!“. Shut up already, I’m venting here. I’ve just spent the better part of two years – actually, if you include design time and false starts it could be closer to five years – designing a new application protocol for my gpsd service daemon, implementing it, getting it deployed, dealing with problems and course-correcting.
For those of you in the cheap seats, an “application protocol” is a kind of language that a program uses to communicate with other programs. Normally humans never see these, but there’s one big example that non-geeks have often seen bits of. HTML, the Web’s markup language, is an application protocol. Designing these is not easy. There are difficult issues and tradeoffs around flexibility, economy, expressiveness, and extensibility for uses we haven’t imagined yet.
When you have a whole bunch of programs written by different people communicating with a particular application protocol, changing that entire ecology to use a different one is not easy. A good analogy in the physical world is the difficulty of changing an entire country’s railroad gauge. The long-term benefits may be huge, but the short-term cost in capital and service disruption is daunting.