5 ms·

OpenPhoto, a photo service for your S3 or Dropbox account

47 points by jmathai 15y ago

joshfinnie 15y ago
I have been thinking of an idea very similar to this. I would be interested in seeing how this will work since I don't believe Dropbox will like being a CDN nor do I think S3 is user-friendly enough for the common person. Love the idea of free and open photo sharing though! Best of luck!
- jmathai 15y ago
  I've talked to the AWS folks and they do have plans for OAuth. I hope I can convince them that with a product like this the value proposition of selling their cloud services directly to end users is huge! Same goes for Rackspace. As far as Dropbox goes --- we'll see. That's a valid point.
callmeed 15y ago
I don't want to sound like a hater, but $25k for this? I can spin up a Rails app, add devise, scaffold an image model and add Paperclip with S3 support in less than 1 hour (probably closer to 30 mins). Yes, I get that there's more to it but still ... Also, this project seems to imply that people "own" files on their S3 or DropBox accounts more than they "own" files on Flickr or SmugMug. I don't get that. Maybe S3 makes it easier to download/transfer files to your local machine, but you're still relying on a 3rd party service provider in every instance. And, since DropBox and SmugMug both rely on S3, it makes even less sense. SmugMug especially has a great API and tons of 3rd party tools (including download ones [1])–so why won't the photo sharing service support that? Why won't it support images stored on the hard drive hooked up to my home router? Sorry, but coming from someone who works in the photo space, this project doesn't seem very thought out from a "here's a problem that needs solving" point of view. [1] http://wiki.smugmug.net/display/SmugMug/Hacks+and+Apps http://wiki.smugmug.net/display/SmugMug/Hacks+and+Apps
- jmathai 15y ago
  Valid questions - not hater-ish at all. Sure, you can spin up an app and server some images from S3 but like you said there's a lot more to that. I'm not pitching a simple photo hosting service like Gallery that stores your photos in S3. Perhaps I can go into more detail on the KS page though. The fact that SmugMug and Dropbox use S3 is irrelevant because they don't hand you their AWS key and secret. The point of OpenPhoto is to decouple the frontend interface(s) from the actual storage. If you want to write a separate frontend adhering to the OpenPhoto specification then that completely works and you don't have to do any exporting or downloading. That's where the ownership differences start to become apparent. Even with great APIs SmugMug is still the gatekeeper. Support for a hard drive hooked up to your home router is completely doable. Just write an adapter that conforms to the OpenPhoto spec ... it's how S3 support works. It's meant to be completely swappable though. Also, in addition to S3 is the ownership of tags, comments and metadata. For this to be a truly open system it shouldn't sit in a mysql or mongodb that OpenPhoto runs. Hope that answers some of your questions. I'm in the photo space myself. I was surprised that you trivialized building a truly great photo service.
  - callmeed 15y ago
    >> The fact that SmugMug and Dropbox use S3 is irrelevant because they don't hand you their AWS key and secret. Exactly. So, why support one (dropbox) but not the other? Is it only because DropBox files are sync'd to a local machine? SmugMug has a "download all" option and most users keep all their original files locally anyway. Plus, considering SmugMug offers unlimited storage, you can argue that it's more affordable than DropBox or S3 once you reach a certain threshold. I get the decoupling argument but every service is a gatekeeper to some degree. I'm not trivializing building a great photo service–reading the project description simply didn't strike a chord with me as a "great service that solves problems". And I don't mean that in a mean-spirited way.
    - khornschemeier 15y ago
      I'm a SmugMug user but I can definitely see the value here. All sites where you upload your photos have a TOS that gives them rights to use and keep your photos, even if you leave the service. A service like this would not have those rights and not even be able to access your photos if you leave because you own the S3 container and take your photos with you. Download all is also not a great solution because if you want to leave then you have to download all your files and then upload them all again to the new service. Using a solution as OpenPhoto you would just be able to move from one provider to the next without any hassle. I'm also assuming with the download all solution you lose all your ratings, tags, comments, and any other meta info on your photos. Again, moving services with something like OpenPhoto would keep that data with the photos.
