I find it interesting that nearly all the comments here are on Tornado vs. Twisted rather than the larger issue of communicating vs. coding that the author brings up.
There've been a lot of times - most recently yesterday - when I've hacked up a solution, mailed it off, and got back a response of "I just did this a couple days ago. With a one-line change, my code could've covered your needs too." And then of course I'm like, "Oh. Shit. Let's modify your code instead and I'll throw away my changelist."
I get the feeling this happens a lot outside of my own personal/professional sphere as well. Google's famous for its NIH syndrome. Python's got about 5 different competing web frameworks. Lots of people still write their own machine code generators instead of using LLVM. I'm kinda curious how much coding people are willing to do to save one e-mail.
Ironically, the folks who insist on building their own stuff are often right. Google's certainly done well for itself, and it's great that we can use Django instead of Zope now. So maybe the problem is that communication really is so expensive that people are better off rewriting large chunks of code to avoid it. But if that's true, we should be looking for ways to reduce the cost of communication, rather than glorifying the folks who go to heroic measures to avoid it.
It's curious - yesterday, Coders at Work was at the top of the hotlist, and most of the comments said, "I'd rather learn about the business & management aspects than the technical aspects." Yet here's an interesting business & management problem, but everyone's commenting on the technical aspects.
The reason I think that folks who build their own stuff are right is that they understand their problem domain better than anyone else.
The author says communication could have cut their time down considerably. That may or may not be true. Getting into a debate with an external project about what should or shouldn't be the correct way to fix/change the external projects code can be a huge drain on time and mental energy. You can't fault a group for deciding not to bother.
Not to mention that if you become the person responsible for a piece of an external project you are suddenly not just supporting your use of that piece you are supporting everyone else's use of that piece. That leads to more debating/discussion about the right way to do it. If you have to find a way to scale fast it might actually in the long run be less time to just write it yourself for your specific needs not an entire communities needs who have different scaling issues than you and different goals. Many times One size does not fit all and convincing someone else of that is just too time consuming to try.
The author did bring up an interesting point about friendfeed developers not even trying to communicate though so I can understand what prompted him to write the article.
I think the author is misinterpreting what's going on. It's not that it's too hard to communicate with the Twisted folks, it's that the FriendFeed folks didn't think Twisted was good enough. Twisted is too buggy and too complicated.
