Ask HN: What Can Distributed Software Development Teams Learn from FLOSS?

As a long time free software proponent and team lead of a small development team (10+ ppl) in a midsized company I always try to intercorporate my experiences from both worlds. Lately I was confronted with the need to accept new team members from abroad working on the same codebase and I expect to have even more [http://www.helpscout.net/blog/virtual-teams/ and http://www.peter-ivanov.com/will-working-virtually-frequently-future/] telecommuting people in my team in the future. All this while research suggests that the failure rate of virtual teams could be as high as 70% [http://sherimackey.com/2012/06/19/virtual-success-the-dark-side-of-virtual-teams/].

On the other hand many FLOSS projects do not seem to suffer from the same problems (especially premature deaths), despite being developed in a distributed manner more often than not. What can corporations and managers learn from FLOSS to make their distributed teams more successful? Consequently, what FLOSS tools, methods, rules and policies can and should be incorporated into the software development process in a company more often?

I'm interested in the opinion of others especially regarding technical issues like source code ownership and revision control system, but also ways of communication, dealing with cultural differences, ...