bryanallen22 15y ago
Any plans to add video?
- jmathai 15y ago
  I should add that to the FAQ. It makes sense as a logical progression to add video support. I defer this one to the community to see if there's enough demand for it. Or of course is someone's motivated enough to fork the code and add it!
LokiSnake 15y ago
Do you have an estimate of the storage/transfer costs if doing self-hosting?
- jmathai 15y ago
  Yes. Below and added to the FAQ on Kickstarter. 20GB of storage ≈$2/mo A 250KB photo served up 4,000 times ≈$.10/mo-- ten cents A simpleDb database for a personal account is typically free That would be about $2.10 per month if you get a lot of views on your photos and store 20GB. There's virtually 0 cost outside of what you pay for your cloud services. If you host the software yourself the only bandwidth will be html markup and a few images for the site (not your photos). Everything else is offloaded to the cloud service provider (and is as cheap as you can get). Hope that answers your question!
deleted 15y ago
[deleted]
- jmathai 15y ago
  Not sure what the details of your startup are/were but the goal of this project is to create and release an open source photo sharing service and a hosted version of it for non technical users.
  - jamesteow 15y ago
    Ehh it's fruitless to be bitter about rejection. I'm just going to wish your endeavor luck and test it out if it gets funded since I like photography.
elbrodeur 15y ago
I said I would pay to use it if you built it, so I've become a backer. Can I ask why you're going the open source route? I would definitely pay a premium to make sure your service stays around, is reliable and is improved over time. http://news.ycombinator.com/item?id=2184603 http://news.ycombinator.com/item?id=2184603
- jmathai 15y ago
  True to your word :). I'm open sourcing it specifically so that it stays around. I have two goals with this: to provide a better photo sharing option for those who want to own their photos and to build a viable business around it. Once it's done and open sourced the first goal will be met. Then I want to focus on providing the service in a hosted model similar to wordpress.com. It will be free to use but there will be premium services you can pay for. Open sourcing it also fosters competition. If someone else wants to build an Instagram clone that ties directly to your S3 bucket then they can easily do it using the language bindings provided by OpenPhoto or opt to use the OpenPhoto API as a proxy. All your photos in your bucket regardless of the service you use. Let me know if you have any suggestions or questions.
grandalf 15y ago
This is awesome. Add a simple iPhoto replacement app for camera syncing and basic editing and I'll donate $100.
- jmathai 15y ago
  It's actually the $500 pledge level that gets you feature requests! Just kidding. So there's been some conversation about sync. Nothing solid yet but a couple ideas include the iCloud photostream API (iOS/OSX only and I need to familiarize myself with it), an rsync style automatic uploader, etc. There isn't an official feature request forum but feel free to open an issue on Github and include some of the specifics of what you're looking for. https://github.com/openphoto/frontend/issues https://github.com/openphoto/frontend/issues
  - grandalf 15y ago
    Excellent. The big unsolved problems with photos are the following four: - Picasa doesn't accomodate the workflow of two parents who might both want to add/edit an album containing their child's baby pictures, each using their own google account + picasa on their own laptop. iPhoto / MobileMe doesn't even come close. - iPhoto doesn't allow for two people to collaborate on an album, each as first class citizens, and insists upon its own file storage approach which means that you can't keep two machines in sync easily. - No cloud system that I'm aware of will let me conveniently manage a library larger than my hard drive. Why not let me specify how much hard drive space I want to allocate to a picture cache and let the pics actually live on the cloud? I think that what's needed is a standard for filesystem-based storage/editing that addresses revisions, undo, etc., so that a library may be synced between two computers and all of that state is shared. I want to be able to undo a crop that someone else made, for example. And, of course, the cloud needs to just work seamlessly with it all.
    - jmathai 15y ago
      That's a tall order. But full of good stuff. - Not sure if this solves the workflow problem but two (or more) people can share the same cloud storage account but maintain their own personal login information. The desktop vs. web component can be worked out later - the platform supports this. - Addressed above? - S3 lets you store as much as you want (theoretically). You pay for whatever you use. I don't believe anyone is going to have as seamless an integration as Apple does with iCloud. I think others can get "close enough" while providing other features and functionality which surpass the extreme seamlessness iCloud purports.

