In my humble opinion, the most crippling problem with building complex social websites in Drupal is the frustrating inability of most modules to work together nicely with user relationship modules, as well as the near total lack of support for any kind of individual, user-controlled privacy settings. I'm not exempting my own modules from this: my Facebook-style Statuses module has an architecture that inconveniently prevents it from working as well with user relationship modules as I would like. This architecture is based on a model I originally came up with when I first created the module 2.5 years ago, way back when Drupal 5 was still in its prime. At the time, Buddylist was the major user relationship module. Then along came User Relationships, which eventually superseded Buddylist; and then the field grew more clouded as FriendList made a strong but short-lived showing and Flag Friend emerged permanently on the scene. The structure I designed in 2007 has worked well, and a large part of the problem is due to Views and even SQL limitations, but it also means that some advanced use cases don't work quite as nicely as I would like. (The other big problem has to do with feasibility: there are just so many parts of a system that need to integrate in order to, say, restrict status updates to only friends that it's too difficult to keep up with them all when there are several different friend modules available.)
I've tried hard to fix the problems I'm describing with Drupal. I tried, and failed, to write a module that would simplify the process of creating individual user-controlled privacy settings across modules. I've worked very hard to make Facebook-style Statuses integrate with over 20 major modules. That has been very successful, but it's not 100% yet in the area of user relationships. I will rectify this eventually.
But more importantly, Views is a major problem: the lack of documentation and therefore awareness of major parts of Views, as well as the impossibility of covering many use cases even with that knowledge. See, we use Views to create lists of content. So whenever a module wants to restrict the visibility of another module's content -- say, if a site admin wants to show only status updates from the current user's friends -- a new argument or filter or relationship has to be added to the original view that showed everyone's status updates. Which would be fine, except that's really hard to do in a module. Views can be exported and imported in modules -- these are "default Views." To make version control nice and simple, many development firms keep each exported view in its own include file in each module. But what if another module wants to add stuff to these default views? There is hook_views_default_views_alter(), but that is sparsely documented, and its brother hook_views_data_alter() is not documented at all. But still, we could figure this out -- except that having to use these alter() hooks is really difficult to maintain in sensible version control, and also not easily exported. Is it possible? Sure, for a specific view. It's just hard and increases code bloat. But worse, it gets impossible to maintain when you have to deal with lots of different potential Views from lots of different potential modules, as tends to be the case with these things.
One recent solution for this problem is the ever-lauded Feature module. With Features, some skilled developer can take the default Views, unconnected with the relationship modules, and fix them up so that they are properly connected via the user interface. The whole thing can then be exported in a single package that glues everything together. It's kind of like what Distributions were promised to be (but never really were) when Drupal 5 came out, except that you can install multiple Feature modules on the same site.
The end of this story is that the situation is getting better, and I think we'll see more instances of Drupal modules working together nicely as it becomes easier to mix-and-match when Features grow in popularity with Drupal 7. Right now though, I'm forced to admit that I can't quite cover every single use case for every single module integration... yet.
I'm doing a presentation on Social Networking in Drupal at SouthEast LinuxFest on June 13th. (It's a lot more optimistic than this blog post indicates.) If you'll be at LinuxFest, please stop by -- I'd love to hear your thoughts.