I think most people here would tend to disagree for two reasons:
1) Firebase's feature set is vast, which ultimately means that you're going to pull in a much bigger SDK than what an "open source Firebase" can reasonably provide. Half or more of the SDK code you're pulling into your project will do nothing. It's better that competitors are like firebase in spirit but ship their own SDKs to optimize for their use cases.
2) Firebase is still owned by google, which automatically paints a target on its back. We don't know what the long term internal roadmap of Firebase is, regardless of what the GCP bosses might say or how much money it seems to make on paper. Google has sown itself quite willing to kill any project at any time without a lot of clear reasoning as to why, and no one wants to build against an SDK/standard that could vanish tomorrow.
That would be a "drop-in replacement", which is indeed a type of alternative. But to be an alternative, it's enough to just provide similar functionality.
1) Firebase's feature set is vast, which ultimately means that you're going to pull in a much bigger SDK than what an "open source Firebase" can reasonably provide. Half or more of the SDK code you're pulling into your project will do nothing. It's better that competitors are like firebase in spirit but ship their own SDKs to optimize for their use cases.
2) Firebase is still owned by google, which automatically paints a target on its back. We don't know what the long term internal roadmap of Firebase is, regardless of what the GCP bosses might say or how much money it seems to make on paper. Google has sown itself quite willing to kill any project at any time without a lot of clear reasoning as to why, and no one wants to build against an SDK/standard that could vanish tomorrow.