47 points by jmathai 15y ago

I have been thinking of an idea very similar to this. I would be interested in seeing how this will work since I don't believe Dropbox will like being a CDN nor do I think S3 is user-friendly enough for the common person. Love the idea of free and open photo sharing though! Best of luck!

jmathai 15y ago
I've talked to the AWS folks and they do have plans for OAuth. I hope I can convince them that with a product like this the value proposition of selling their cloud services directly to end users is huge! Same goes for Rackspace. As far as Dropbox goes --- we'll see. That's a valid point.

callmeed 15y ago

I don't want to sound like a hater, but $25k for this? I can spin up a Rails app, add devise, scaffold an image model and add Paperclip with S3 support in less than 1 hour (probably closer to 30 mins). Yes, I get that there's more to it but still ... Also, this project seems to imply that people "own" files on their S3 or DropBox accounts more than they "own" files on Flickr or SmugMug. I don't get that. Maybe S3 makes it easier to download/transfer files to your local machine, but you're still relying on a 3rd party service provider in every instance. And, since DropBox and SmugMug both rely on S3, it makes even less sense. SmugMug especially has a great API and tons of 3rd party tools (including download ones [1])–so why won't the photo sharing service support that? Why won't it support images stored on the hard drive hooked up to my home router? Sorry, but coming from someone who works in the photo space, this project doesn't seem very thought out from a "here's a problem that needs solving" point of view. [1] http://wiki.smugmug.net/display/SmugMug/Hacks+and+Apps http://wiki.smugmug.net/display/SmugMug/Hacks+and+Apps

jmathai 15y ago
Valid questions - not hater-ish at all. Sure, you can spin up an app and server some images from S3 but like you said there's a lot more to that. I'm not pitching a simple photo hosting service like Gallery that stores your photos in S3. Perhaps I can go into more detail on the KS page though. The fact that SmugMug and Dropbox use S3 is irrelevant because they don't hand you their AWS key and secret. The point of OpenPhoto is to decouple the frontend interface(s) from the actual storage. If you want to write a separate frontend adhering to the OpenPhoto specification then that completely works and you don't have to do any exporting or downloading. That's where the ownership differences start to become apparent. Even with great APIs SmugMug is still the gatekeeper. Support for a hard drive hooked up to your home router is completely doable. Just write an adapter that conforms to the OpenPhoto spec ... it's how S3 support works. It's meant to be completely swappable though. Also, in addition to S3 is the ownership of tags, comments and metadata. For this to be a truly open system it shouldn't sit in a mysql or mongodb that OpenPhoto runs. Hope that answers some of your questions. I'm in the photo space myself. I was surprised that you trivialized building a truly great photo service.
- callmeed 15y ago
  >> The fact that SmugMug and Dropbox use S3 is irrelevant because they don't hand you their AWS key and secret. Exactly. So, why support one (dropbox) but not the other? Is it only because DropBox files are sync'd to a local machine? SmugMug has a "download all" option and most users keep all their original files locally anyway. Plus, considering SmugMug offers unlimited storage, you can argue that it's more affordable than DropBox or S3 once you reach a certain threshold. I get the decoupling argument but every service is a gatekeeper to some degree. I'm not trivializing building a great photo service–reading the project description simply didn't strike a chord with me as a "great service that solves problems". And I don't mean that in a mean-spirited way.
  - khornschemeier 15y ago
    I'm a SmugMug user but I can definitely see the value here. All sites where you upload your photos have a TOS that gives them rights to use and keep your photos, even if you leave the service. A service like this would not have those rights and not even be able to access your photos if you leave because you own the S3 container and take your photos with you. Download all is also not a great solution because if you want to leave then you have to download all your files and then upload them all again to the new service. Using a solution as OpenPhoto you would just be able to move from one provider to the next without any hassle. I'm also assuming with the download all solution you lose all your ratings, tags, comments, and any other meta info on your photos. Again, moving services with something like OpenPhoto would keep that data with the photos.

bryanallen22 15y ago

Any plans to add video?

