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.
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.
>> 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.
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.
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."
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."
Those terms exist so smugmug can put the pictures on the website. Otherwise some jackass would come along, upload some photos, then sue them for copyright infringement. Note that they only sell the photos at Content Owner's direction.
Somewhat similar with facebook. If you write on someone's wall and delete your account, the wall post will stick around.
Ultimately, the terms on Facebook or SmugMug or any other service say that you "own" your content. Unfortunately, they store it in a proprietary format which means that it's pretty much useless without their services.
Not sure I understand your first point. Dropbox isn't the only "filesystem" that's supported. S3, Cloudfiles or anything with an adapter is.
"Download all" is a good solution in your opinion? Maybe you don't have a lot of photos but that doesn't sound terribly useful to me.
Does SmugMug provide differential syncing (honest question)? My guess is no. Amazon S3 does.
I agree that every service has a gatekeeper when you're talking about the Internet. But in my mind decoupling this way buys you a tremendous amount of advantages at fairly low cost.
Hopefully the project gets funded and you can see how great the service is and how big of a problem it solves :).
Sorry if I'm not being clear ... SmugMug uses S3 for its storage [1]. DropBox also uses S3 for its storage [2]. They are, in essence, both layers/services built on top of S3 (albeit different types of services). So why support one but not the other?
Gotcha. In theory SmugMug could be supported as a "storage service" if they have the appropriate APIs.
It doesn't make a lot of sense to do that because SmugMug doesn't offer any compelling storage services on top of S3. Their APIs are (from a file system perspective) a subset of S3.
Dropbox on the other hand provides sync on top of S3 which could be a big benefit for some users.
Personally, I think S3 and Rackspace Cloudfiles make the most sense. They are as close to a raw file system API which exists "in the cloud". I mention Dropbox to showcase the flexibility of the idea and more people are probably familiar with what Dropbox is than S3.
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.
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.
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.
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!
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.
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.
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!
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.
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.
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.
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.
- 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.
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).
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!
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