As much as I love Flickr and the community that it encompasses, I need my photographs to be on my own site with my own layout and my own additional features. However, regardless of what I do on my own site, I intend to continue placing my photographs in Flickr for the community aspect and feedback it provides. So, as I see it that leaves me with three options.
# Use Flickr to power my own Gallery.
# Host my own Gallery and have it synchronize with Flickr.
# Host my own Gallery and use it separate from Flickr.
Flickr provides an API that will allow me, with a bit of programming, to display my images there on my own site. With some creative tagging, some fancy tactics, and a bit of coders duct tape, a working site can be produced. This is very easy to do because three or four very simple scripts tied together can handle everything. However, because Flickr does very little to protect the full sized version from unauthorized downloads, I do not upload full sized versions at all. This means that automating my lab orders becomes much more difficult. Additionally, this means that I have to rely on Flickr, its servers, and its TOS. Should those things go down, my site will be rendered inoperable.
Hosting my own Gallery is pretty easy these days, too. "Gallery 2":http://gallery.sf.net/ is feature rich and not any more annoying than using "WordPress":http://wordpress.org/ as my blogging software. It has a modular architecture that should make extending it fairly easy. However, it will need to be extended. In order to keep from having to upload images and maintain titles and descriptions in two places (my Gallery and Flickr) I'd like to author a Flickr synchronization module. Additionally, the only currently written commerce module, "checkout":http://sourceforge.net/projects/gallerycheckout/, is nearly useless. Products are defined and priced globally. Overriding the price of an individual product is possible through a very cumbersome method. I need image classes, and products based on the class of image. I also need to ability to hold sales, offer coupons, and provide purchase options. So, this means that I'll need to write at least two modules. This also means that I have to understand how Gallery works under the hood. This programming is quite a bit more difficult and cumbersome than the four simple scripts needed to use the Flickr API. However, the results are more stable, more capable, and more future proof.
Finally, I can simply host my Gallery separate from Flickr. All of the pros and cons I mentioned about hosting my own Gallery still apply. The only difference is that I don't have to write the Flickr synchronization module in exchange for having to upload every image twice and deal with captioning and titling in both locations. If I'm going to write modules, I may as well go all the way, so this option doesn't appeal to me.
So, I'm left with two options. One option (using Flickr) is easy to write and fairly simple to maintain. Additionally, 1/4th of it is already done: that's how I currently sell photographs currently. Furthermore, quite a few people have written similar (yet terrible) applications that I can use for inspiration (read: theft). However, the end result is far less flexible, stable, and future proof then the more complicated method of hosting my own. Additionally, writing these two modules and releasing them to the community will allow me to give a little back and drum up a little exposure for myself in the process.
Yeah, yeah. I know what I need to do. I just hate doing it.
