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.