20 ms·

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

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.

Nevraeka 12y ago
+1 to open source the platform
- dude3 12y ago
  Node.js + Socket.io + Bootstrap + AngularJS + Angular Socket.io + 1000 lines of code
  - matthewmacleod 12y ago
    But that's a thousand lines of code I don't have to write. And integrations I don't have to do. And libraries for lots of platforms. I think you're undersstimating the added value – the point is that people don't have to bother setting up and maintaining all of those moving parts with a service like firebase. Case in point, I was building a small real-time web serice this weekend; it's exactly the sort of thing that Firebase would be great for. But given that I couldn't run it locally, and that there's no migration path if they were to acquired and shut down, I had to implement a half-assed solution on my own. If Firebase had been open-source, I'd almost certainly have ended up forking over cash for them to host it anyway.
    - dude3 12y ago
      The project in which I implemented this toolset is working great and it only took me one weekend to implement too. I am not saying Firebase is inferior at all. Just, for my situation, I am not sure why I need to pay for that functionality when I can literally set it up in one day vs reading the documentation on how to set it up on Firebase in the same time. I also control all outcomes and avoid ones like this where Google could potentially take over control of a large portion of your app. My server side code is about 100 lines. This controls a chat server, chat rooms, youtube video commands. And its currently working just fine with 4,000 visitors a day on a vps that cost $5 a month. Why not learn how to do it yourself? Especially if you already have vps. I am using varnish with multiple sites and it took a couple hours to set up. I am really confused on this.
      - jnbiche 12y ago
        I think you're vastly underestimating what Firebase offers, which you presumably didn't do in 100 lines of code: 1) Full user management services, including registration and password recovery 2) Extremely fine-tuned access control per resource 3) Complete, tested front-end libraries for AngularJS, Backbone, and other popular frontend libraries. 4) Much more reliability than socket.io in providing cross-platform, cross-mobile real-time messaging (believe me I've used and tested socket.io). socket.io may or may not work on a given platform, and it's no longer a very active project, either. 5) Full admin panel for database, including real-time data updates. Look, for a chat app, you're absolutely correct that Firebase may be overkill. But very few of us that rely on Firebase for applications are limiting ourselves to chat apps. That said, I'm not happy about this acquisition. And this is probably the last time I'll be burned like this by a PaaS company. I saved a lot of time by going with Firebase (much more than 100 lines of code) but I'm questioning whether it was worth it. PS: I didn't downvote, although I was tempted after reading your "Why not learn" remark. I think you're right in the end that open source is the best solution, but you're very wrong to assume that people are using Firebase because they can't quite figure out how to make a 100-line Node app.
        ulisesrmzroche 12y ago
  - christiansmith 12y ago
    Don't forget about persistence. Creating a horizontally scalable database isn't likely to be a trivial matter. Somehow I don't think Twitter Bootstrap is going to be much help there. Firebase has solved many harder problems than you and I are ever likely to have to deal with and they deserve full credit for that.
    - icedog 12y ago
      We don't know how "solved" these questions are because it's closed source.
  - dude3 12y ago
    + Redis
    - justsee 12y ago
      When building our realtime platform we quickly realised socket.io fell over spectacularly with serious traffic, and that all other hefty realtime services did not use it. There has been lots of movement with the bigger release but nothing that has interested us in going back to it.
      - ddorian43 12y ago
        so what did you use ?
        justsee 12y ago
        Well the memory leaks and approach to fallback connections led to it being more sensible to roll our own. We've only needed to handle concurrent connections in the 1-10k range though. There are really better c++ and erlang implementations we've investigated but won't pull those off the shelf till needed. Obviously there's loads of great realtime-as-a-service offerings like Firebase and Pusher that make sense for a lot of use cases, just not ours. We were always uncomfortable with relying on a third party for a core aspect of infrastructure, and this acquisition introduces uncertainty that we don't have to worry about.
        Xixi 12y ago
        I've not tried it yet, but Poxa [1] looks quite promising: it's an Elixir app that is supposedly compatible with Pusher libraries. [1] Poxa: https://github.com/edgurgel/poxa https://github.com/edgurgel/poxa
  - Nekorosu 12y ago
    Bootstrap and Angular? Why? I'm pretty sure the core idea of FireBase is being usable with any JavaScript client-side.
  - rakoo 12y ago
    I don't see MongoDB. Is that on purpose ?
- jemfinch 12y ago
  There's a small triangle for that right next to the GP's username. This comment adds nothing to this conversation.
sanderjd 12y ago
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.
- tburns 12y ago
  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).
- lookingsideways 12y ago
  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.
SiVal 12y ago
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.
jimbokun 12y ago
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.
- jchrisa 12y ago
  HTML5 - http://pouchdb.com http://pouchdb.com iOS, Android, .NET, Java - http://developer.couchbase.com/mobile http://developer.couchbase.com/mobile Hosted - http://www.iriscouch.com http://www.iriscouch.com and http://cloudant.com http://cloudant.com Original - http://couchdb.apache.org http://couchdb.apache.org All of these are 100% open source and interoperable.
  - marpalmin 12y ago
    This is exactly why I went for couchbase and decided to avoid firebase.
    - skrebbel 12y ago
      Assuming you use PouchDB, how do you avoid syncing the entire database with all users?
      - willholley 12y ago
        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.
        12y ago
kenjackson 12y ago
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).
- koolkao 12y ago
  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.
  - jkarneges 12y ago
    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.
jchonphoenix 12y ago
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.
- jeswin 12y ago
  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?
  - jchonphoenix 12y ago
    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).
