I really agree with this.
There is a downside to chat, though: it has lower bandwidth than face-to-face communication. Sometimes you know what you need to say, but you don’t know how much the other person understands. Thus, you must figure out what they know, and how to communicate what they need to know most effectively.
In person, it is much easier to gauge how the conversation is going for the other person — you can see their face, hear their voice, etc.
My guess is that there will be an eventual place for a product like google hangouts that has a few features:
1) IDE connection, which makes it easier to share code than in real life.
2) quick/trivial video chatting, with altered social expectations.
2.5) an effective search for content of audio/video recordings
3) very easily searchable logs for all communications.
At some point, I would guess that all communication will take place with the aid of computers, just because of its benefits.
Chat isn’t always better than face-to-face time. In-person conversations should be the exception, not the rule. Also, right after a conversation, I always like to jot down the results, so that the outcome of that conversation is clear and agreed upon.
I don’t consider in-person conversations an “exception”, but they certainly aren’t a rule. I feel conversing with someone in person is oftentimes the best way to understand exactly what they want you to do.
And while a conversation-less culture may work for Github, I’ve found that such a philosophy breaks down when you work with mostly non-developers. Github’s culture is centered around developers and engineering, most businesses do not have that luxury. When the CEO of my company wants a feature done, it’s MUCH easier if him and I can talk it out so I can catch his bad ideas, and he can catch my misunderstandings about the rather large and complex system we’ve built. Him simply writing down what he wants, showing mockups, etc., is almost always confusing. Whenever I’ve done freelance, I typically give my clients a call to discuss stuff throughout the project, because when they explain things to me in different ways I can get a better understanding of where they’re coming from.
That being said, we do have difficulties given this mindset, which some call “interruption-driven development”. I am distracted every so often by what’s going on around me, or if the CTO/CEO needs something fixed right now. This can be troubling, so sometimes I will work from home simply so I can ignore interruptions and just build features quickly. If I were founding a startup, Github (or its ancestors, a large FLOSS project) is exactly how I would run it.