The IETF, when it is functioning well, does a good job of documenting,
debugging and refining work that is brought to us. When we innovate, it's
usually some team of individuals who has the innovative idea, and then they
decide they want to do it in the context of the IETF. There's nothing wrong
with doing this, but there is a cost to doing it. We can certainly work to
minimize the cost that we impose, but I don't think we ought to change the
basic mechanism whereby we do standards in order to optimize this use case: in
doing so we would be letting go of what we do well.
An open source project that gets a prototype working well may or may not
actually have something. To the extent that they have made an incremental
change to an existing standard, or layered what they have done on top of
existing standards, there may well be little left to do. Then the IETF
process may feel like a straitjacket.
On the other hand, consider a project like Diaspora (in the abstract, please—I
am not suggesting the IETF take it on). Diaspora was invented by people who
didn't entirely know what they were doing, and exists essentially as an
implementation, not as a standard. When I've looked at hacking on it, I've
thrown my hands up in disgust because there's no documentation at the level
that would allow me to do an independent implementation. I think the security
is also half-baked, and could have benefited from some IETF process.
Projects _like_ this can definitely benefit from IETF process. Up to a point,
you are innovating and learning, and probably the most heavyweight IETF-like
process you can afford is to publish work in progress through the ISE, or as
individual submissions. But at some point you have something that you think
is a result, and then it's time to write an interoperable implementation and
get some peer review to shake out issues. This is when the IETF can help, and
when the IETF should help.
So I don't mean to say there's no problem here to solve, but I think the basic
idea that because open source is innovating without us, we need to
fundamentally change what we do, is mistaken.
To put it more positively, I think that IETF is an enabling technology for open
source, and that there is a strong positive feedback loop between a successful
open source project and a successful, related IETF process. And this is true
even in cases where some participants are doing closed-source projects.
So I think the things Wes outlined as weaknesses in the IETF are quite correct,
and we should work on them, but let's not throw the baby out with the bathwater.