I’m getting the hint that everyone’s tired of politics, so here’s something else, technology.

I got an email from Qoop.com today informing me that they’ve launched their beta services with Flickr and Buzznet (both good photo sharing sites). I originally heard about Qoop via Battelle’s Searchblog where it was introduced as a web-to-print play. For example, Battelle set up a deal with them to offer a bound print copy of the Searchblog posts from 2004. There were some clever possibilities hinted at with regard to micropublishing.

The Flickr integration is sweet and simple. You can go ahead and get photo books published or posters published of your photos. The layouts and choices are very simple right now. I suspect this will get better over time. The app even generates previews and emails you when they’re done (or you can wait… 500 photo posters take a while).

Battelle has more today on Qoop and some interesting possibilities with Google Print

For the techie/web business guy in me, there’s even more interesting things going on here. The integration between the two sites seems to be fairly loose. Different clues make it seem like Qoop is mainly relying on the public APIs of Flickr. Granted, they may have some special deal in place to use those APIs in a commercial venture and perhaps they have some extra features, but in principle you or I could build the application that generates the posters. Heck, people have. They just haven’t put together the printing part of this, of course.

Integration like this is one reason I am a big fan of public APIs from web sites, especially sites that make a business out of storing and managing user data. I always hate it when I spend a bunch of time adding data to an app, be it a fantasy football game or a photo sharing site then find out that the one feature I really want is not available at the service I chose.

Flickr provides a good example. I got a pro account after I found FlickrExport, a plugin for iPhoto that allows users to export to Flickr directly from iPhoto. It’s that missing feature that Yahoo Photos or Ofoto didn’t have. By having the API, a third party was able to create the missing feature, improving Flickr at the same time. It’s a great situation.

The main risk with doing this is that users can be more mobile. In other words, they can export data to a competing service, especially if the competing service simply implements the public API. Also, sites that rely on advertising for revenue may not want users looking at content on other sites or applications. For example, ESPN.com doesn’t offer full stories via RSS because it would cut into our advertising (RSS is essentially a web API for content).

In most cases, though, the benefits outweigh this risk. For one thing, there has yet to be an API war, if you will, in the Web 2.0 space. There simply hasn’t been an API competitor for Flickr or del.icio.us or whatever. Some day that will happen, though, and it will be interesting to see how that plays out.