A far bigger danger is pseudospecifications. When everyone uses the same 3 libraries, it isn't too much work to stack on a few compatibility hacks. Protocols t

A far bigger danger is pseudospecifications. When everyone uses the same 3 libraries, it isn't too much work to stack on a few compatibility hacks. Protocols that have 700 different variations have deviation built directly into the spec. Programmers absolutely adore making these because they hate arbitrary standards. If you say "The header has a 64 bit timestamp" they'll say "But what if I only need 32". If you say "This uses UTF8" they'll say "What about an ASCII only variant", and that kind of thing makes protocols fragmented from day 1. If some deviance gets truly entrenched, sometimes it's because it's what the community wants, and it should be the new spec. Maybe some header is actually rather useless and can be inferred from data, so you don't send it on some embedded system where memory is tight. Sometimes you just can't control it. You will probably never convince CompuComp to drop some shitty extension they made. You'll probably never get people to stop using it. Lack of compatibility will only hurt your product, not theirs. People should maybe think twice about it, and maybe they should avoid using it if they are the inventor of a protocol and control the main implementation.... but if it's free for all bazaar model stuff(A problematic dev practice in itself), I think it can be useful.