Save FriendFeed! Why we need niche social networks

The Internet economy dictates that social networks win big or go away. But there should be a place for useful services like FriendFeed, which Facebook says it will kill soon

social networking enterprise group workers people table circle

When Facebook announced its impending shutdown of FriendFeed, the chatter was predictable: It was the long-expected end of yet another failed social network. That doesn't begin to explain what FriendFeed's real value was, why that mattered, and how it might be recreated.

FriendFeed combined two major functions: group messaging and feed aggregation. Were it only a platform for group discussion it would still have been useful. Even today, that basic need isn't easy to satisfy in a lightweight and open way. But it was feed aggregation that made FriendFeed into something more: a user innovation toolkit, albeit one that was never well understood or fully exploited.

For posterity, here are the services that FriendFeed could aggregate (pictured left).

FriendFeed services

Services aggregated by FriendFeed

In a FriendFeed group, the flow of items could be a mix of member conversation and external feeds. How is that useful? For me, it was the ideal way to support the Elm City project when I was actively working on it. As with any discussion forum, it enabled me to provide linkable and searchable answers to questions from curators, as well as transfer one-to-one communication via email into the one-to-many environment of the forum.

But there were also streams of notifications in other places that I wanted to consolidate and bring to the attention of curators. I wrote articles about the Elm City project on my own blog, and at various times on an O'Reilly Media blog and The project status page was another source of items of interest to curators.

In some cases, RSS feeds were already available for these sources. In other cases, I constructed them using tagged social bookmarks. Then I added those feeds to the FriendFeed group's stream.

FriendFeed's celebration of that do-it-yourself approach was both its great strength and, arguably, its downfall. Wiring services together in that way is a fundamental Web literacy. When we talk about teaching everyone to code, JavaScript isn't the place to start. Forming URLs and using them to compose lightweight solutions is a kind of coding that's much more relevant to most people. That's my belief, anyway, but it isn't widely shared and clearly wasn't helpful to FriendFeed.

This week I'll begin working on a new project that would benefit from the same kind of support forum that FriendFeed provided for the Elm City project. Obviously I won't be able to use FriendFeed. But it's worth asking why that's necessarily so.

We take it for granted that services like FriendFeed must either scale out massively or die. The massive scale requires infrastructure that cannot easily be replicated. But like many social networks, FriendFeed supported lots of small independent groups. There were, for example, 85 members in the Elm City group. You don't need planetary infrastructure to support a group like that. A $5 monthly Digital Ocean droplet is more than sufficient.

What about maintenance? I don't think FriendFeed got much love in recent years. But it probably didn't need much, either. A mature service that's been used well and thoroughly debugged tends to keep running. When growth and active development end, so do the major causes of breakage.

Nowadays, services like FriendFeed are born in the cloud. They start small and aim for world domination. A few make it. When most don't we call them failures and consign them to the dot-com deadpool. Maybe there's another way. Maybe services like FriendFeed can go back to being small, become distributed, and continue to deliver their unique value to those who appreciate it.

Copyright © 2015 IDG Communications, Inc.