> Sadly, open standards also slow down the development of new features, as everybody needs to be "on board" for new features to roll out. Take email (SMTP, IMAP, etc) as an example, where no major progress has been made in 25+ years, despite the platform being hopelessly insecure.
The usual answer for avoiding the need for everybody being "on board" with the changes is capability negotiation. Unfortunately, that doesn't work for email since it's a unidirectional, store-and-forward protocol: the sender has no way to negotiate capabilities with the recipient (or recipients, in case of a mailing list). If for instance I invent a new rich-text format for email, I have to include a fallback format on every message, since I cannot know whether the recipient can read my new format.
> Feel free to replace email for TCPv4/v6.
With TCP, there's another issue: middleboxes. While TCP does have working capability negotiation, unrelated third parties (which were not part of the negotiation) interfere with things they don't understand. If for instance I introduce a new TCP option which when negotiated changes the meaning of the sequence number field, a stateful firewall would drop the data packets even though they're valid for both endpoints. Due to the large amount of middleboxes in the wild, the design of TCP has been effectively "frozen", in that any enhancement will break unexpectedly for a large subset of users.
> The only successful open standard i can think of would be HTTP.
What saved HTTP was SSL/TLS. By making it hard for middleboxes to interfere without actually acting as an endpoint (with negotiation), it allowed the protocol to evolve. The best example is HTTP2: while there is a cleartext version of HTTP2, nobody uses it because it would get broken by middleboxes.
The usual answer for avoiding the need for everybody being "on board" with the changes is capability negotiation. Unfortunately, that doesn't work for email since it's a unidirectional, store-and-forward protocol: the sender has no way to negotiate capabilities with the recipient (or recipients, in case of a mailing list). If for instance I invent a new rich-text format for email, I have to include a fallback format on every message, since I cannot know whether the recipient can read my new format.
> Feel free to replace email for TCPv4/v6.
With TCP, there's another issue: middleboxes. While TCP does have working capability negotiation, unrelated third parties (which were not part of the negotiation) interfere with things they don't understand. If for instance I introduce a new TCP option which when negotiated changes the meaning of the sequence number field, a stateful firewall would drop the data packets even though they're valid for both endpoints. Due to the large amount of middleboxes in the wild, the design of TCP has been effectively "frozen", in that any enhancement will break unexpectedly for a large subset of users.
> The only successful open standard i can think of would be HTTP.
What saved HTTP was SSL/TLS. By making it hard for middleboxes to interfere without actually acting as an endpoint (with negotiation), it allowed the protocol to evolve. The best example is HTTP2: while there is a cleartext version of HTTP2, nobody uses it because it would get broken by middleboxes.