But still, I just started using Firebase, and this news makes it clear to me that I should move off them as soon as I can. Firebase was an interesting technology supplier: When they were a small company, I could count on it that as a customer, I would count. Google is known to not give a damn about paying customers (ref: all the Google Apps customers who lose their email (for whatever reason) and get redirected to a FAQ page with answers to unrelated questions). Google is also known to Be Evil: I'm not sure I dare waiting until the terms change such that my user's data is subject to googlebot scanning.
Firebase's business model is aligned with my interests: the more users I have, the more I (hopefully) earn, so the more I pay Firebase. I strongly doubt, however, that Google is buying Firebase because they think they can get very rich selling Firebase subscriptions. It's either going to turn out a acquihire, or it is some part of a grand ecosystem plan. Acquihire means they'll pull the plug sooner or later, grand ecosystem plan means vendor lock-in. While I'm happy to be locked in to the services of a small independent business, I'd think twice before becoming entirely dependent on a company that could lose me as a customer and not even notice the slightest impact on their bottom line.
I know all of the Firebase guys are reading this, and I don't mean to piss on your parade. I'm certain you're not lying when you say that things are only going to get better. But I'm also certain that your jobs don't depend on that anymore, and when higher-ups decide to move the big boat's direction, Firebase might be over sooner than any of us wants it to.
That's a pretty big risk to take as a startup that fully depends on Firebase for their data storage.
Startup dilemma post-acquisition: "they're no longer in control! how can I trust they'll be around in 12 months!? so risky!"
No one wants to run yet another cluster, but anyone with an eye to business continuity ought to want the assurance that they can migrate to and from their own servers if that need should arise.
That might not be in the short term interests of Firebase, but it's definitely in the long term interests of their customers. Why would anyone ever base the future of their own business on the exit needs of another company's investors? It is a ridiculous risk. As much as I love what Firebase has built, I'd never use it for anything more than a toy project for that exact reason.
Basho, ElasticSearch and Docker(?) seem to be on a good path with commercial open source models. Is there any reason that a startup like Firebase couldn't do both? Offer their open source product as a service with non-critical value adds? GitHub is another example that comes to mind. If they were to get bought and shut down, it would be a pain in the ass to set up new remotes, but no one would have to stop using git.
For my applications in healthcare I'm often forced to use in-house servers.
It is also available in Debian jessie.
What to do?
Google could resolve that by both hosting Firebase and open sourcing it. That way, you could outsource the critical Firebase management to Google and not have to build it yourself, while still having the security of knowing that if Google ever made it unavailable (shutting it down, worsening service, raising the price, etc.), you wouldn't be wiped out.
They already offer hosted database service for other OS databases. I hope they'll do the same with Firebase.
All of these are 100% open source and interoperable.
You could also use filtered replication but it is:
a) not scalable
b) not secure (the whole db would still be accessible to all users)
Couchbase has a different spin on this via "channels" though I'm not sure how it interoperates with PouchDB.
Forcing an open source on acquisition severely limits your exit options and lowers your acquisition value. In terms of the companies you've mentioned with commercial open source models, none of them are clear successes. All still have battles to fight. Open source is a really hard path to take, and it's littered with dead companies and zombies who's revenues have been cannibalized by their open source creations.
As much as the users feel like startup founders owe them something, startup founders are human like everyone else. They don't exist to be our slaves. Imposing rules like this on companies would result in fewer tools and companies overall as the companies themselves would no longer make economic sense.
Most people start companies because they love what they are doing, want to make an impact, and to make a good living.
An interesting study would be whether open source startups are doing any better or worse than closed source companies. Do you have any links?
It's not impossible to build a business around open source, but it's incredibly hard. Take MySQL for example. MySQL's initial pitch was this "We'll destroy 50% of the DB market, and then capture 25% of the remaining market." And MySQL the company never really made it. This is with arguably the largest pure technical market to ever exist (databases).
As a founder, I am in a startup's shoes, and my intention was not to provoke an angry mob, but merely to state my own opinion. I don't want to use Firebase for anything my own revenue will depend on, and that's a shame, because they have made an awesome product.
> Forcing an open source on acquisition severely limits your exit options and lowers your acquisition value.
These acquisitions of 3 year old companies are always sort of disappointing to me. On the one hand, I'm truly inspired and encouraged see their measure of success. On the other hand, I'd really like to see more startups committed to building lasting companies that strive for win-win outcomes that include users, employees, investors and founders. This isn't supposed to be a zero sum game.
> As much as the users feel like startup founders owe them something, startup founders are human like everyone else. They don't exist to be our slaves.
With a company like Firebase, there's a chain of trust that's really important. They are not responsible for just their own individual users. They are responsible for other companies' users. The effects of everything they do are multiplied accordingly.
Part of offering a platform is the guarantee that "this thing you depend on to serve your users will not go away unexpectedly without leaving a viable alternative." That's not an unreasonable thing for someone to demand when they're building their house on your foundation. Their use of your service also represents an investment of their own developer time. You go away, they lose that investment. If you as the operator of a platform don't want to take on that level of responsibility, don't go into that business.
> Imposing rules like this on companies would result in fewer tools and companies overall as the companies themselves would no longer make economic sense.
Who said anything about imposing rules? You're putting words in my mouth.
There's a trend to throw VC money at open source force multipliers: http://words.steveklabnik.com/is-npm-worth-26mm
This isn't perfect and it contradicts my point about wanting to see sustainable companies, but I find it encouraging nonetheless. I think Firebase could have easily fallen into this category.
I'm trying to point out that there is a very large number of companies where open sourcing on acquisition doesn't make sense. And there's also very serious financial risk to founders if they choose to adopt this idea. The way you've stated this suggestion, I'm afraid unsuspecting founders will adopt this policy and shoot themselves in the foot a few years down the line.
I draw a lot of this from personal experience. I just sold my company a few months back, I currently work at an open source company (which you've already mentioned as one of the "model" OSS companies), I have first hand experience with a company getting acquired that had this "open source" clause a few weeks back, and I'm also heavily involved in the due diligence process for many tier 1 VCs that look to invest in the infrastructure space.
Having been through all of that, I can say that my personal outcome would not have been possible had I had the "open source" clause for my company, and we would have needed to pivot hard. The company acquired with this clause lost a vast majority of its acquisition value because of this "open source" clause. It's basically become a talent acq. And from doing due diligence/working at an OSS company, it's become clear that most founders SEVERELY underestimate the challenges in building an OSS company. It's a double edged sword. And it's one where arguably the edge facing you is sharper than the one facing your market.
I think you're undersstimating the added value – the point is that people don't have to bother setting up and maintaining all of those moving parts with a service like firebase.
Case in point, I was building a small real-time web serice this weekend; it's exactly the sort of thing that Firebase would be great for. But given that I couldn't run it locally, and that there's no migration path if they were to acquired and shut down, I had to implement a half-assed solution on my own. If Firebase had been open-source, I'd almost certainly have ended up forking over cash for them to host it anyway.
Just, for my situation, I am not sure why I need to pay for that functionality when I can literally set it up in one day vs reading the documentation on how to set it up on Firebase in the same time.
I also control all outcomes and avoid ones like this where Google could potentially take over control of a large portion of your app.
My server side code is about 100 lines. This controls a chat server, chat rooms, youtube video commands. And its currently working just fine with 4,000 visitors a day on a vps that cost $5 a month.
Why not learn how to do it yourself? Especially if you already have vps. I am using varnish with multiple sites and it took a couple hours to set up. I am really confused on this.
1) Full user management services, including registration and password recovery
2) Extremely fine-tuned access control per resource
3) Complete, tested front-end libraries for AngularJS, Backbone, and other popular frontend libraries.
4) Much more reliability than socket.io in providing cross-platform, cross-mobile real-time messaging (believe me I've used and tested socket.io). socket.io may or may not work on a given platform, and it's no longer a very active project, either.
5) Full admin panel for database, including real-time data updates.
Look, for a chat app, you're absolutely correct that Firebase may be overkill. But very few of us that rely on Firebase for applications are limiting ourselves to chat apps.
That said, I'm not happy about this acquisition. And this is probably the last time I'll be burned like this by a PaaS company. I saved a lot of time by going with Firebase (much more than 100 lines of code) but I'm questioning whether it was worth it.
PS: I didn't downvote, although I was tempted after reading your "Why not learn" remark. I think you're right in the end that open source is the best solution, but you're very wrong to assume that people are using Firebase because they can't quite figure out how to make a 100-line Node app.
Also, check out the number of issues, some of which are pretty significant (although there are tons of ridiculous ones there, too). But if they're catching up -- and they appear to be -- that's great. It's a great project.
Firebase has solved many harder problems than you and I are ever likely to have to deal with and they deserve full credit for that.
There has been lots of movement with the bigger release but nothing that has interested us in going back to it.
We've only needed to handle concurrent connections in the 1-10k range though.
There are really better c++ and erlang implementations we've investigated but won't pull those off the shelf till needed.
Obviously there's loads of great realtime-as-a-service offerings like Firebase and Pusher that make sense for a lot of use cases, just not ours.
We were always uncomfortable with relying on a third party for a core aspect of infrastructure, and this acquisition introduces uncertainty that we don't have to worry about.
 Poxa: https://github.com/edgurgel/poxa
