StackMob is shutting down
pastebin.com
pastebin.com
"When asked if StackMob will continue to operate as normal, he said it was too early to tell since the acquisition just closed today." http://venturebeat.com/2013/12/17/paypal-acquires-stackmob-t...
That was dead giveaway that they'd shut it down. We instead chose Parse for a project we were just starting, and it's worked out pretty well (except for the bugs they've been having the past week which don't allow us to create new columns or deploy).
thanks for reminding me why i'll never outsource my app's primary datastore. 'tis a bridge too far.
It's not a full app platform like Parse and StackMob, we are focussed on the data layer challenge.
Do the kind of people who work at places like stackmob, once their product has been killed, really want to work in other departments at paypal upgrading ancient systems?
(According to the article rradu posted this was why they were aquihired)
It seems like they would run away as soon as possible since they worked at a place like stackmob over paypal in the first place. (I assume there are some sort of retention bonuses etc to try and keep them.)
If you're looking to work as an employee at a startup to get rich, good luck with that. Early stage startups pay less than 50% of normal pay, and options are a fraction of a percent of the company. Unless the startup sale goes into 9 figures, which is probably less than 1% of all startups, you'll at best see a nice bonus. Later stage startups are just like big companies. With HR, managers, process, meetings, and the like.
I don't work at startups for money. I work at a startup for the small team size, for the massive impact you make as an individual, for the team building experience, the hard times and the good. You get to meet your customers, you get to see a feature you've built contribute directly to more people signing up. Being a software engineer at a small startup is the best job in the world, and it doesn't pay well. All the things I like about being at a startup are things that don't exist at big companies. So when the eventual acquisition happens, I help transition because I owe it to the team, but then I'm out.
I have that at a large company. My team owns a project, we have 3 devs, an architect, a QA, and a team lead.
We even get to meet our customers, though as it's an internal project, for another business unit, 'people signing up' isn't quite as meaningful. But you get to see people whose jobs suddenly become much easier and the excitement that can cause.
I would rather build my own company. Why would I want to toil my life away at a terrible wage and extremely long hours, only to get a fractional percentage of the payout if the company is bought out?
This is why I don't work at startups.
To answer your question: not really. Some of us found a niche at a place like PayPal, but a lot of us tried and weren't cut out for it.
My heart goes out to StackMob and its employees. Get paid.
Edit: It occurs to me that this is slightly complicated by the need to have API compatibility with StackMob, and I don't know the space well enough to know if anyone does that. In other PaaS businesses I'm aware that some companies maintain drop-in replacements for the market leader, because they make it possible to poach clients without asking for a $X00,000 rewrite.
I'm always happy when a company does well. But when a company's success isn't in the best interest of their customers, there's a fundamental disconnect. It is, after all, possible to advocate for existing customers during M&A negotiations.
In this case, their believing customers are now rewarded by having their software assets freshly encumbered by technical debt. What was sold as a solution is now a problem. So maybe it's just me, but it seems that the proper disposition should be one of apology, not celebration.
My sense is there is a little bit of "Let the buyer beware" on both because both employees and customers know what they're getting into with a startup. That said, the employees should at least get some stock out of it. Should early customers ask for stock too?
We will provide a migration script for former Stackmob users later this day, so getting apps back running should be a minimum pain. Also, to compensate for your lost time, you can get one month free medium plan with the voucher "stackmobOmat" :-)
I've seen a $1B public company start winding down a massive revenue-making division within the course of a conference call. Parse is a great service; I certainly hope Facebook doesn't do that and don't imagine they will any time soon, but nothing is impossible.
EDIT: And though you certainly know Facebook's internals better than we do, as an outsider, the risk of an acquired department shutting down is a lot higher if there's a potential to not part of the core business strategy.
The kinds of vendors I like to work with are ones that depend on satisfying people like me. For example, locally owned restaurants in my neighborhood are high on my list, because the owner is present and knows that his livelihood requires serving his customers well.
Personally, I'd never build anything critical with Parse, because Facebook's survival does not depend on satisfying Parse's customers. They could take a $90m write-down tomorrow and nobody would notice. If they did it during a time of adversity, analysts would praise them for "focus".
Another way to look at it is what it would take to kill Parse. My guess is that if any one of a few people left Facebook, the person replacing them could either directly or indirectly kill it off. You see that sort of project-killing happening all the time at companies during reorgs triggered by people leaving. It doesn't have to be a bad business or anything; as long as something doesn't match current strategy or vision or ROI goals or an exec's mood, it's at risk.
Independent companies, though, are much harder to kill: if a CEO took a profitable company and said, "Hey, we're shutting down in 4 months," the investors would find a new CEO. Shutting down a whole company requires the executives and the investors to all agree, so it happens very rarely unless the company is distressed.
[1] That sounds a little unfair. I trust them to be Facebook, by which I mean to act in the best interests of their revenue model as they currently perceive it. I just don't expect that to align closely with my interests, and think any mismatch between the two will be entirely my problem.
Plus, there's the whole Facebook data privacy issue. I've never seen a Parse representative state categorically that Facebook has no plans to data mine Parse customer data (i.e., your customers' data). And I know Facebook too well to trust my customer data to them.
If you have any thoughts or comments feel free to ask!
http://www.mobilechameleon.com/web-services-for-use-by-mobil...
Kinvey[1] is another BaaS platform with a pricing model based on users instead of API calls. We also have quite a few integrations, including the ability to run code on a pre-save/post-save on a different server if you so desired.
At the end of the day, there are a bunch of decent choices out there, it all depends on what features and pricing fit your needs.
http://www.kinvey.com/app-cost-estimator
When I fill in stuff it tells me it would cost the same and take the same time to DIY as to use Kinvey... so why would I use Kinvey?
Perhaps that's what has happened here? What options did you pick?
Ouch, that's probably the bare minimum they could've possibly done.
Partners and Customers who Trust StackMob
(Picture Fry meme:)
Can't tell if sarcasm, or sincerity.
1. Things which aren't essential to your business. (e.g.: things that could be replaced by nothing (even if just temporarily))
2. Things which meet the definition of a commodity, in the formal 'fungible goods' sense of the word.
Many .?aaS offerings fail both of these tests in that they're an essential component of a service, and also fail the commodity test in that there is qualitative differentiation between offerings. The features of EC2 (used to their fullest) are wildly different than those of Rackspace, and the two are only really fungible with one another across a small subset of their feature sets.
Examples of offerings that pass this commodity test include:
- Most mailers (sendgrid, mailgun, postmark, &c) when used simply. Switching from one backend to another isn't a huge endeavour, as they are all cut from conceptually similar cloth.
- VPS offerings when used simply (notice a pattern here?). A basic Ubuntu box in the cloud is a basic Ubuntu box in the cloud.
In contrast, Stackmob, Parse, et al. all fail this commodity test hard. Switching costs are very high (especially with Stackmob, whose iOS SDK bleeds anti-patterns all over your app), data migration is a nightmare, and major architectural assumptions can vanish in an instant
Part of the bargain of leaning on non-commoditized offerings to back essential services is accepting the risk that they may one day leave you in the lurch. In the metaphor of technical debt, outsourced services are extending you credit to finance your technical debt. Having one of your outsourced dependencies close up shop is really just them calling in their debts.
Of course, there's no right answer. I agree completely that the point is moot unless you ship; the GP wasn't really intended to be imperative; it was meant (or at least it was always how I understood it) as more as a heuristic to assess the risk associated with outsourcing a core dependency that can't be easily hedged.
But once you have validated the idea and are making a proper go of it, then yes, betting the whole of your company on some other highly risky company is generally a bad idea.
Basically, "never outsource something hard to replace" still applies, because early on you're happy to replace your entire business. If you have a few small customers and your vital 3rd-party service provider fails, then you say, "Oh well," accept that the customers are going to be pissed, and resign yourself to getting new customers. After you have rebuilt on a lower-risk platform, of course.
Just seems like a waste of effort just because someone wanted to write his own database software.
But deploying it looks like a snap. They have documentation on how to do this on their site.
Sorry to the baasbox db team for the incorrect assumption. But it might be a good idea to make the underlying db a bit clearer, assuming I didn't miss any obvious mention of it (which is quite possible).
orientdb is a fine db, indeed it's one I was thinking of when I was wondering (incorrectly) why they wrote their own.
Thanks for your correction.
What is the benefit of using proprietary platforms like Parse and Stackmob?
OrientDB was a clear win for me because it was open source and free while other Java Object databases had license fees attached in tiny letters.
The author of OrientDB was very helpful too on the google discuss groups. OrientDB included everything I wanted, SQL for POJO storage, server or file storage DB.
yum install java-1.7.0-openjdk scp baasbox-xx.tar.gz user@host:remotepath cd remotepath ./start
Next week we are gonna publish a specific tutorial on AWS.