And then rewrite your entire app against a new API. No thanks.

I wish this was true. I am locked-in with Firebase and would love to self-host now that I have resources. Sadly I will have to rewrite the API. It's not that Firebase is not great, I just want to take control back.

To be fair, I think Horizon is one of the more promising Firebase alternatives. However, it has completely different semantics, and is quite immature at this point (look at the limitations: http://horizon.io/docs/limitations/). But if Firebase remains proprietary and Horizon continues to improve I could certainly imagine that rewriting my app will eventually start to look attractive.

I know everybody would love to see this, but for me it's a bit much to ask from Google to open-source Firebase since they invested quite a lot of time and money into it to get to the current version. Apart from that, I can definetly recommend http://deepstream.io as a Firebase alternive, although it currently lacks an Android/iOS client (Java client is in the works).

I doubt Google will open source Firebase since the latest version is tied deeper into other Google Cloud stacks. I evaluated Firebase as a backend for an iOS/Android app but has to drop them due to the app needs China market. Firebase Android SDK has dependency on Google Play Store services, and majority of Android phones in China do not have Google Play services installed. There are even report that some sites under Firebase Hosting (basic static site hosting) can not be accessed in China.

If you highly value the hosted PaaS aspects of Firebase then it's good to look at (they are one of the best in that space). If you're looking for an open-source alternative that can be hosted in your private or public cloud, check out Couchbase Mobile (full disclosure, I'm an architect at Couchbase). We're open-source under Apache 2 and have all the database and sync functionality of Firebase. Many of our customers/users evaluate us against Firebase, it really depends on where you place the most value: PaaS, controlling your own data, open-source, etc. http://developer.couchbase.com/mobile

Yeah, I agree that open sourcing Firebase is too much to ask. But there's other things they could be doing: a) document the wire protocol and license the clients for free use with any server, b) make the API definitions public domain and provide a compatibility test suite for alternative implementations, c) lead a standardization effort on real-time JSON databases, etc...

True, maybe https://github.com/firebase could help with some reverse engineering. However, I discovered the Firebase document and the deepstream.io record structure to be fairly similar, so with the help of https://github.com/firebase/firebase-queue the migration from Firebase to deepstream.io + RethinkDB might be possible. As a more general note, I would expect some of the stuff you mentioned to happen in the upcoming months/years, since Firebase is right now set to become the universal plattform for app devs (analytics, dynamic links etc.) rather than a standalone database offering.

Sure! We should be tankfull they throw us a bone here and there(i.e. a whitepaper)...until then let's invest more in their cloud services so they can show us how small we are without them. I remember people asking why they don't open source datastore and appengine. Their response was that we are too dumb to manage it so it won't help us anyway.

If you ate not willing/able to pay for managed cloud services like Firebase, there are some really cool self-hosted alternatives out there (like deepstream.io and horizon.io). Open-sourcing software should always be a can, not a must. We could as well expect Amazon to open source DynamoDB, which is proprietary as well and still has quite a lot of users.

Given that this blog post is about having portable workloads and Firebase is specifically not portable, isn't it obvious that talking about Firebase would be "off message"?

Actually, the article specifically talked about some non-portable services and explained why this wasn't a big deal, so to me leaving out Firebase implies that 1) it is a big deal and 2) they're not interested in making Firebase apps portable. My conclusion is that they're only opening up the services where they're not in the lead and getting people locked into the ones that are. Which is fine and a great business strategy but rather detracts from the "we're all about openness and choice" image they're trying to project.

I personally perceive Google as ahead in the container space and quickly the machine learning space.

I don't see how one product being closed has any impact on the openness or portability of the products mentioned in this article. It seems unreasonable, to me, to criticize them for omitting an exhaustive list of closed products in a blog post about portable platforms.

There are few things in life that would excite me more than Firebase going open source. Sad, I know. :/

Cloud PubSub is also missing, which I've always heard is one of the better parts of Google's cloud offerings.