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).
If you want data sync capability and you prefer to run your own databases, Couchbase Lite is an open-source iOS and Android JSON database that syncs with Couchbase running on your servers.
"Thank you, our customers, for believing in us." is such an obnoxious and insincere statement. If anything, their customers only went with them because StackMob gave assurances (or at least the impression) of stability. I wish they were just upfront, sincere, and a bit apologetic.
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.)
I worked at a PayPal acqui-hire. For a while, it was pretty good! We suddenly had EBAY RSU's instead of maybe-someday-money and the work didn't change (as the mothership decided what exactly to do with us). That lasted about three months, after which our product got spiked and we were tossed in on very PayPal-y projects.
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.
Same happened to me somewhere else. My advice for these situations is ASAP or GTFO the acquired unit. ASAP, lateral into the larger company if that's the kind of place you think you want to work, or GTFO the whole place whenever you feel like it. Regardless, get away from the acquired company so you don't become deadwood.
The solution to this is to get more cash instead of equity, and don't stick around after acquisition.
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've always laughed at startups that offer me a big piece of equity in exchange for a lower salary. Why on earth would I want a worthless piece of paper in exchange for some very valuable pieces of paper?
"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."
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 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."
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?
Building a company requires skills that many, including myself do not have. You have to be able to sell. You have to be good with people. You have to be able to convince at least your friends to work on the idea with you. You have to have a good idea. And, you in the end you stop coding, and start worrying about business things. I like to code. I wouldn't mind owning my own business, but I haven't the skills and I haven't an idea so good that it would compensate for my lack thereof.
Also an opportunity for "concierge" service -- "Find/replace all instances of api.stackmob.com with api.example.com, and give us your credentials on StackMob. We'll take care of everything else. It's our thanks for signing up for our $500-a-month-until-your-business-dies plan."
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.
Sounds more like one should not use this kind of solution unless it's very temporary or one is building a quick prototype. What about businesses that relied on stackmob? welcome to the Baas area.
When I did my study on the BaaS providers last year, most of them were venture funded and not profit making and almost all of them were in the business for only a few short years. The only profit making / long term businesses that were into this space were Kii and Apigee App Services. The rest appeared to be candidates for acquisition.
> Thank you, our customers, for believing in us. It’s because of you that we’re able to move on, to rise to a new challenge, and to make a real difference.
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.
A lot of folks are writing that this is bad for employees. Is it worse for employees (who may have been sold a bill of goods joining) or worse for customers (who may have been sold a bill of goods signing up)?
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?
From the perspective of a non-paying customer who was testing out the service although not seriously considering it I am kind of shocked even though I know I should not be. This will damage all their competitors in BaaS. No way anyone with any sense would want to risk this sort of thing again, this confirms the worst fears of using service like this. Amazon may well be the winner as usual when custom solutions become more favourable again.
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 don't get why anyone in their right mind would invest in a Backend as a service. Ok, maybe things like image uploading, or what not, but not the entire back-end.
I am creating an app as a side project and this makes it a lot more manageable. It is my first time messing with web dev and would rather focus my time developing it instead of having to learn a lot of back-end as well. I understand where you are coming from though. I would like to learn back-end but I already have a lot to learn.
Do you feel that way about all acquisitions? About Parse? About Facebook? We've invested a ton of resources into Parse post-acquisition and continue to do so.
I can't speak for him, but having written stuff using the Facebook API, Facebook is not high on my list of companies to trust in a business context. [1]
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.
Thank you. If you're using Parse as a service, please read this carefully and think about the implications. I loved Parse until they were acquired -- great API and great documentation. Now I would never use them for a project.
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.
It's not that a service can't stick around post-acquisition, it's that in any company, you can have sweeping changes on the turn of a dime. One large senior management change and entire departments can get shut down or reorganized within a week.
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.
I've heard good things about Apigee. My understanding is that their backend-as-a-service is built upon the acquired and open-sourced usergrid technology, which leaves you the option of hosting it yourself in the event they ever go ahead and terminate their own service. That's not a bad out to have.
CloudMine[0] is also a BaaS company (Disclaimer: I work for CloudMine). We're focusing a lot on enterprise and making a robust system that companies can really deploy on.
If you have any thoughts or comments feel free to ask!
Disclaimer: I work for Kinvey on their development team.
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.
Well, if you are building a very simple system it's quite possible you don't need a backend at all. Our goal when designing the tool was to help people get an estimate of how much it does cost to build an app, hence we have some options that don't strictly point to backend features.
How about, "Pick your battles"? I agree that it's ideal to own something vital to your business or a product, but if you're trying to validate an idea and get something to market ASAP then outsourcing and/or using 3rd-party services can make a big difference. Trying to do everything yourself is a slippery slope. Related: http://en.wikipedia.org/wiki/Not_invented_here
I always took his statement to mean that if something is essential to your business, you should think very carefully about the risks inherent in outsourcing it. The two major exceptions to this are
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.
If you are trying to validate an idea, then building it on a 3rd party service is fine, because your riskiest hypothesis is not, "We can run a real business."
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.
curious to know how you can use http://baasbox.com and deploy it on EC2. It's open source and free, but I guess mobile developers don't like backend work.
Hi, we have just released a short tutorial on how to deploy BaasBox on EC2.
If you are already familiar with the Amazon EC2 you can skip the first part and go directly to the second one.
http://www.baasbox.com/baasbox-on-amazon-ec2/
baasbox looks interesting except for the fact that they apparently created their own custom database system. Why? Even if they wanted to stay within the Java ecosystem, there are so many good databases already available in Java.
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.
Oh wow, apologies for the misstatement. I glanced at the docs, features, and github, and didn't see any sign or mention of a DB dependency, so I assumed they had written their own.
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.
Our stance is that, as an app developer, you should not care too much about the technology behind a backend. You should rather stay focused on the front end.
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.
"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).