- christiansmith 12y ago
  > 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 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.

Nevraeka 12y ago

+1 to open source the platform

dude3 12y ago
Node.js + Socket.io + Bootstrap + AngularJS + Angular Socket.io + 1000 lines of code
- matthewmacleod 12y ago
  But that's a thousand lines of code I don't have to write. And integrations I don't have to do. And libraries for lots of platforms. I think you're undersstimating the added value – the point is that people don't have to bother setting up and maintaining all of those moving parts with a service like firebase. Case in point, I was building a small real-time web serice this weekend; it's exactly the sort of thing that Firebase would be great for. But given that I couldn't run it locally, and that there's no migration path if they were to acquired and shut down, I had to implement a half-assed solution on my own. If Firebase had been open-source, I'd almost certainly have ended up forking over cash for them to host it anyway.
  - dude3 12y ago
    The project in which I implemented this toolset is working great and it only took me one weekend to implement too. I am not saying Firebase is inferior at all. Just, for my situation, I am not sure why I need to pay for that functionality when I can literally set it up in one day vs reading the documentation on how to set it up on Firebase in the same time. I also control all outcomes and avoid ones like this where Google could potentially take over control of a large portion of your app. My server side code is about 100 lines. This controls a chat server, chat rooms, youtube video commands. And its currently working just fine with 4,000 visitors a day on a vps that cost $5 a month. Why not learn how to do it yourself? Especially if you already have vps. I am using varnish with multiple sites and it took a couple hours to set up. I am really confused on this.
    - jnbiche 12y ago
      I think you're vastly underestimating what Firebase offers, which you presumably didn't do in 100 lines of code: 1) Full user management services, including registration and password recovery 2) Extremely fine-tuned access control per resource 3) Complete, tested front-end libraries for AngularJS, Backbone, and other popular frontend libraries. 4) Much more reliability than socket.io in providing cross-platform, cross-mobile real-time messaging (believe me I've used and tested socket.io). socket.io may or may not work on a given platform, and it's no longer a very active project, either. 5) Full admin panel for database, including real-time data updates. Look, for a chat app, you're absolutely correct that Firebase may be overkill. But very few of us that rely on Firebase for applications are limiting ourselves to chat apps. That said, I'm not happy about this acquisition. And this is probably the last time I'll be burned like this by a PaaS company. I saved a lot of time by going with Firebase (much more than 100 lines of code) but I'm questioning whether it was worth it. PS: I didn't downvote, although I was tempted after reading your "Why not learn" remark. I think you're right in the end that open source is the best solution, but you're very wrong to assume that people are using Firebase because they can't quite figure out how to make a 100-line Node app.
      - ulisesrmzroche 12y ago
- christiansmith 12y ago
  Don't forget about persistence. Creating a horizontally scalable database isn't likely to be a trivial matter. Somehow I don't think Twitter Bootstrap is going to be much help there. Firebase has solved many harder problems than you and I are ever likely to have to deal with and they deserve full credit for that.
  - icedog 12y ago
    We don't know how "solved" these questions are because it's closed source.
- dude3 12y ago
  + Redis
  - justsee 12y ago
    When building our realtime platform we quickly realised socket.io fell over spectacularly with serious traffic, and that all other hefty realtime services did not use it. There has been lots of movement with the bigger release but nothing that has interested us in going back to it.
    - ddorian43 12y ago
      so what did you use ?
      - justsee 12y ago
        Well the memory leaks and approach to fallback connections led to it being more sensible to roll our own. We've only needed to handle concurrent connections in the 1-10k range though. There are really better c++ and erlang implementations we've investigated but won't pull those off the shelf till needed. Obviously there's loads of great realtime-as-a-service offerings like Firebase and Pusher that make sense for a lot of use cases, just not ours. We were always uncomfortable with relying on a third party for a core aspect of infrastructure, and this acquisition introduces uncertainty that we don't have to worry about.
        Xixi 12y ago
        I've not tried it yet, but Poxa [1] looks quite promising: it's an Elixir app that is supposedly compatible with Pusher libraries. [1] Poxa: https://github.com/edgurgel/poxa https://github.com/edgurgel/poxa
- Nekorosu 12y ago
  Bootstrap and Angular? Why? I'm pretty sure the core idea of FireBase is being usable with any JavaScript client-side.
- rakoo 12y ago
  I don't see MongoDB. Is that on purpose ?
jemfinch 12y ago
There's a small triangle for that right next to the GP's username. This comment adds nothing to this conversation.

sanderjd 12y ago

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.

tburns 12y ago
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).
lookingsideways 12y ago
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.

SiVal 12y ago

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.

jimbokun 12y ago

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.

jchrisa 12y ago
HTML5 - http://pouchdb.com http://pouchdb.com iOS, Android, .NET, Java - http://developer.couchbase.com/mobile http://developer.couchbase.com/mobile Hosted - http://www.iriscouch.com http://www.iriscouch.com and http://cloudant.com http://cloudant.com Original - http://couchdb.apache.org http://couchdb.apache.org All of these are 100% open source and interoperable.
- marpalmin 12y ago
  This is exactly why I went for couchbase and decided to avoid firebase.
  - skrebbel 12y ago
    Assuming you use PouchDB, how do you avoid syncing the entire database with all users?
    - willholley 12y ago
      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.
      - 12y ago

kenjackson 12y ago

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).

koolkao 12y ago
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.
- jkarneges 12y ago
  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.

jchonphoenix 12y ago

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.

jeswin 12y ago
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?
- jchonphoenix 12y ago
  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).
christiansmith 12y ago
> 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 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.