Seeing Both Sides of the Twitpic/Posterous Controversy

Yesterday, microblogging and content sharing service Posterous launched a new service to let users import their images from TwitPic, a service popular for image image sharing on Twitter.

It was part of Posterous’ plan to offer 15 content importers in 15 days.

However, unlike previous importers for Ning, Tumblr and Vox among others, this one did not go smoothly. TwitPic ended up blocking the importer, preventing it from working. This, in turn, resulted in a back and forth between the attorneys.

The situation prompted many, including myself, to start thinking about alternatives to TwitPic for photo sharing on Twitter. However, the more I think about the issue, the more I see both sides.

In short, this one isn’t cut and dry, though it still leaves me hoping for more from TwitPic in the future.

Posterous’ Side

From Posterous’ viewpoint, all they were trying to do was offer an easy way for their users to move the content they created from TwitPic to their service.

However, TwitPic doesn’t offer an API for pulling content out of the service, just one for putting content in. A TwitPic representative even stated that they would prefer users to do it manually, meaning right click each image by hand and save to their hard drive.

So, to build an importer, Posterous used TwitPic’s RSS feed system, which it provides for every account. RSS is an open standard and is accessible to all. So, all Posterous was doing was grabbing TwitPic’s provided RSS feed, extracting the user’s content, and importing it into their own service. As Posterous’ attorney put it, nothing illegal about it.

TwitPic’s Side

Unfortunately though, after some experimentation, it doesn’t seem to be that simple.

First, TwitPic does offer an RSS feed for each account but only includes thumbnails of the images, not the full-sized works. You can see my TwitPic RSS here. This means, at some point, Posterous was actually visiting the pages on TwitPic and scraping/extracting the images from there.

This, undoubtedly, caused a great deal of load on TwitPic’s side. Confronted with this, they decided to block the app altogether and not shoulder the burden. This is a choice every website has, to block visitors that are causing harm to the site, especially bots, and that seems likely what TwitPic did.

In short, TwitPic, has the right to say who can and can not use their site, which was the choice they made, likely in part because of the load caused by the deluge of Posterous users importing their images.

My Take

TwitPic doesn’t allow users to extract their images out of the service, either for backup or to port over to a competitor. This makes me nervous. Granted, I would have very limited use for such an importer, considering that most of my pics are stored elsewhere and are spur-of-the-moment tweets not meant to have any lasting value, I would still feel better with an exit strategy.

So I’ve decided to give Posterous a try. I’ll be using it as my default image uploader for a few weeks to see what I think. But, despite my switch, I have a hard time seeing Posterous as the straight out “good guy” in this dispute. I’m not comfortable with the likely image scraping they were performing and I don’t wish to deny TinyPic, or any site, the right to block visitors that are draining them.

However, TinyPic could remedy this by offering logged-in users an easy way to access their images for transport. Whether through a formal API procedure or simply offering a zip of all images uploaded, giving users control over their own content is key to making them comfortable in staying over the long term.

That being said, TwitPic is far from the most egregious in restricting access to one’s own information. Facebook has gone as far as to sue and be sued by social networking aggregator Power.com for their efforts to extract data from the service.

Still, Facebook has not shut down various hacks for downloading data and has even authorized applications for the purpose of downloading photo galleries, including one’s own.

Rather than blocking Posterous outright, I think TwitPic, its users and everyone would be to try and work out a way to make the two services compatible. Rather than turning to the lawyers, it would have been better to turn to each other and try to resolve the problem and ensure that data is portable in and out of both TwitPic and Posterous.

After all, data portability is what most consumers want and that isn’t a one-sided issue. It’s about users being in final control over the content they create.

Bottom Line

Simply put, data portability is not a cut-and-dry problem. It requires cooperation on the part of all sides to ensure that users can do with their own content and information as they please. Sometimes, unfortunately, that means making it easier for customers to leave your service, but it also makes it easier for them to join.

Usually, you can tell a lot about a company by how protective they are over allowing customers access to their own data. Companies that are confident in their services make it easy to import and export, those who fear an exodus, do not.

More than anything, this stance has me worried about the viability of TwitPic moving forward and whether it will be able to compete in the months and years ahead. Not because TwitPic blocked Posterous, but because it made no effort to work with them and, instead, brought in the lawyers.

TwitPic has a right to block Posterous but I, as a user, have the right to go elsewhere. That is exactly what I’m doing.

5 comments
Sort: Newest | Oldest
Jonathan Bailey
Jonathan Bailey

I think it has something to do with the API. There are dozens of apps that can do uploads to TwitPic and tweet them out but nowhere near as many for Flickr. I'm not sure why but I'm not a programmer either.

My understanding is just that TwitPic's API was built for tweeting and... not much else...

cybele
cybele

I don't understand why folks use TwitPic if they have a flickr account. Easily integrated and easier to share out to other sites (Facebook, blog, RSS, etc.).

Jonathan Bailey
Jonathan Bailey

Agreed. I think the problem Posterous created though was that hundreds were doing the export at once without warning. That's only a guess but it's the best I have. You do have a good point about bandwidth and resource usage though, manual extraction would probably take more. Still, fewer customers are likely to go the manual route, making it a resource-saver overall but one that comes at the expense of existing users.

That, of course, is not cool...

Nick
Nick

If TwitPic wants to have any ability to say they're doing the right thing here, they need to unblock Posterous's application immediately. If they are saying that a user can manually export the images and they'd be just fine, then having a script do it is no different. It causes no additional bandwidth charges and I'm sure that it is at least a bit optimized to try to grab the image directly rather than by fetching the whole page first.

You have to make the data that users put in easy to get out anymore. It just doesn't work well if you don't. I'm with Posterous on this one.

Nick
Nick

If TwitPic wants to have any ability to say they're doing the right thing here, they need to unblock Posterous's application immediately. If they are saying that a user can manually export the images and they'd be just fine, then having a script do it is no different. It causes no additional bandwidth charges and I'm sure that it is at least a bit optimized to try to grab the image directly rather than by fetching the whole page first.

You have to make the data that users put in easy to get out anymore. It just doesn't work well if you don't. I'm with Posterous on this one.