I'm surprised that no one has sent this out yet:
http://gigaom.com/2014/04/12/why-i-quit-writing-internet-standards/
"Summary: After contributing to standards organizations for more
than seven years, engineer Vidya Narayanan decided it was time to
move on. Although she still believes that these organizations make
the Internet a better place, she wonders about the pace of change
versus the pace of organizations."
"while the pace at which standards are written hasn't changed in
many years, the pace at which the real world adopts software has
become orders of magnitude faster."
This is key, in a way. But the pace at which software has been
adopted hasn't changed. Nor has the pace at which the real world
adopts *interoperable protocols* changed -- and that has always been
much slower. What has happened is that a lot of the focus (and money
and employment) has moved from adopting new protocols to adopting new
software, software which is under no interoperation constraints.
A simpler comparison is between the compilers for two languages:
Fortran and Perl. There have been many, many Fortran compilers
written, and at any era, there has been the effort to standardize the
language that the compilers accept, so that a program can be compiled
using more than one compiler. In reality, to ensure that the
compilers interoperate.
Now look at Perl. There has only been one compiler in all of history,
so that any Perl program that works on one computer works on every
computer that implements Perl -- because it's always run using the
same compiler.
In this case, it is a side-effect of open source, I think, because
open source eliminates the financial pressure on computer vendors to
write their own compilers for a language.
A similar thing has been happening in other fields. An internal
feature can be added to Apache and distributed to the world in
months. But adding a feature to HTTP can take years, because it has
to be designed and implemented to be interoperable -- in this case,
between the HTTP servers and the HTTP clients.
In the current Internet business, a lot of the new business is at the
application layer, and it is composed of "walled garden" web sites,
which don't have to interoperate with anything else. In the more
elaborate cases, the user's web browser effectively downloads the
client software at the point when the user accesses the server. There
are no true interoperability constraints.
In situations where you are going to need "two independently-developed
interoperable implementations", a standards process is still needed.
But there are a lot of high-profile situations where that isn't
needed.
In regard to speeding up the standards process, it's clear that in
most cases, the process could in principle be carried out much faster.
In all the cases I've observed, the major problem is that the
participants can only spend a small fraction of their working hours on
the standards discussion. I assume this is because it's rare that
getting the standard completed is gating to shipping their employer's
product.
Dale