| [Firebase founder] I no longer work at Firebase / Google, but two points: 1. There may be issues with the GCP integrations & UX/DX, but GCP integration is good for many customers and necessary for the future of the business. One of the common failure modes for the 2011-2014 crop of Backend-as-a-Service offerings was their inability to technically support large customers. The economics of developer tooling are a super-power-law. So, if you hope to pay your employees you'll need to grow with your biggest customers. Eventually, as they become TheNextBigThing, your biggest customers end up wanting the bells and whistles that only a Big Cloud Platform provide. This was a part of the reason we chose to join Google, and why the Firebase team really really really pushed hard to integrate with GCP at a project, billing, and product level (philosophy: Firebase exposed the product from the client, GCP from the server) despite all the organizational/political overhead. 2. I'm excited to see the current crop of app platforms emerge. It has been 10 years since we launched (https://news.ycombinator.com/item?id=3832877) and there are now some great innovations in the space. I like the way Supabase (https://supabase.com/) has exposed Postgres and InstantDB (https://www.instantdb.com) graphdb+realtime is really promising. |
If you have a successful popular product (firebase) and a not particularly successful or well loved product (GCP), does mixing A into B make sense?
It might make technical sense to have the robust engineering capabilities of B to support A.
…but if it’s driving customers away from A, because it’s starting to look like what they don’t like from B…
All I can say is that there seems to be a lot of pressure for GCP to succeed, and I’m pretty skeptical that the changes to firebase are being made for the sake of making that product better.
Betty had a bit of butter, but the butter was bitter, so she mixed the bitter butter with the better butter to make the bitter butter better but it made the better butter bitter…