"Is it churlish to suggest that the most clear counter-example to "all in same room" is http://git.kernel.org/ "

Not churlish - maybe misguided ;-) I'm really not trying to suggest that distributed work is bad / evil / fails. Just that - all things being equal - colocated teams win. That there is a substantial body of evidence that not being colocated carries a substantial productivity hit.

My "gut feeling" is that regular funded sprint meetings plus remote working is an area of research that may well yield best long term trends. But wheres the proof :-)

Indeed! It's the complete absence of "distributed teams do X and Y better" research that I find fascinating. Unless it's hiding in a corner that I've not been able to find.

I'd be curious to know if any of the quoted research looked at open source projects. In addition, I'd be curious to know if it included organizations such as GitHub and 37signals, especially given how old it is.

Very few pieces of the kernel were actually developed by teams. One guy writes this subsystem, another writes a driver. The interactions between components are well established. Approximately 0% of the linux kernel consists of interdependent components simultaneously developed by different people.

I think he's implying the kernel as a whole. Clearly, the whole kernel is developed by a very distributed "team".

That said, you get right to the heart of the matter: the interactions between kernel components are well established. Sufficiently so that one person can work independently on a subsystem and another on a driver.

In my own personal experience, designing component interfaces is the most important aspect of building a system, especially when you are working with a team. Very often, I have found that the "all in one room" development model is implemented because the team lacks the ability to define those interfaces first. They are very fluid and so it's necessary to be able to lean back and yell at the guy working on the driver or subsystem and say "yo, I need this additional parameter". On a distributed team you need to write that in an email and that extra effort is often seen (rightly or wrongly) as a major bottleneck.

Where I have seen companies fail to work successfully with geographically distributed teams, it has generally been because their "all in one room" culture has allowed them to establish an adequate process/culture around designing quality component interfaces in an efficient manner. This inability to define quality "contracts" is typically what leads to slipped projects and missed expectation. Often times, it is what plagues teams that are co-located.

If you can do a good job at defining system components and their interfaces, doing the development independently and distributed is easy. You can write test harnesses and stubs around those APIs. The question is: can you work on that design process in a distributed manner as well?

In my experience, it doesn't matter, local or remote. Designing component interfaces is hard work and hard to get right. But it is essential.

perfect perfect perfect

  In my own personal experience, designing component interfaces is the most important aspect of building a system, especially when you are working with a team. Very often, I have found that the "all in one room" development model is implemented because the team lacks the ability to define those interfaces first.