Join the 85,000 open source advocates who receive our giveaway alerts and article roundups.
Interview with Evan Prodromou, lead developer of pump.io
pump.io: the decentralized social network that's really fun
Get the newsletter
For more than a decade, Evan Prodromou has worked to build open source tools that help people share things online. In 2003, he co-founded Wikitravel, a website that lets world travelers collaborate on the ultimate travel guide. Then, in 2008, Prodromou launched StatusNet, a decentralized, federated networking tool whose public face, identi.ca, became the microblogging service of choice for many free software advocates and open enthusiasts.
But when he speaks of his latest project, pump.io—a leaner, simpler, more efficient, social networking server with simple APIs—Prodromou is careful to keep the politics and technicalities of online social networking firmly in the background. Building an open source social network is not just a way to avoid privacy violations, censorship, or monopoly, he says.
He's hoping others are similarly enthused. Last December, Prodromou announced the close of StatusNet (the project's code has since become part of the GNU Social project) and committed himself to building pump.io (as well as to teaching others how to hack on it). On July 11, Prodromou finished migrating identi.ca—and its passionate user base—from StatusNet to pump.io. Identi.ca is now just another node in what Prodromou hopes will become a growing network of pump.io sites.
Read more in this interview with lead developer, Evan Prodromou.
Explain the pump.io project to us.
pump.io is an activity stream server that does most of what people really want a social network server to do.
That's a pretty packed sentence, I understand, but I can try to unwind it a little.
"Activities" are the things we do in our on-line or off-line life—waking up in the morning, going for a run, tasting a beer, uploading a photo, adding a friend, eating a burrito, joining a group, liking a blog post.
pump.io uses a simple JSON format to represent all these kinds of activities and many more. It organizes activities into streams—time ordered lists of activities, with the newest first. Most streams are organized by theme, like: all the things that my friends did, or all the things that I did, or all the things anyone has done to this picture.
Programmers use a simple API to connect to a pump.io server and add new activities. pump.io automatically organizes the activities into streams and makes sure the activities get to the people who are interested in them.
And, really, that's what we want from a social network—to find out what our friends, family, and coworkers are doing. pump.io does the routing for social networks in a simple, natural way by default, and programmers can fine-tune that routing if they need to.
What are your goals with pump.io? What problems have you designed it to solve?
There are three big needs that I want to solve with pump.io.
- mobile-first social networks. I've talked to developers over and over who are looking for a scalable open source server for their mobile social networking app. Developers who are good at iOS or Android development want to concentrate on making that front-end excellent—not on building yet another Like API. Although there are other open source social network programs, like StatusNet, most of them focus on the Web interface and leave the API as an afterthought. pump.io is first and foremost an API server. It has a default Web UI if you want to turn it on, but you can turn it off and just use the API server by itself.
- activity streams for non-social software. Activity streams show up in lots of software, but a lot of times it's not software designed to be social. Software that's meant for making books, for rendering 3D models, or for bug tracking have all kinds of activities that people do, but it's hard and kind of distracting for developers to implement those activity streams well. pump.io lets those developers get activity streams into their software kind of for free.
- social internetworking. I'm excited about the federated social web, so any social software I make is going to have the ability to connect to other social software. A pump.io server can push an activity to another server if it thinks there's a stream there that needs it. This lets the pumps form a mesh of connected users. You can set up a private internetwork—say, between interoperating applications—or join the increasingly large public pump network.
How does pump.io differ from your previous project, StatusNet?
pump.io is different from StatusNet in a few ways, but I think the main difference is that it does a lot less. The StatusNet server software ships with two different APIs, about 150 kinds of pages and 117 plugins. We have a desktop client, an Android client, and an iOS client. You can login to a server five different ways.
That kind of bulk has a few downsides. First, it's way more than any one developer needs to build their own site or project. So they end up either having a lot of features enabled their users don't need, or going through the admin interface flicking switches to turn things off. Second, it's really easy to miss what the value is—a developer looks at it and thinks, "This is a microblogging server; I'm working on video-sharing. This isn't for me." And third, it really sucks the air out of the room for third-party developers. It doesn't leave much around the edges to do.
pump.io is really designed from the ground-up as a lean, mean developer tool. Developers can either set up a pump for their own project, or they can build applications for the public pump network. It's not easy—it means making decisions that keep the server tight, scalable, and performant—but I think it pays off in the end.
Though its code is still available, you've essentially sunsetted StatusNet. What do you hope to do differently with pump.io?
That's not actually true. There is a lot of battle-hardened code in StatusNet written by some of the smartest people in Web development, and it's running a lot of public and private sites. It's got a passionate community around it. I couldn't sunset that software if I tried.
Instead, we're contributing the code of StatusNet to the Free Software Foundation where it will form the core of the GNU Social project. There's a really passionate community of developers around GNU Social, and I think there's a strong incentive to make the two programs internetwork, just like two pump.io servers can internetwork.
As for what I hope to do differently: I really want pump.io to become one of those essential pieces of infrastructure for development. We have great, rock-solid servers like memcached or RabbitMQ that implement certain kinds of data routing. I think pump.io can be part of that toolset.
What lessons from StatusNet guided your construction and implementation of pump.io?
Probably the biggest lesson has been how amazing the Internet community has been in support of the work E14N has done. I've always been the kind of person who wants to do everything himself, and working on a big free and open source software project has made me realize that you can really do a "trust fall" back into the arms of the community. They're going to be there.
That's one of the reasons pump.io tries to push innovation out to the edge. If you trust people to step up, they're going to do it. I really want to see the cool mobile and Web UIs, apps, games, search engines, and data mining tools that people build for the pump network. Already in the last few months since the first few versions have come out, we've had some cool desktop and mobile clients developed. And I think there's more on the way.
Another thing I've learned is that you really have to dogfood your own technology. E14N has run big public social networks like identi.ca since 2008, and they're a pretty essential part of my life. Having the pump network running means I'm using the software for connecting with friends and family—and I live with the consequences of my development decisions.
Why is decentralized social networking so important?
Phew! That's such a dangerous topic. There's a real hazard of focusing the discussion on what's wrong with centralized social networking—privacy violations! stifled innovation! government surveillance! unfair playing fields!—and just getting people really bummed out before they ever even start thinking about what the alternatives could be.
It's like opening a box full of spiders and snakes right someone's face and yelling BOOGETY BOOGETY BOOGETY. People just want to get the hell away from you; they're not going to stop to listen to whatever it is your selling, no matter how great it is.
So I try to skip that part entirely. The thing about a social internetwork is that it's really fun. It's fun to set up a network just for you and your family, and connect that network to other families in your neighborhood. It's exciting to set up a pump.io server on your Raspberry Pi. If you're a software developer, it's awesome to get rid of the layers of bureaucracy between you and your users and make software that matters to them. If you're a designer, it's great to set up your own site that shows off your style instead of some one-size-fits-all profile page.
Some people I talk to get all confused when I say you can make your own social network. "Who would want to make their own social network?" And I say, "You smoke your own ham. You built a 14-foot-high velocipede for Burning Man. Why wouldn't you make your own social network?"
I get giddy when someone makes something cool with pump.io. It must be how the people at Lego feel every day. And that's really what pump.io is. We've made this software, but our users put it together to make the network.
And if that doesn't float your boat, well, that's fine. A pump on its own is a really great tool to work with in its own right. And if you want to connect some pumps together, well, the plumbing is there to do it.