Something I think would make this even better, is if the pledges were standardised, so they followed some mutually agreeable guidelines. I had a go at doing this here:
I have it in place on my app (https://nachapp.com), and plan it include some/all of the pledges on future products I launch. Haven't yet come in contact with any other founders who are up for including it on their product... but if you like the idea and want to help improve the draft (even if it's just for the "long-term service" pledge), feel free to get in touch.
They just need to safeguard the code drops and execute the transfer at the proper time. Like reading a will.
It's less than ideal, but it is usually extremely low on the list of priorities as well as virtually untestable, unless the business model involves a large number of functionally identical VLAN's.
Also, names of people are usually not very strongly attached to products.
How many application variables are hard-coded to your company's specific network and server configuration?
Have you fully documented the configuration of every related server, checked that in, and kept it up to date?
Are the required versions of every dependency well documented?
Does it use any third-party packages that you have modified, but never checked into your source control?
Is any part of it dependent on some massively expensive piece of software or data set that you happen to have easy access to for some reason?
"One thing we do want to make clear: Svpply is not going away. We’ll continue to bring our users new products each day"
And as dotBen posted, from their blog:
And if you follow the comments you'll see that some believe that these promises aren't even meant to be long term. So, simply, we would be stupid to bank on it.
Congratulations to the team, though! It shows a great and determined effort, something I greatly admire. And hopefully a means of maintaining trust will emerge.
But that's just the same incentive for a company to continue providing the same level of service after being acquired.
The couple of small companies that I have worked for that had such a pledge took it seriously. They would hand source for every release over to an escrow company ensuring availability after company death.
I know that the acquirees are saying otherwise in this case (and Google is surely saying the same to them), and they might be right this time, but "nothing will change" is virtually always the line, until it suddenly isn't.
FWIW, I'm not even knocking Google (or Firebase) for this state of affairs; just noting that anyone paying attention will have seen this play out dozens of times in a way that is unpleasant in the medium to long term for anyone relying on the acquired company's technology.
Not under the control of the customer, obviously.
We are developers and you are developers, and we're all trying to work towards making cool things :) I don't see that changing any time soon, everyone from in Cloud from Urs down gets it. We have to earn your trust, and we do that be providing the best product we can, interacting in communities directly, providing great support, and not creating vendor lock-in. I wouldn't work on this team if we didn't do those things, because I believe in them as being necessary parts much as you do.
 I can't speak to the rest of the company because I don't have experience with it, but I had very good support experience with Play too, so it's my hope that support in general at Google has turned a significant corner in recent years.
So, when my Google Apps is down, I don't want to geek out and talk to an engineer on the various technical issues. I want it back, up and running asap.
Speaking as a former Google Cloud customer (App Engine), while I had my gripes, the one you cite wasn't one of them. They already provide what you're looking for in my experience.
Who's "we"? You, an honest guy, I'm willing to trust. But not Larry nor whoever the next CEO will be.
Where the buck drops is where mine won't cuz the other guy is your boss.
Just in case any Googlers are reading: you have a contact form for adsense questions that rejects my email address because my real name has "Cocks" as a part of it.
Fully depending on any third party for any important part of your business is a risky strategy. If you're contracting out something as core as data storage, you'd better have a good plan B regardless of the provider's economic situation.
I don't believe that claim, especially nowadays.
That said, if I were using Firebase I'd be concerned, too. Google is well known as a place startups go to die, or morph into something The Borg wants rather than something aligned with the startup's original vision and the expectations of their paying customers.
Good luck and godspeed!
Er, versus fully depending on a startup that could run out of money or be acquired at any time?
I want to take this opportunity to personally say thank you! The community here has been instrumental to our success. You’ve been our supporters, beta testers, fans, and critics. Even the comment threads here have been a valuable source of feedback :)
I want to reiterate a point that James made in the blog post: Firebase is here to stay, and it’s only going to get better at Google. Our entire team is joining Google, and James and I will continue to run things day-to-day. You’ll still see us around the tech scene at meetups, conferences, and hackathons, and we’ll still be active here and on Twitter.
Thanks again -- big things are coming!
Who has the final decision about whether Firebase continues going forward?
If you do not have either of these, how can you be sure "Firebase is here to stay, and it’s only going to get better at Google."?
I hope they will improve integration with AngularJS while not dropping support for Ember and other third party integrations.
Look at their Google Play services: Android and iOS get realtime, and web is relegated to using a REST API: https://developers.google.com/games/services/
To me that's a huge hole in their services currently that needs to be remedied as the realtime web becomes more pervasive.
If Google discontinues it yet incorporates the technology into their own products/platforms that is still a loss for developers who use/would have used Firebase.
I'm curious if that is written contractually, specifically in the deal that you made. Is it? If so exact what is the wording in the contract?
I realize the intentions are good and I'm actually glad for the team, but I started taking a more realistic view towards these kinds of statements.
Firebase is awesome, keep up the great work!
R> firebase <- data.frame(Product="Firebase", Dead=FALSE, Started=Sys.Date(), Ended=NA, Type="program", Profit=TRUE, FLOSS=FALSE, Acquisition=TRUE, Social=FALSE, Days=1, AvgHits=NA, DeflatedHits=mean(google$DeflatedHits), AvgDeflatedHits=NA, EarlyGoogle=FALSE)
R> conditionalProbability(firebase, 5*365.25)
While I would have my concerns about going with Firebase after a Google acquisition, shutdown isn't one of them. They're clearly investing tons into the Google Cloud Platform, pouring resources into things like App Engine. Google also just seems to love competing with Facebook, which now owns Parse - the top alternative to Firebase.
Your analysis is probably worth more though ;-)
My guess for Firebase is 25%. Why? Because I don't see this making enough profit and social value is low. Just a guess though, then again I'm wrong a lot, so it should be interesting looking back on your stats (Bookmarked).
AngularFire has always been one of the most amazing things about Firebase. So much so that I decided to build my business on it (https://www.angularcourse.com). Misko (Angular creator) himself has said that 3-way binding with AngularFire was the closest to fulfilling his vision of what Angular should be.
Also more than the technology, Google's getting a company that really cares about the developer experience and knows how to design developer products. This is improving but still really lacking in the Google Cloud product line.
Firebase is one of those products that really gets you exciting about programming. Many people have told me about how they were amazed the first time they saw real-time updates in Firebase forge. I know I spent an embarrassing amount of time watching the colors change (green, red, orange) in Forge too.
Here's his blog post about the topic:
"<angular/> provides the database hosting as a service so that your <angular/> application does not have to worry about it."
"The cost of building security and authentication into your web-application is often overlooked when building web-applications. <angular/> offers both out of the box."
i really hope firebase doesn't get broken up or otherwise disappear into the goog.
and congrats btw!
I'm curious to see how this wraps up into App engine though. Currently there is a web routes hack to get angular to send/receive to datastore, but it's not very robust.
Probably none. Angular is part of Ads, they're not in the Cloud group.
Does anyone know of a good Firebase alternative which is either (1) still independent or (2) run by a company with a reason to maintain it?
You can use Cloud SQL, Cloud Storage, Datastore, Compute Engine, App Engine, BigQuery, DNS, and all the APIs á la cart, and I'm sure the same will be true of Firebase.
In case you don't know, the APIs that used to be bundled with App Engine back when it was the only cloud product, like Datastore, have been unbundled over time. I assume remaining App Engine-only APIs like cron are under consideration for unbundling, but there's no precedence for an already unbundled API being bundled to App Engine.
https://parse.com/ - freemium
http://backendless.com/ - freemium
http://www.kinvey.com/ - freemium
http://deployd.com/ - open source
http://firehose.io/ - open source
http://www.baasbox.com/ - open source
https://www.meteor.com/ - open source
As for the open source solutions, I specifically want to pay someone money to solve this for us. We've been running ShareJS, but it's annoying to maintain and fix.
If you want to add realtime to an existing project that already has a database, then I suggest checking out Fanout ( https://fanout.io/ ). We intentionally don't want to own your whole stack, and we've opened our code and protocols so that you're never trapped. Would love to get your feedback.
http://www.socket.io (open source)
Usergrid enterprise-grade hosting and support provided by Apigee (as API BaaS): https://developers.apigee.com/get-started
Once google pulls the plug, we (the community) want to be ready with open-source alternatives.
(oh and, James and Andrew really deserve it. they did good!)
Lately, Google has been rolling out one-click installs for Redis, Cassandra, RabbitMQ, etc. I had to read comments on HN to understand that this is a financial integration rather than merely a technical one. What strange and evasive messaging... why not just announce that the company has been purchased?
I noticed the exact same thing when I read the announcement(s) -- both Firebase and Google were very specific in saying that "Firebase has joined Google", not "Firebase has been acquired by Google".
So I'm guessing it means exactly what it says -- the Firebase team has been hired by Google and the product is now a part of Google Cloud Platform.
It's been incredible to watch Firebase grow from a glimmering James' and Andrew's eyes. It seems like just yesterday a few dozen of us were all huddling around in a board room being onboarded for the beta.
Excited and optimistic for the future of Firebase :)
Looks like every new exciting app/platform eventually gets acquired or acquihired by the big fishes. We are all moving towards large monopolies in the internet world. I was thinking of using firebase but I am not sure anymore. Google just does not have any customer service.
Regardless congrats and best of luck!
Disclaimer: Engineer on Cloud SQL team
At the same time, I can't wait to see what the future of AngularFire holds!
If they shut it down and I have to rewrite all the stuff I've built with it I'm going to freak the fuck out.
Is there some market explanation for why this tends to happen?
Even so, it's no secret how conflicted they are about "Docs". It's gone through what, 3 major rebrandings in the last five years ("Drive"? "Docs"? "Apps"?), plus it's more of a traditional, old-school enterprise sale, which means salespeople, budgets, big complicated custom integrations, security policy, etc., all things I don't see as Google's core strengths vs. traditional enterprise vendors like Oracle, Microsoft, etc.
In any case, "GCE" as they're calling it (Google Compute Engine) might be Google's fourth billion-dollar business. Mobile is a huge thing: there are tons of phones sold every day, developers love it, but it's still too hard.
I imagine the GCE execs faced a build vs. buy decision for "the thing that'll make mobile development easier", push notifications, and a handful of other use cases Firebase has really nailed. So given the choice between (1) building something in-house, which means they're years behind, have to build a brand from scratch, understand the problem space, and recruit the right team vs. (2) write a big check, it's not a very hard choice IMO.
Source: I lived with a firebase employee, I work in a company that GCE's sales team has visited, I spoke at AWS reinvent last year, and I built a venture-funded company on Google Apps.
EDIT: I guess it's not correct to say it's just Adwords and Adsense anymore, but it's still 90%+ advertising, and having some diversity there would go a long way (see child comment)
I think EC2 happened because Amazon expanded by building data centers. Whenever they finished a new one they found they had a lot of surplus hosting capacity that they couldn't monetize.
So EC2 was useful because the capacity was just sitting there.
Google always had ideas for new services. So they saved any extra capacity for experimental products or tried to sell it through Google App Engine.
Great recount by an old time employee: http://glog.glennf.com/blog/2011/10/16/the_true_story_of_the...
Totally opposed to Amazon's, GOOG's DNA has never been about serving customers directly.
I foresee their cloud offerings, including Firebase -- to the extent they'll let it run, to continue being tolerated stepchildren.
Even a cursory reading of any of Google's earnings statements disproves your first sentence.
The tough part for companies like Google is maintaining that momentum by letting the founders of the project maintain control and move forward without marketing or bureaucratic red tape killing it, something Google has been really good about in the past.
Just tweeted this yesterday : "Docker = future of IT infrastructure, Firebase = future of product focused companies running circles around competition" and today Firebase announced Google acquisition
Love it, big congrats!
Preferred stack now for app development would be Angular JS + Firebase + Go on Google Apps Engine for triggers/additional logic I guess
Previous HN discussions: https://news.ycombinator.com/item?id=7767765 / https://news.ycombinator.com/item?id=5514284
Disclosure: Hoodie core dev here.
*) Not in legal sense, obviously, but as a fact who handles storage and transmission of the data.
After that I decided not to become a customer of theirs.
Still loving the name "Plankton".
My watch can sense my body and ambient temperature, which tells Nest the optimum temp for my house and my phone can tell Nest my proximity to my house so it knows when to turn on. Shit just got real! Congrats to the Firebase team.
Cash and equity. Corrected the next two paragraphs for you.
Interesting: when I try to post that link as a URL the submission is '[dead]' on HackerNews. Why?
I'm also going to detach this subthread and mark it off-topic.
(p.s. I don't mean 500 literally. It's a stand-in for "the number at which I snapped".)
I probably should read the HN FAQ again - its been quite a long while.
Because it's a site calling out the user-screwing acquisitions that Y-Combinator exists to make money from.
Basically, it's a cargo culted phrase in acquisition announcements.