Firebase is Joining Google(firebase.com)
firebase.com
Firebase is Joining Google
https://www.firebase.com/blog/2014-10-21-firebase-joins-google.html
240 comments
Startup dilemma pre-acquisition: "they're just a startup! how will I know they'll be around in 12 months?! so risky!"
Startup dilemma post-acquisition: "they're no longer in control! how can I trust they'll be around in 12 months!? so risky!"
Startup dilemma post-acquisition: "they're no longer in control! how can I trust they'll be around in 12 months!? so risky!"
I'd like to take that devil by the horns and strongly suggest that companies like Firebase, who clearly deliver a critical infrastructure dependency for anyone using their service, should open source their platform as an act of good faith toward their customers.
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.
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.
One company similar in services to FireBase is FanOut (fanout.io) and they share your open philosophy. Their server code is open source, and they make money by running it for you. I'm optimistic about FanOut and hope that they can be a success based on this model (and their service in general).
Looks fascinating. Setup of the open source version seems quite involved, are there containers I can use to try it out?
For my applications in healthcare I'm often forced to use in-house servers.
For my applications in healthcare I'm often forced to use in-house servers.
If you are using VMs in house, then an easy way to get going with Pushpin is to install Ubuntu Utopic and run "apt-get install pushpin".
It is also available in Debian jessie.
It is also available in Debian jessie.
This is a great point. Just running the infrastructure is a big enough value-add. I wonder how well this is working for Discourse. Obviously a very different type of platform, but they're using this model and appear, from the outside, to be having success.
I'd also be very interested to see how things are turning out for Discourse as a business. I've been keeping an eye on OSS product + hosted businesses for awhile (Ghost being another one now).
It's not just Discourse and Ghost. Wordpress has been doing this since way before those projects were started and there's no sign that they're going away any time soon.
Maybe Google could open source it themselves. A lot of us didn't want to risk much on Firebase, because who knew what might happen to a small company. With the acquisition, we are now in the position of not wanting to risk a significant part of our business on an insignificant part of Google's.
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.
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.
One interesting thing about the legacy of CouchDB is the sync protocol. There are now multiple implementations capable of syncing with each other, making it easy to migrate data to a different provider, even if the underlying implementation is different. I think there have been one or two forks and different service providers, and they can all exchange data without issue, as far as I know.
HTML5 - http://pouchdb.com
iOS, Android, .NET, Java - http://developer.couchbase.com/mobile
Hosted - http://www.iriscouch.com and http://cloudant.com
Original - http://couchdb.apache.org
All of these are 100% open source and interoperable.
All of these are 100% open source and interoperable.
This is exactly why I went for couchbase and decided to avoid firebase.
Assuming you use PouchDB, how do you avoid syncing the entire database with all users?
database-per-user is a common pattern with CouchDB. If you need to aggregate data across your users for reporting etc then you can use a server-side replication to create a "master" database which is only accessible to your internal users.
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.
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.
Couchbase Sync Gateway's channels are just slices through the data. The mechanism is internal to the Sync Gateway (you write a JS function that says who can see which channels and which channels a doc belongs to.) Replicating clients don't Need to know about this filtering, so channels work great with all flavors of Couch.
Before making suggestions like this and getting the HN bandwagon to support this POV, perhaps we should put ourselves in the startup's shoes?
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.
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.
> Before making suggestions like this and getting the HN bandwagon to support this POV, perhaps we should put ourselves in the startup's shoes?
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.
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 not trying to say your opinion is incorrect. Judging by your response, you took my comment a little too harshly.
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'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 didn't take it personally at all and if you have the time and inclination I'd love to hear more about your experiences. Please feel free to email me. smith at anvil dot io.
I was trying to respond to your pre-edit comment about fewer companies being started if we have such rules.
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?
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?
I don't have any links per say, but I have done extensive market research on this as it's a requirement in my job (I work at one of the aforementioned open source companies). A quick nitpick, regardless of what people publicly say to the press, I'm 100% positive that most companies are started with some financial motive.
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).
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).
Nevraeka(2)
The solution I've come up with is a pledge to release the source code if the product dies.[1] We've done this at Floobits, and it makes our users' lives less stressful.[2]
1. http://geoff.greer.fm/2012/09/19/a-responsible-product-sunse...
2. https://floobits.com/pledge
1. http://geoff.greer.fm/2012/09/19/a-responsible-product-sunse...
2. https://floobits.com/pledge
Nice to see someone else viewing pledges as a potential solution.
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:
https://github.com/jamesisaac/pledges
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.
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:
https://github.com/jamesisaac/pledges
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.
What good is a pledge? Once the product dies, there's presumably little incentive to abide by it.
I have worked at startups that people could believe would fail. We used source code escrow services that release the code to customers if we went out of business. Any of them would have been free to open-source.
Up-voted and seconding. I have worked at startups that have done the same thing. I think this is not an uncommon practice.
Any recommendations as to reputable code escrow services? I'd imagine there are some misbehaving players out there.
Never heard of a bad actor. I think you just choose a law firm, insurance company, big 4 accounting firm. That sort of company.
They just need to safeguard the code drops and execute the transfer at the proper time. Like reading a will.
They just need to safeguard the code drops and execute the transfer at the proper time. Like reading a will.
Little incentive? Even assuming sociopathic tendencies, it doesn't make sense to renege on the pledge and be branded a money-grubbing liar. The internet has a long memory, and people would not trust you in the future.
How about the pain-in-the-butt that is organizing, packaging, and releasing an organic network & development environment when you have other bigger things on your plate? I'm sure there are a few companies here and there with everything already nicely packaged. Yet, most places I've worked, it would be a herculean effort to pull the tangled jungle that is the internal network & development environment into one halfway-functional package.
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.
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.
Who said anything about organizing or packaging? Just put the code up on Github with a reasonable license and walk away. Running and maintaining is of course still a problem, but you can hardly expect a company that is out of business to do that.
"Just put the code up" isn't always that easy.
You may have the code, but there might still be a huge pile of problems. Such as:
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?
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?
I completely agree that open sourcing the project does not guarantee that the project will continue to function. I also think that after a company goes out of business they have no responsibility to keep their project functioning. Once they open source it, anyone is free to put in the work to keep it going and I can't think of a better guarantee a company could reasonably give.
Not to be a dick, but
"One thing we do want to make clear: Svpply is not going away. We’ll continue to bring our users new products each day"
https://news.ycombinator.com/item?id=7939934
And as dotBen posted, from their blog:
"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 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.
"One thing we do want to make clear: Svpply is not going away. We’ll continue to bring our users new products each day"
https://news.ycombinator.com/item?id=7939934
And as dotBen posted, from their blog:
"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 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.
> Even assuming sociopathic tendencies, it doesn't make sense to renege on the pledge and be branded a money-grubbing liar.
But that's just the same incentive for a company to continue providing the same level of service after being acquired.
But that's just the same incentive for a company to continue providing the same level of service after being acquired.
In general it could be taken as a legally binding statement so if they are bought out and shut down there would be an avenue to pursue with the new owners.
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.
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.
Yes, the legal route sounds at least plausible. I don't know if there's any precedent or how reliable such a contract could be made.
It's not plausible because insolvent / bankrupt companies have the option to walk away from onerous contracts if it is in the interests of the debtors not to honour them. In this case, the idea of open sourcing the software UPON bankrupcy could destroy any remaining value left in the business (value of IP) which would otherwise be realisable to distribute to debtors.
[deleted]
[deleted]
[deleted]
Why not just open source it from the beginning? :)
https://github.com/inboxapp/inbox/blob/master/LICENSE
https://github.com/inboxapp/inbox/blob/master/LICENSE
I know some folks at Basho where they do just that with Riak, a high-availability distributed database. It's not an unworkable strategy, and clients know the product's not going to vanish out from under them.
https://github.com/basho
https://github.com/basho
I prefer something enforceable in court.
Putting the source in escrow is a much better -- and more enforceable -- option than a mere pledge. This places the ability to release into the hands of a third party who is obligated to do so in the event that the conditions are met.
Being acquired by Google almost solves the dilemma in that statistically you can be nearly certain that whatever product or service a newly acquired company provides will be a dead project within 2 years.
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.
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.
Solution: "They're a stable, growing business that is profitable and intends to be in business for themselves for a long time! Not as risky!"
Not under the control of the customer, obviously.
Not under the control of the customer, obviously.
Good point. As a startup owner myself, I somehow feel more comfortable depending on startups than on BigCo's (hence the rant), but maybe you're right that that's more emotional than rational.
I'm an engineer on Cloud SQL. Support is much, much different from the wider Google reputation in Cloud[1]. We have a long leash to talk directly to people, and we do: Cloud SQL team, at least, monitors the google-cloud-sql tag on Stack Overflow and replies with help when possible. If you pay, you get telephone access to support reps who have a bunch of experience, and when they can't get something done themselves (rare), they can and do file bug tickets with the engineering team directly to get issues resolved.
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.
[1] 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.
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.
[1] 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.
I appreciate the hardwork you guys are putting in. But what you are saying is tangential to what parent wants. parent wants a committed vision/plan from google towards customer support. Allowing developers to talk to customers is all cool but what's required is commitment from google as a company to invest in customer support resources.
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.
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.
Google Apps !== Google Cloud.
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.
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.
We have to earn your trust
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.
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.
Isn't the same true of firebase as a company as well? Even pre-acquisition, all you need is for them to bring in an outside CEO who wants to monetize their userbase to screw things up.
That's pretty much true of any online service as opposed to software you control.
> 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).
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.
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.
Is it this[1] form? If so, I'll find the owner and file a bug.
[1]: https://support.google.com/adsense/contact/contactsales?hl=e...
[1]: https://support.google.com/adsense/contact/contactsales?hl=e...
We've had a lot of vendors, like Firebase, approach us at Poll Everywhere over the years. Despite how awesome they are as people, a company, and the huge problems they solve, I've always avoided it getting in bed with any vendor for something that I think is fundamental to a realtime web application. As a result, we developed our own realtime web framework at http://firehose.io, open sourced it under the MIT license, and made ourselves immune to these circumstances.
>That's a pretty big risk to take as a startup that fully depends on Firebase for their data storage.
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.
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.
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.
I don't believe that claim, especially nowadays.
I don't believe that claim, especially nowadays.
That's an excellent observation. I often feel that in the rush to acquisition the future of the product line can get lost. For example, one of the previous non-profits I worked with used myfamily.com for communications. Myfamily.com was bought out by Ancestry.com not too long ago, and progress on the MyFamily site - a completely separate but corollary product line - stagnated until they simply ended the product's run with just a few week's warning. After a while, when the acquired company's goals no longer apply for the new parent - or when they simply become too much of a hassle - they are simply left to twist in the wind.
Just an fyi in case you weren't trying to snipe on purpose, but there haven't been any data loss "issues" (e.g. stupid decisions by Google) with Apps for several years now.
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!
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!
> That's a pretty big risk to take as a startup that fully depends on Firebase for their data storage.
Er, versus fully depending on a startup that could run out of money or be acquired at any time?
Er, versus fully depending on a startup that could run out of money or be acquired at any time?
Would you purchase a company which was dependent on this Google service? Hmm, well Google might.
Hacker News -
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!
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!
Congrats on achieving your goal, it's always a good thing when people get to where they want to go. I'm not trying to be a dick with this: when you say "Firebase is here to stay" you have to be sensitive to history which shows that might not be an honest statement; you can't guarantee that if you no longer own Firebase. I think everyone appreciates your goal will be to keep Firebase strong and growing, but its future is not entirely in your hands.
Do you have anything in writing from Google giving a minimum support time for the Firebase platform?
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."?
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 have come to rely on firebase for a number of my projects, and I have mixed feelings when I see this news. This team does awesome work, though, and I'm glad that they seem to be highly valued.
I hope they will improve integration with AngularJS while not dropping support for Ember and other third party integrations.
I hope they will improve integration with AngularJS while not dropping support for Ember and other third party integrations.
We will absolutely not be dropping support for any platforms. We'll support what our customers want to use, whether that's Ember, or iOS, or React.
...until Google decides to pull the plug on Firebase in 6 months to 2 years.
Isn't it more likely their realtime functionality will be integrated or merged with whatever WebSocket initiatives Google has running?
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.
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.
My comment was only referring to Firebase as a standalone product/service.
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.
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.
"Firebase is here to stay, and it’s only going to get better at Google"
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'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?
Let's be honest — "Firebase is here to stay" is true right until the moment Google decides it isn't. It is no longer your decision to make (in a way, it never was, if you took external funding).
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.
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.
Congrats! I remember the debut of firebase at a hackathon back when I could barely code. Since then firebase has become my goto backend for new projects.
Firebase is awesome, keep up the great work!
Firebase is awesome, keep up the great work!
That first AngelHack? We remember it too. It was a ton of fun!
I remember when firebase was first announced It has always been my goto backend for my quick prototypes. And now using it for our product.
Thanks for a great product. I hope that Google can just leave the product team intact so they can continue to deliver.
Congratulations! Seriously guys! I'm incredibly excited to see this technology become more accessible / used deeper within Google's Cloud stack. I've also loved using this product as of late. Keep up the good work and enjoy this celebration!
Congratulations, guys! Are you going to change offices, or will you still be above me?
How will Firebase grow in relation to Google Cloud Messaging (GCM)? Do you think we could see GCM being replaced with Firebase?
If anyone is curious, my old analysis ( http://www.gwern.net/Google%20shutdowns ) gives an estimate of 70% for Firebase surviving another 5 years:
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)
[1] 0.693911886Interesting analysis, but I suspect you're missing something critical - whether or not Google use the product internally. If other Google services start to adopt Firebase (or they're already using it) then surely the probability of it being killed off is greatly reduced. The analysis you've done works for standalone products, but I think it'll fall down for services.
This may not be any indication. A Firebase competitor named GoInstant was bought by Salesforce, used to build a few things internally at that company, and very recently shut down and the team integrated into the parent company. Any outsiders that built anything with GoInstant were basically out of luck. I have no idea how many users they had, and Firebase has greater visible traction, so that may factor in as well.
Thanks for posting this.
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 ;-)
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 ;-)
Not sure about 70% to another 5 yrs, you gave Google+ (personal) an 85%, I believe it to be much lower.
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).
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).
wow! lots of decimal points! must be legit.
Please note that I rounded it in my comment, of course I don't think the stuff after the decimal point matters... (The source code is there so in the future I remember how exactly I got 70%, and in the unlikely event anyone is that interested in the details.)
As a heavy Angular user, I wonder how much of a role the Angular team played in driving this acquisition.
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.
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.
I just had a flashback from one of Misko's early talks about Angular's original vision as a full set of tools that included a managed database and security rules.
Here's his blog post about the topic:
http://misko.hevery.com/2009/10/04/sweet-spot-for-angular/
Some quotes:
"<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."
Here's his blog post about the topic:
http://misko.hevery.com/2009/10/04/sweet-spot-for-angular/
Some quotes:
"<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."
we make use of and love the angular/firebase/angularfire combo. for all it's faults and the complaints about how the web was not designed to be an app platform, it's what we have right now and these technologies (among others) really bridge the gap between 'app' and 'web'.
i really hope firebase doesn't get broken up or otherwise disappear into the goog.
and congrats btw!
i really hope firebase doesn't get broken up or otherwise disappear into the goog.
and congrats btw!
I got into Firebase because of Angular, and I am so far really happy with AngularFire. I am looking forward to even better symbiosis between the two! Especially considering all the serious vulnerabilities disclosed recently, I think a lot of people appreciate having a managed platform like Firebase to take care of the back end. AngularFire has the potential to become a significant standard if it continues on course.
Hey, class participant here. Your angular course was where I first really saw firebase in action, and speculatively angular probably has something to do with the acquisition.
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.
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.
> As a heavy Angular user, I wonder how much of a role the Angular team played in driving this acquisition.
Probably none. Angular is part of Ads, they're not in the Cloud group.
Probably none. Angular is part of Ads, they're not in the Cloud group.
It's true that they're in separate orgs inside the company, but Google is a pretty open place and it's extremely common for different orgs to work together. So I'm not sure that this observation really answers anything.
Darn, I was just planning to integrate Firebase on a project today. Now I'm very hesitant to do so (if Google doesn't entirely pull the plug at some point, I expect them to package it in with Google App Engine—which I have zero interest in using).
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?
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?
All of Google's cloud offerings are available independently.
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.
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.
Some good Firebase alternatives:
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
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
Most of the Freemium options seem to be targeted at either (a) mobile apps or (b) enterprises (their homepages clearly target executives/managers, not developers). They seem to want to own your whole stack. We have an existing app, with just a small bit that needs to be realtime. Firebase is the perfect solution, so it's really a shame that their future isn't bright.
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.
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.
(Disclaimer: I work for Fanout)
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.
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.
https://www.loggur.com is like Firebase on steroids, though only launched a few weeks ago. There is a lot to come: first thing being proper documentation for the REST API behind Loggur (should developers prefer to talk directly to it), and then hopefully huge strides in usability. But we need tons of feedback for the latter!
Parse actually seems pretty developer-focused. So does Syncano, except their free tier is limited. I believe they're changing that, though. Pubnub, Kinvey, etc. all seem to target more enterprise clients.
Also:
http://www.syncano.com (freemium)
http://www.pubnub.com (freemium)
http://www.socket.io (open source)
http://www.syncano.com (freemium)
http://www.pubnub.com (freemium)
http://www.socket.io (open source)
Apache Usergrid (open source): http://usergrid.incubator.apache.org/
Usergrid enterprise-grade hosting and support provided by Apigee (as API BaaS): https://developers.apigee.com/get-started
Usergrid enterprise-grade hosting and support provided by Apigee (as API BaaS): https://developers.apigee.com/get-started
I came across backand - http://www.backand.com/ - they might be a good alternative
https://www.loggur.com is like Firebase on steroids, though only launched a few weeks ago. There is a lot to come: first thing being proper documentation for the REST API behind Loggur (should developers prefer to talk directly to it), and then hopefully huge strides in usability. But we need tons of feedback for the latter!
You might want to check out Syncano for real-time apps/data storage. If you're looking just to do just push notifications, check out PubNub. I believe both are independently owned. And yeah, bummer about the whole Google thing.
hood.ie or pouchdb might be what your helpful
If you're concerned about the future of Firebase and you're the roll your own type, I wrote an article on how to build your own Firebase - it was extremely popular earlier in the year.
http://procbits.com/2014/01/06/poor-mans-firebase-leveldb-re...
http://procbits.com/2014/01/06/poor-mans-firebase-leveldb-re...
Open source it now ! Core client, server and protocol.
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!)
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!)
I'm looking forward to a sandstorm.io compatible version. I think this would be great for enterprise uses.
Funny enough SandStorm is built on Meteor :)
We love you Firebase! Your company and culture are an inspiration to all and your platform in particular is a role model to other cloud database companies. Best wishes from me personally and your many fans at Keen IO.
Has "acquired" become a dirty word lately? I read the announcements on both the Firebase and Google Cloud pages, and it wasn't even clear to me that Google had purchased the company (or a controlling interest, or whatever has happened). The message is simply that Firebase "joined the Google Cloud platform".
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?
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 have zero connection to the deal so this is entirely speculation, but in short, no, "acquired" has not become a dirty word. When a company is purchased - it's usually described as such. (In fact, I think for a public company, it's actually legally required that it be disclosed to shareholders in accurate terms, though the exact level of detail -- i.e. $$ -- is dependent on the "materiality" of the transaction.)
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.
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.
Well, you know ... Mr. Brin and Mr. Page recently succeeded in persuading me to activly support Google's business ... that's the style how some collegue told me about his new job :-). Yes, it's a bit tiring and part of the whole "we want to make the world a better place" marketing bullshit of the tech giants. At this scale, it's brutal business, nothing else. So, it would have been refreshing to read in the blog post: "We just took the heaps of money." Which is perfectly fine.
Congratulations guys! Wearing my #11 beta sweatshirt as I write this. :)
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 :)
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 :)
Congrats.
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.
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.
This is cool. If I recall correctly, one of the major issues with Firebase scaling was that they resolved consistency issues by running everything in a single datacenter. I wonder if something like Spanner could help them become a more distributed system.
having mixed feelings, on one hand I'm super happy that Firebase has grown to where it is now, the product has always been awesome and with Google I can only see it getting even better (Especially after seeing its Angular binding, and how Angular features Firebase as its default backend). On the other hand, I've loved how Firebase as a small team, always stays close with their users, listen to feedback from them and provide a lot of help and guidance. I often think of Firebase team members as friends and teachers. I don't know if they will be able to stay this way after joining such a big firm like Google :'(
We still love our amazing community and don't have any plans to change this. We'll work hard to stay accessible and active.
You may have no plans to change. But Google may have different plans down the road. Their track record speaks for itself.
Regardless congrats and best of luck!
Regardless congrats and best of luck!
Google's track record of interacting directly with developers is really good: public issue trackers, public mailing lists, monitored Stack Overflow tags... What track record are you speaking of? What could devrel be doing better?
Disclaimer: Engineer on Cloud SQL team
Disclaimer: Engineer on Cloud SQL team
Sorry I meant shuttering down various sites after buying them. Not talking about support.
Agreed -- I've always been very impressed by the Firebase team's responsiveness/helpfulness, especially on stackoverflow.
At the same time, I can't wait to see what the future of AngularFire holds!
At the same time, I can't wait to see what the future of AngularFire holds!
AWESOME!!! Congrats to the team, Firebase has been a pleasure to use from day one. The Angular fire integration has allowed me to prototype ideas in hours as opposed to days. THANK YOU, for creating such clear documentation, clear video presentations. The google acquisition makes it a easier to sell to some of the higher ups now, :P. YAY!
Congrats James - I've been watching your journey since Envolve. We were one of the first hundred users to join Firebase (ID:68) and I remember how easy it took to add real time notifications to one of my product (5 hrs I believe). Your team's success is well deserved.
Really hoping they bought it because it's something amazing that Amazon doesn't have, or they're planning on using it themselves and want more control over it.
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.
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.
Congratulations to James & the team. I remember when you were powering RickyMartin.com !
Yes, huge congrats guys! I don't know if I love the product or the team more. :)
Still not sure how I feel about tech giants acquiring startups like Parse and Firebase.
Is there some market explanation for why this tends to happen?
Is there some market explanation for why this tends to happen?
Google has only two billion-dollar businesses: Adwords and Adsense. They've been trying for the past 2-4 years to grow Apps/Docs/Drive platform into a third one, and have had reasonable success getting into some larger organizations like Motorola and some universities (Indiana U being one).
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.
Google's big recent push has been getting more companies onto their cloud infrastructure, which when you think about it, it's kind of nuts how they let Amazon eat their lunch in this area. It's GOOGLE: these guys invent filesystems (GFS/CFS), create their own Javascript compiler (V8), hell they've even created two programming languages (Dart, golang) and a database (spanner) -- how Amazon got ahead in cloud hosting really gives me pause.
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)
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.
Google's big recent push has been getting more companies onto their cloud infrastructure, which when you think about it, it's kind of nuts how they let Amazon eat their lunch in this area. It's GOOGLE: these guys invent filesystems (GFS/CFS), create their own Javascript compiler (V8), hell they've even created two programming languages (Dart, golang) and a database (spanner) -- how Amazon got ahead in cloud hosting really gives me pause.
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)
> how Amazon got ahead in cloud hosting really gives me pause.
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.
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.
I talked to some Amazon product managers, they said the narrative was closer to "we had to learn how to scale to meet the holiday shopping season" than "we had a bunch of extra capacity laying around". It's not a big leap of faith, look at how much business retail chains do over the holiday season, and imagine operating an e-commerce platform of Amazon's scale - you learn how to do elastic infrastructure pretty quickly, esp. with Bezos's legendary cheapness (doors for desks, etc.)
Off-topic, but door-desks aren't really cheap at all.
Great recount by an old time employee: http://glog.glennf.com/blog/2011/10/16/the_true_story_of_the...
Great recount by an old time employee: http://glog.glennf.com/blog/2011/10/16/the_true_story_of_the...
it's kind of nuts how they let Amazon eat their lunch in this area. It's GOOGLE: these guys invent filesystems (GFS/CFS), create their own Javascript compiler (V8), hell they've even created two programming languages (Dart, golang) and a database (spanner) -- how Amazon got ahead in cloud hosting really gives me pause.
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.
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.
Urs Holzle announced in January publically that Google's TI and Google Cloud will merge... thoughts?
>> Google has only two billion-dollar businesses: Adwords and Adsense.
Even a cursory reading of any of Google's earnings statements disproves your first sentence.
Even a cursory reading of any of Google's earnings statements disproves your first sentence.
"We generated 91% of Google revenues from our advertisers in 2013."
https://investor.google.com/pdf/20131231_google_10K.pdf
https://investor.google.com/pdf/20131231_google_10K.pdf
1. "revenues from our advertisers" is not just Adwords and Adsense - e.g. YouTube, AdMob, DCLK
2. The remaining 9% of ~60B is 5.4B
The market explanation is simple, if you can't beat em, join em. Firebase has a unique and well developed product, a growing following and good momentum. It makes sense for companies like Google to pull this talent into their portfolio.
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.
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.
Sometimes, talent acquisition. Sometimes, killing a competitor. Sometimes, getting technology to roll into their services.
They can use the platform internally and make money off of it, all while gaining access to a wealth of data about potential competitors and acquisition targets.
I'm building my product on top of Firebase using AngularFire and this news worries me so much. At first I thought it could be great but after reading all the comments here I'm not sure what to think anymore. The CEO is saying that they will continue developing the platform but apparently history shows that such promises are not always kept. Firebase is such an awesome product that it will be really terrible for Google to shut it down. I come from a Ruby On Rails and SQL background and as soon as I saw an app running with Angular and Firebase, I fell in love right away. I have already put too much time and effort into making my product with Angular and Firebase that it is too late to go back now, I will have to take the risk. Honestly if Google shuts it down, I'm sure they will release the source code at the very least. I think I'm going to be optimistic and hope that Google makes the right choice.
This is AMAZING :)
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
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
Congrats to the Firebase team. I remember stopping by your offices when there were just 4 people in a tiny office at 153 Townsend. All of the work you've done to help the community and build your product has been an inspiration. Wish you the best on the next leg of your journey.
First off congrats! I have been following Firebase for a long time and think it's a wonderful product. That being said, I really hope they stick to their word and use the resources at Google to expand Firebase keeping it open and not make it a walled garden.
I think it's a bit premature to be bought out at this time. You're still a young company, and had just started to get traction, and I doubt you are profitable yet. A couple more years of not being profitable and your plug is pulled. That's just how it is in the corporate world. You look at all those yahoo acquisitions and notice most of them aren't around anymore. They weren't profitable, and so they were shut down. Good for you, but you had capital to last a few more years, and you could afford to be a bit more aggressive, but that didn't happen.
BYOBaaS: Bring Your Own Backend as a Service. Open Source, bootstrapped funding model, easy to use, Offline First, private data by default, cute domain name: http://hood.ie — Very Fast [Web] App Development.
Previous HN discussions: https://news.ycombinator.com/item?id=7767765 / https://news.ycombinator.com/item?id=5514284
Disclosure: Hoodie core dev here.
Previous HN discussions: https://news.ycombinator.com/item?id=7767765 / https://news.ycombinator.com/item?id=5514284
Disclosure: Hoodie core dev here.
These guys have created an incredibly useful and unique platform. Congrats!
Call me old-fashioned but I shy away from unique platforms precisely because they are, well, unique, as you don't have a lot of vendor choice should you decide to migrate for whatever reason.
Theres definitely that fear of vendor lockin right now, because theres no standard yet. But on the other hand, the possibilities that firebase opens up are definitely worth that lockin for some users. There's going to be other alternatives sooner or later, now its just about determining how much you trust Google to keep firebase alive as is.
It'll be interesting to see what Google does with firebase. There are already alternatives out there - but question is - which of them will succeed next?
Let's hope google doesn't kill Firebase soon, would be a shame.
They will, eventually.
Don't argue with a timetraveller
The hell with startup, I want to know next Sat's Loto # from timetraveller. :-)
Everything dies eventually
I guess the mobile focused PaaS phase has fully cycled. Google has Firebase, Facebook has Parse and Amazon has Cognito. Still some room for independents now that they got bought up.
So, now all Firebase customers' data belongs* to Gogle?
*) Not in legal sense, obviously, but as a fact who handles storage and transmission of the data.
*) Not in legal sense, obviously, but as a fact who handles storage and transmission of the data.
I'm gonna miss the little bottles of hot sauce they gave out at hackathons. I put it on everything they fed us. <sigh>
I'm not too sure how I feel about start ups getting acquired by big corporate. Sure its a good way to acquire fresh ideas and talent, but it prevents new billion dollar companies from forming.
Wow, huge congrats to everyone at Firebase! You all seriously deserve it—amazing people, hard workers and great product.
Am I missing something about what Firebase is? Is it just a database system with a web API? I don't mean this disparagingly but don't most people just run their own database inside a VPS somewhere or a server and send data to/from that via their own interface? Am I missing something?
Firebase is geared towards building applications that need to update their data in realtime. When you change data in Firebase (either by adding data or modifying something that's already there), all connected clients are notified of the change, allowing you to update your UI to match the new data. While many people use it as a backend, it really shines when you take advantage of these notifications.
Ah OK. Thanks for the info. It saves you having to write a database system, the API and implement web sockets then. Thanks!
Count me in the "Thank God I'm not a Firebase customer" camp, because that was my reaction on reading this news. I think Google is still a net force for Good in the world, but the fact that the reaction here is so more-or-less uniform cannot possibly be healthy for the company.
Congrats - this is awesome, and a huge step for you all. Excited to hear what else is in store on the 4th.
Welcome to the chocolate factory. You're going to find this a very interesting experience.
I recently started using SignalR for some of my apps. What is the difference between SignalR and Firesharp? (both are realtime, only SignalR is more or less self hosted on first perspective)
I think SignalR is more analogous to socket.io in the Node ecosystem than it is to Firebase. But that's just me.
Firebase? Their customer database was stolen in September 2013 (I started receiving phishing emails), I reported it to them but never heard back.
After that I decided not to become a customer of theirs.
After that I decided not to become a customer of theirs.
Unfortunate, Google has a reputation for killing acquisitions. Let's hope the founders manage to escape and recreate their product after, like Dodgeball vs. Foursquare.
Huge congrats to you guys!
Still loving the name "Plankton".
Still loving the name "Plankton".
This is great. I hope you guys don't go away. I've been meaning to explore the google cloud a bit more anyway, though, I guess.
Is there a service that allows you to build on top of an Backend as a Service? So you could swap in and out Firebase, Parse, others?
Well now the stars are aligning. Google now has their way to begin the push on IoT with Nest, Glass and Phone data all linked contextually.
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.
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.
[deleted]
"Two big reasons."
Cash and equity. Corrected the next two paragraphs for you.
Cash and equity. Corrected the next two paragraphs for you.
Woot, congrats James and team. Google will make a good home :)
I love the product I hope google brings a lot to the table.
Congrats Firebase! Keep up the great work!
Any guess for how much they got acquired?
Congrats James and the Firebase team!
Congrats James & team!
Congratulations
HOW MUCH
Congratulations on not using the word "journey" once in your blog post or in this message.
Serious question: what's wrong with the word "journey"?
There is a tumblr called 'ourincrediblejourneyDOTtumblrDOTcom' which tells a long tale of users left in the cold.
Interesting: when I try to post that link as a URL the submission is '[dead]' on HackerNews. Why?
Interesting: when I try to post that link as a URL the submission is '[dead]' on HackerNews. Why?
Because it was funny the first few dozen times, but around the 500th occasion that someone stuck in his thumb and pulled out that particular plum, I had a fit of pique and wrote a line of code to kill it. What was I thinking? I'll drop everything and restore it.
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'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".)
dang, thanks for the explanation. I think you should keep the piqued code in so that we can go 'meta' and have 500 submissions about why an overused meme is dead. :-)
I probably should read the HN FAQ again - its been quite a long while.
I probably should read the HN FAQ again - its been quite a long while.
That's interesting - I've never come across it. Thanks for the explanation.
>Interesting: when I try to post that link as a URL the submission is '[dead]' on HackerNews. Why?
Because it's a site calling out the user-screwing acquisitions that Y-Combinator exists to make money from.
Because it's a site calling out the user-screwing acquisitions that Y-Combinator exists to make money from.
YC's focus is long term. Great products over long term require real compassion for your users. User-screwing acquisitions are usually acquihires and low return.
HN automatically blocks Tumblr
It's just cliche. There's nothing wrong with the word itself, and it's both descriptive and apt, but it's been driven into the ground by people using it in a glib fashion. See: synergy.
http://ourincrediblejourney.tumblr.com/
Basically, it's a cargo culted phrase in acquisition announcements.
Basically, it's a cargo culted phrase in acquisition announcements.
Please see: http://ourincrediblejourney.tumblr.com/
It's an overused buzzword that has no meaning anymore. Every company that gets acquired has an "amazing journey".
[deleted]
[deleted]
Putting in 100 hours a week for 3-10 years and getting a huge payoff at the end does sort of sound like an amazing journey though.
But it's also true. A startup is a journey!
It's a tired trope in acquisition announcements.
ourincrediblejourney dot tumblr dot com
[deleted]
Least constructive comment, yet most acclaimed.
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.