Snapjoy (YC S11) is closing(blog.snapjoy.com)
blog.snapjoy.com
Snapjoy (YC S11) is closing
http://blog.snapjoy.com/2013/snapjoy-is-closing/
15 comments
Background Info:
Snapjoy was bought by Dropbox a couple of months ago: http://blog.snapjoy.com/2012/snapjoy-joins-dropbox/
The short timeframe to migrate your data is worrying given that Dropbox is supposed to be in the 'data saving' business- I'd hope they'd cherish user's data more than this.
Also sad that Dropbox isn't investing in a migration story, though I saw Google do the same thing with Picnik when that was shutdown.
Also sad that Dropbox isn't investing in a migration story, though I saw Google do the same thing with Picnik when that was shutdown.
I doubt if 30 days qualify as short-time for anyone to download their photos from a photo-sharing service.
It's most likely that users use this service from their smartphones and so it's not like they are somehow going to miss the notifications they will keep sending perhaps every week your photos are still on their servers
It's most likely that users use this service from their smartphones and so it's not like they are somehow going to miss the notifications they will keep sending perhaps every week your photos are still on their servers
> It's most likely that users use this service from their smartphones
So you're saying it's likely most of their users are completely unable to back up their photos at all? (since one of the top 2 smartphone OSes doesn't support downloading ZIP files, and the users of the other OS probably don't have enough free space on their MicroSD card)
So you're saying it's likely most of their users are completely unable to back up their photos at all? (since one of the top 2 smartphone OSes doesn't support downloading ZIP files, and the users of the other OS probably don't have enough free space on their MicroSD card)
Given that this is summer when many people are on vacation and have less or no Internet service and often the same for cell phone data service, which is famously limited anyway....
My aunt just went on a 3 month hiking trip through the country.
> "Though we won’t be accepting new signups, existing users can continue to use Snapjoy to share and enjoy photos just as you do now."
Not so much, I guess.
Not so much, I guess.
How long did you expect that to remain valid? They've trucked on for six months since the acquisition. Is there a reason to assume that statement was meant as eternally binding?
Well it's a fairly big jump from "First and foremost, don’t worry -- your photos are safe!" to "[In one month] all photos and data will be permanently deleted"
I can't imagine there are many uses who feel like snapjoy delivered on the sentiment of their "Snapjoy is joining Dropbox" post.
"Stay tuned, the best is yet to come" doesn't usually imply we'll give you 1 months notice and then delete all your photos.
I can't imagine there are many uses who feel like snapjoy delivered on the sentiment of their "Snapjoy is joining Dropbox" post.
"Stay tuned, the best is yet to come" doesn't usually imply we'll give you 1 months notice and then delete all your photos.
That would have been helpful information in the blog entry.
The post is for their users not for external discussion sites that require additional context.
Dropbox forced them into STFU mode.
Six months ago.
“After two years of building Snapjoy, the time has come for us to shut down the service.”
That is a really weird statement. Shutting down without offering any alternatives is not a normal thing to do for a software company. No word of why they’re shutting down, just ’the time has come’. No apology. Nada.
I had to read the comments in this thread to find out they were acquired by Dropbox.
That is a really weird statement. Shutting down without offering any alternatives is not a normal thing to do for a software company. No word of why they’re shutting down, just ’the time has come’. No apology. Nada.
I had to read the comments in this thread to find out they were acquired by Dropbox.
[deleted]
Anyone else feel like a month of warning before permanently deleting your data is cutting it a bit close?
In the summer, when plenty of people are on vacation, plenty without great or any Internet access....
Yeah, that occurred to me as well.
Each time such a service shuts down it puts another nail into this "put your stuff in the cloud" business model, as the absolute number of people who'd been screwed keeps growing, along with the people they influence.
Yeah, that occurred to me as well.
Each time such a service shuts down it puts another nail into this "put your stuff in the cloud" business model, as the absolute number of people who'd been screwed keeps growing, along with the people they influence.
Disclaimer: Founder of Trovebox / OpenPhoto
I still believe there's a lot of promise in "the cloud". It's unfortunate that these types of shut downs leave such a bad taste in people's mouths.
There is a way to do it though. Decoupling application logic from data storage basically solves this problem. If we (Trovebox) ever has to send an email like this it would be along the lines of "Our service is shutting down but your photos are safe where they are, you don't have to do anything. If you want to continue using the service here are the ways to do it on your own."
I still believe there's a lot of promise in "the cloud". It's unfortunate that these types of shut downs leave such a bad taste in people's mouths.
There is a way to do it though. Decoupling application logic from data storage basically solves this problem. If we (Trovebox) ever has to send an email like this it would be along the lines of "Our service is shutting down but your photos are safe where they are, you don't have to do anything. If you want to continue using the service here are the ways to do it on your own."
What kind of API do you see as valuable for something like that, disconnecting the ownership and control of data from stewardship? Can you see a design for something that would applicable to other products, whether it was built on S3 or a new shared data source, distributed solution, opaque data protection, etc. Would Firebase supporting API keys that can be delegated by the data owner, rather than the application provider, be a solution on the transactional/database side?
I started thinking more about this following Fred Wilson's post on how this is happening in the investment community, as well as his vision for the future of VC (as I understand it).
http://www.avc.com/a_vc/2013/06/decoupling-advisory-from-cus...
As I mentioned on comments there, I'm working on a concept in a different area but with the same fundamental pattern, which I see emerging as we desire more ownership and control of our assets, and permanency of data and other resources. I'm also working on a blog post about this.
I started thinking more about this following Fred Wilson's post on how this is happening in the investment community, as well as his vision for the future of VC (as I understand it).
http://www.avc.com/a_vc/2013/06/decoupling-advisory-from-cus...
As I mentioned on comments there, I'm working on a concept in a different area but with the same fundamental pattern, which I see emerging as we desire more ownership and control of our assets, and permanency of data and other resources. I'm also working on a blog post about this.
Not sure I understand exactly but I'll take a stab at answering.
For us, the API needs to simply abstract how and where data is stored. The same API works for any supported storage service.
We've open source large parts of our code and that falls under the "stewardship" banner. We act as a broker but make it as simple as possible if you want to be the broker yourself.
For us, the API needs to simply abstract how and where data is stored. The same API works for any supported storage service.
We've open source large parts of our code and that falls under the "stewardship" banner. We act as a broker but make it as simple as possible if you want to be the broker yourself.
Thanks for the reply. Do you have a Github repository or some other URL for this code?
Sorry for the confusion, but by "stewardship" I meant that you maintain or manipulate the data but do not control the place that is stored. I could have chosen a better word.
This new model needs clearly defined terms for these roles.
Sorry for the confusion, but by "stewardship" I meant that you maintain or manipulate the data but do not control the place that is stored. I could have chosen a better word.
This new model needs clearly defined terms for these roles.
How can that work and still provide unified billing while you're in operation. E.g. let's say the photos are stored in S3, would they either have to pay bills to both Amazon and you, or switch to a smaller bill from Amazon upon your demise?
The other problem is of course that very few of these companies do that sort of thing as far as I know (which I wouldn't, particularly, seeing as I only use rsync.net for off-site safety (http://en.wikipedia.org/wiki/2011_Joplin_tornado) and otherwise use local disk plus LTO tape with a full backup always in a safe deposit box).
The other problem is of course that very few of these companies do that sort of thing as far as I know (which I wouldn't, particularly, seeing as I only use rsync.net for off-site safety (http://en.wikipedia.org/wiki/2011_Joplin_tornado) and otherwise use local disk plus LTO tape with a full backup always in a safe deposit box).
There is no unified billing at the moment. Not sure that is desired though. Decoupling payment is part of data ownership.
Remember that we provide storage as well. There is unified billing that way at the cost of data ownership. This coupled with the ability provided to migrate to another storage provider is as good of a solution as possible today.
I hope this gets better in the future as I realize it is not ideal. But it is at least headed in an interesting direction :).
Remember that we provide storage as well. There is unified billing that way at the cost of data ownership. This coupled with the ability provided to migrate to another storage provider is as good of a solution as possible today.
I hope this gets better in the future as I realize it is not ideal. But it is at least headed in an interesting direction :).
How is customer acceptance going? Me, I'd love such a thing, but ... well, you may be ahead of your time, but I suppose at least one of your unique selling propositions is that you aren't like the other "cloud" vendors, and the more the others screw over their customers like in this example the stronger that proposition will be.
A friend of mine who has a fist full of patents on basic hard drive technology, including several in every hard drive you own, has a maxim that goes something like this: "When you buy a hard drive you should start planning for its death and the loss of all your data on it." The popularity of various backup services, especially in the face of strict data cap regimes outside of Verizon, suggests that plenty have learned this lesson, which I would assume also helps your case.
Anyway, it sounds like you're doing a very good thing, I wish you the best of luck!
A friend of mine who has a fist full of patents on basic hard drive technology, including several in every hard drive you own, has a maxim that goes something like this: "When you buy a hard drive you should start planning for its death and the loss of all your data on it." The popularity of various backup services, especially in the face of strict data cap regimes outside of Verizon, suggests that plenty have learned this lesson, which I would assume also helps your case.
Anyway, it sounds like you're doing a very good thing, I wish you the best of luck!
We've had good adoption but it is TBD if there's a big enough demand from the consumer market.
However, our architecture opened up other interesting opportunities which we'll be announcing soon.
Have a look at the University of Southern California Digital Repository. They have system for long term digital preservation. They discard any storage media after 3 years and continually check for "rotting" of files.
However, our architecture opened up other interesting opportunities which we'll be announcing soon.
Have a look at the University of Southern California Digital Repository. They have system for long term digital preservation. They discard any storage media after 3 years and continually check for "rotting" of files.
I wanted to tell you this the last time you submitted to HN, but don't you feel the photo of the child on your homepage portrays a cold, zombie-esque feeling?
I don't know if it's deliberate but it hardly made me felt welcomed
I don't know if it's deliberate but it hardly made me felt welcomed
Obligatory XKCD: http://xkcd.com/1150/
That XKCD assumes the person actually got the message, in which case a month is fine.
Sending an email doesn't cut it on this short of a timeline.
The really weird thing is they had seven months to tell people about this deadline, and waited until six of them had passed.
Sending an email doesn't cut it on this short of a timeline.
The really weird thing is they had seven months to tell people about this deadline, and waited until six of them had passed.
Why do you assume the decision was made upon acquisition? Things change.
Everyone who follows tech startups saw this one coming. This was a clear acquihire. My company was in the process of acquihiring. We knew from a mile away that they didn't give a crap about continuing the development our product, despite all their promises. We ended up declining (none of us wanted to move to the bay area).
Oh they might have procrastinated but the decision should have been made around that time. It's not an excuse to say you wasted so much time deciding how to shut down the service that people need to get out out now now now.
You give them one more user, which is worth a lot when a software company negociates its value before a buyout.
Hence why you should only use these type of services for backups (or also syncing), not as a primary storage mechanism.
Or, from the opposite perspective, my hard drive is a backup for my Dropbox account.
Or, from the opposite perspective, my hard drive is a backup for my Dropbox account.
[deleted]
Why isn't there an automatic migration path to Dropbox?
Did Dropbox buy Snapjoy or did the team decide to join Dropbox because their product was not working out?
Perhaps a one-click migrate-to-dropbox option is in order?
perhaps if the Snapjoy folks were in a better position to collaborate with these Dropbox people.
maybe they can reach out on LinkedIn or something.
maybe they can reach out on LinkedIn or something.
I have been expecting this to happen after the Dropbox acquisition. I'm a big fan of Snapjoy but not looking forward to downloading all the data only to re-upload it to Dropbox.
Clearly they don't give a shit about their users.
Data in the cloud might be safe from disk failures, but not safe from acquisitions.
Anyone looking for a place to migrate their library, I recommend Everpix -- at least until they are also acqui-hired. Flickr, too, is looking much more attractive with their revamped free tier, and is certainly likely to be in it for the long haul.
Yah, after convincing my daughter it was the way to keep her photos from filling her iPhone she gets a message from the app today saying this. She's in a panic of course about it.
And as one last slap in the face, it's 8 separate downloads!
And as one last slap in the face, it's 8 separate downloads!
Once again Archive Team has a job to do.
I'm guessing this isn't serious. But if you are, I'm pretty sure most of the data on Snapjoy is private rather than public.
Doesn't mean we aren't looking at it, we are :)
I must say, it's like a superhero movie.
This one really has me scratching my head. I always assumed that Snapjoy would merge into Dropbox's photo system, but I also assumed that they would give users the explicit option to port over their accounts to Dropbox.
Customer acquisition has always been the name of the game for Dropbox, this seems like a missed opportunity to bring over a good chunk of committed users.
Customer acquisition has always been the name of the game for Dropbox, this seems like a missed opportunity to bring over a good chunk of committed users.
> Customer acquisition has always been the name of the game for Dropbox, this seems like a missed opportunity to bring over a good chunk of committed users.
Have you considered the fact that perhaps there was no customers to acquire in the first place?
I couldn't find the app in the appstore but a Google search for "itunes snapjoy" showed that the app had only being rated with 7 votes.
Have you considered the fact that perhaps there was no customers to acquire in the first place?
I couldn't find the app in the appstore but a Google search for "itunes snapjoy" showed that the app had only being rated with 7 votes.
"What's Snapjoy? We're building the smart photo library in the cloud"
s/We're/We were
s/We're/We were
Bummer. Was it really costing Dropbox a lot to keep the service? From the aquihire blog post in December, I got the impression there never was an intention to keep things running.
Lacking easy migrate support, at least the export option exists.
A sad day. Big ups to Michael, JP, and the rest of the team. Snapjoy, RIP