5 ms·

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

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.
    - callmeed 15y ago
      >> 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. Can you provide a source or specific TOS clause that shows this?
      - khornschemeier 15y ago
        I thought it was pretty well known that sites give themselves those rights in the TOS, especially with the recent Twitpic issues where they were selling user content. In any case, from SmugMug's terms: "However, by uploading and/or posting any User Content to the Site, you grant SmugMug a perpetual, nonexclusive and royalty-free right to use the User Content and the name that is submitted in connection with such User Content, as is reasonably necessary to display the User Content, provide the Services and to facilitate, at Content Owner's direction, the license of Photos or the sale of Products on the Site." Under #13, http://www.smugmug.com/aboutus/terms/ http://www.smugmug.com/aboutus/terms/. From Facebook terms, "you grant us a non-exclusive, transferable, sub-licensable, royalty-free, worldwide license to use any IP content that you post on or in connection with Facebook ("IP License"). This IP License ends when you delete your IP content or your account unless your content has been shared with others, and they have not deleted it." Under #2-1, http://www.facebook.com/#!/terms.php http://www.facebook.com/#!/terms.php. Noticed you had no response to the value gained from OpenPhoto over the download all.
jrgnsd 15y ago
I can't comment on the $25k price tag, or if SmugMug is as open as you describe it to be, but I DO want a service where I can share photos online without losing my sense of control over them. I have a DropBox, and if there's a service that automatically picks up photos I place in a specified folder and make those taggable and publicly available, I'll use it. I don't like facebook or the effort it takes to upload photos to whatever service. This sounds easy and convenient to me. It is of course possible that there's other, easier and/or cheaper ways than the proposed solution.
- jmathai 15y ago
  SmugMug (while a great service) isn't any more open than other photo sites with an API. I have thought a bit about sync services. Not planned atm but I have the same sentiments. Unsure if you're an iOS/OSX user but iCloud's syncing is an interesting feature I want to look into - unsure what their photostream API allows though. As far as cost - I didn't break it down to the hour. But I know that there's a lot more than $25k of work to build a really great photo service.
  - jrgnsd 15y ago
    I'm on Ubuntu and Android, and it would be a definite plus if I can drop my photos into a folder from where ever, and they're shared on the net.
    - jmathai 15y ago
      Yea, I agree. I hope to build a mobile app for the service which should make it easy to get photos from Android to the service. My friend was interested in command line tools that would do differential syncing to your local machine. It's definitely possible and I hope someone takes that on!
    - brlewis 15y ago
      Are you running Dropbox? Make a new folder and share it with box@ourdoings.com
Vitaly 15y ago
20K price tag is perfectly reasonable to develop a first public beta version of a web application (not too simple, not too complicated). Web application is much much more then a basic rails scaffold with devise and paperclip. For most of the web apps that we see in beta I'd estimate 200-500 hours of development. "1st beta" is important here. once you go out to public with your service the real work starts. A web application with real users that is open to public for some time can get way over 1000 hours of development for support, bug fixes, pivoting, new features, operations etc.

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.
  - callmeed 15y ago
    >> 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. Can you provide a source or specific TOS clause that shows this?
    - khornschemeier 15y ago
      I thought it was pretty well known that sites give themselves those rights in the TOS, especially with the recent Twitpic issues where they were selling user content. In any case, from SmugMug's terms: "However, by uploading and/or posting any User Content to the Site, you grant SmugMug a perpetual, nonexclusive and royalty-free right to use the User Content and the name that is submitted in connection with such User Content, as is reasonably necessary to display the User Content, provide the Services and to facilitate, at Content Owner's direction, the license of Photos or the sale of Products on the Site." Under #13, http://www.smugmug.com/aboutus/terms/ http://www.smugmug.com/aboutus/terms/. From Facebook terms, "you grant us a non-exclusive, transferable, sub-licensable, royalty-free, worldwide license to use any IP content that you post on or in connection with Facebook ("IP License"). This IP License ends when you delete your IP content or your account unless your content has been shared with others, and they have not deleted it." Under #2-1, http://www.facebook.com/#!/terms.php http://www.facebook.com/#!/terms.php. Noticed you had no response to the value gained from OpenPhoto over the download all.

jrgnsd 15y ago

I can't comment on the $25k price tag, or if SmugMug is as open as you describe it to be, but I DO want a service where I can share photos online without losing my sense of control over them. I have a DropBox, and if there's a service that automatically picks up photos I place in a specified folder and make those taggable and publicly available, I'll use it. I don't like facebook or the effort it takes to upload photos to whatever service. This sounds easy and convenient to me. It is of course possible that there's other, easier and/or cheaper ways than the proposed solution.

jmathai 15y ago
SmugMug (while a great service) isn't any more open than other photo sites with an API. I have thought a bit about sync services. Not planned atm but I have the same sentiments. Unsure if you're an iOS/OSX user but iCloud's syncing is an interesting feature I want to look into - unsure what their photostream API allows though. As far as cost - I didn't break it down to the hour. But I know that there's a lot more than $25k of work to build a really great photo service.
- jrgnsd 15y ago
  I'm on Ubuntu and Android, and it would be a definite plus if I can drop my photos into a folder from where ever, and they're shared on the net.
  - jmathai 15y ago
    Yea, I agree. I hope to build a mobile app for the service which should make it easy to get photos from Android to the service. My friend was interested in command line tools that would do differential syncing to your local machine. It's definitely possible and I hope someone takes that on!
  - brlewis 15y ago
    Are you running Dropbox? Make a new folder and share it with box@ourdoings.com

Vitaly 15y ago

20K price tag is perfectly reasonable to develop a first public beta version of a web application (not too simple, not too complicated). Web application is much much more then a basic rails scaffold with devise and paperclip. For most of the web apps that we see in beta I'd estimate 200-500 hours of development. "1st beta" is important here. once you go out to public with your service the real work starts. A web application with real users that is open to public for some time can get way over 1000 hours of development for support, bug fixes, pivoting, new features, operations etc.