jmathai 15y ago
I should add that to the FAQ. It makes sense as a logical progression to add video support. I defer this one to the community to see if there's enough demand for it. Or of course is someone's motivated enough to fork the code and add it!

LokiSnake 15y ago

Do you have an estimate of the storage/transfer costs if doing self-hosting?

jmathai 15y ago
Yes. Below and added to the FAQ on Kickstarter. 20GB of storage ≈$2/mo A 250KB photo served up 4,000 times ≈$.10/mo-- ten cents A simpleDb database for a personal account is typically free That would be about $2.10 per month if you get a lot of views on your photos and store 20GB. There's virtually 0 cost outside of what you pay for your cloud services. If you host the software yourself the only bandwidth will be html markup and a few images for the site (not your photos). Everything else is offloaded to the cloud service provider (and is as cheap as you can get). Hope that answers your question!

deleted 15y ago

[deleted]

jmathai 15y ago
Not sure what the details of your startup are/were but the goal of this project is to create and release an open source photo sharing service and a hosted version of it for non technical users.
- jamesteow 15y ago
  Ehh it's fruitless to be bitter about rejection. I'm just going to wish your endeavor luck and test it out if it gets funded since I like photography.

elbrodeur 15y ago

I said I would pay to use it if you built it, so I've become a backer. Can I ask why you're going the open source route? I would definitely pay a premium to make sure your service stays around, is reliable and is improved over time. http://news.ycombinator.com/item?id=2184603 http://news.ycombinator.com/item?id=2184603

jmathai 15y ago
True to your word :). I'm open sourcing it specifically so that it stays around. I have two goals with this: to provide a better photo sharing option for those who want to own their photos and to build a viable business around it. Once it's done and open sourced the first goal will be met. Then I want to focus on providing the service in a hosted model similar to wordpress.com. It will be free to use but there will be premium services you can pay for. Open sourcing it also fosters competition. If someone else wants to build an Instagram clone that ties directly to your S3 bucket then they can easily do it using the language bindings provided by OpenPhoto or opt to use the OpenPhoto API as a proxy. All your photos in your bucket regardless of the service you use. Let me know if you have any suggestions or questions.

grandalf 15y ago

This is awesome. Add a simple iPhoto replacement app for camera syncing and basic editing and I'll donate $100.

jmathai 15y ago
It's actually the $500 pledge level that gets you feature requests! Just kidding. So there's been some conversation about sync. Nothing solid yet but a couple ideas include the iCloud photostream API (iOS/OSX only and I need to familiarize myself with it), an rsync style automatic uploader, etc. There isn't an official feature request forum but feel free to open an issue on Github and include some of the specifics of what you're looking for. https://github.com/openphoto/frontend/issues https://github.com/openphoto/frontend/issues
- grandalf 15y ago
  Excellent. The big unsolved problems with photos are the following four: - Picasa doesn't accomodate the workflow of two parents who might both want to add/edit an album containing their child's baby pictures, each using their own google account + picasa on their own laptop. iPhoto / MobileMe doesn't even come close. - iPhoto doesn't allow for two people to collaborate on an album, each as first class citizens, and insists upon its own file storage approach which means that you can't keep two machines in sync easily. - No cloud system that I'm aware of will let me conveniently manage a library larger than my hard drive. Why not let me specify how much hard drive space I want to allocate to a picture cache and let the pics actually live on the cloud? I think that what's needed is a standard for filesystem-based storage/editing that addresses revisions, undo, etc., so that a library may be synced between two computers and all of that state is shared. I want to be able to undo a crop that someone else made, for example. And, of course, the cloud needs to just work seamlessly with it all.
  - jmathai 15y ago
    That's a tall order. But full of good stuff. - Not sure if this solves the workflow problem but two (or more) people can share the same cloud storage account but maintain their own personal login information. The desktop vs. web component can be worked out later - the platform supports this. - Addressed above? - S3 lets you store as much as you want (theoretically). You pay for whatever you use. I don't believe anyone is going to have as seamless an integration as Apple does with iCloud. I think others can get "close enough" while providing other features and functionality which surpass the extreme seamlessness iCloud purports.