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!"
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.
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.
All of these are 100% open source and interoperable.
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.
For my applications in healthcare I'm often forced to use in-house servers.
It is also available in Debian jessie.
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.
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?
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).
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 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.
1. http://geoff.greer.fm/2012/09/19/a-responsible-product-sunse...
But that's just the same incentive for a company to continue providing the same level of service after being acquired.
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.
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?
"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.
They just need to safeguard the code drops and execute the transfer at the proper time. Like reading a will.
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.
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.
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.
Not under the control of the customer, obviously.