Hacker News Reader

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!"

Good point. As a startup owner myself, I somehow feel more comfortable depending on startups than on BigCo's (hence the rant), but maybe you're right that that's more emotional than rational.

Solution: "They're a stable, growing business that is profitable and intends to be in business for themselves for a long time! Not as risky!"

Not under the control of the customer, obviously.

Being acquired by Google almost solves the dilemma in that statistically you can be nearly certain that whatever product or service a newly acquired company provides will be a dead project within 2 years.

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.

The solution I've come up with is a pledge to release the source code if the product dies.[1] We've done this at Floobits, and it makes our users' lives less stressful.[2]

1. http://geoff.greer.fm/2012/09/19/a-responsible-product-sunse...

2. https://floobits.com/pledge

What good is a pledge? Once the product dies, there's presumably little incentive to abide by it.

Little incentive? Even assuming sociopathic tendencies, it doesn't make sense to renege on the pledge and be branded a money-grubbing liar. The internet has a long memory, and people would not trust you in the future.

> Even assuming sociopathic tendencies, it doesn't make sense to renege on the pledge and be branded a money-grubbing liar.

But that's just the same incentive for a company to continue providing the same level of service after being acquired.

How about the pain-in-the-butt that is organizing, packaging, and releasing an organic network & development environment when you have other bigger things on your plate? I'm sure there are a few companies here and there with everything already nicely packaged. Yet, most places I've worked, it would be a herculean effort to pull the tangled jungle that is the internal network & development environment into one halfway-functional package.

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.

Who said anything about organizing or packaging? Just put the code up on Github with a reasonable license and walk away. Running and maintaining is of course still a problem, but you can hardly expect a company that is out of business to do that.

"Just put the code up" isn't always that easy.

You may have the code, but there might still be a huge pile of problems. Such as:

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?

I completely agree that open sourcing the project does not guarantee that the project will continue to function. I also think that after a company goes out of business they have no responsibility to keep their project functioning. Once they open source it, anyone is free to put in the work to keep it going and I can't think of a better guarantee a company could reasonably give.

Not to be a dick, but

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

I have worked at startups that people could believe would fail. We used source code escrow services that release the code to customers if we went out of business. Any of them would have been free to open-source.

Up-voted and seconding. I have worked at startups that have done the same thing. I think this is not an uncommon practice.

Any recommendations as to reputable code escrow services? I'd imagine there are some misbehaving players out there.

Never heard of a bad actor. I think you just choose a law firm, insurance company, big 4 accounting firm. That sort of company.

They just need to safeguard the code drops and execute the transfer at the proper time. Like reading a will.

In general it could be taken as a legally binding statement so if they are bought out and shut down there would be an avenue to pursue with the new owners.

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.

Yes, the legal route sounds at least plausible. I don't know if there's any precedent or how reliable such a contract could be made.

It's not plausible because insolvent / bankrupt companies have the option to walk away from onerous contracts if it is in the interests of the debtors not to honour them. In this case, the idea of open sourcing the software UPON bankrupcy could destroy any remaining value left in the business (value of IP) which would otherwise be realisable to distribute to debtors.

Why not just open source it from the beginning? :)

https://github.com/inboxapp/inbox/blob/master/LICENSE

I know some folks at Basho where they do just that with Riak, a high-availability distributed database. It's not an unworkable strategy, and clients know the product's not going to vanish out from under them.

https://github.com/basho

Nice to see someone else viewing pledges as a potential solution.

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 prefer something enforceable in court.

Putting the source in escrow is a much better -- and more enforceable -- option than a mere pledge. This places the ability to release into the hands of a third party who is obligated to do so in the event that the conditions are met.

https://sandstorm.io/

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.

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.

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

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.

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.

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.

HTML5 - http://pouchdb.com iOS, Android, .NET, Java - http://developer.couchbase.com/mobile Hosted - http://www.iriscouch.com and http://cloudant.com Original - http://couchdb.apache.org

All of these are 100% open source and interoperable.

This is exactly why I went for couchbase and decided to avoid firebase.

Assuming you use PouchDB, how do you avoid syncing the entire database with all users?

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.

Couchbase Sync Gateway's channels are just slices through the data. The mechanism is internal to the Sync Gateway (you write a JS function that says who can see which channels and which channels a doc belongs to.) Replicating clients don't Need to know about this filtering, so channels work great with all flavors of Couch.

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

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.

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.

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.

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?

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

> 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

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 not trying to say your opinion is incorrect. Judging by your response, you took my comment a little too harshly.

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.

I didn't take it personally at all and if you have the time and inclination I'd love to hear more about your experiences. Please feel free to email me. smith at anvil dot io.

I'm an engineer on Cloud SQL. Support is much, much different from the wider Google reputation in Cloud[1]. We have a long leash to talk directly to people, and we do: Cloud SQL team, at least, monitors the google-cloud-sql tag on Stack Overflow and replies with help when possible. If you pay, you get telephone access to support reps who have a bunch of experience, and when they can't get something done themselves (rare), they can and do file bug tickets with the engineering team directly to get issues resolved.

We are developers and you are developers, and we're all trying to work towards making cool things :) I don't see that changing any time soon, everyone from in Cloud from Urs down gets it. We have to earn your trust, and we do that be providing the best product we can, interacting in communities directly, providing great support, and not creating vendor lock-in. I wouldn't work on this team if we didn't do those things, because I believe in them as being necessary parts much as you do.

[1] I can't speak to the rest of the company because I don't have experience with it, but I had very good support experience with Play too, so it's my hope that support in general at Google has turned a significant corner in recent years.

We have to earn your trust

Who's "we"? You, an honest guy, I'm willing to trust. But not Larry nor whoever the next CEO will be.

Where the buck drops is where mine won't cuz the other guy is your boss.

Isn't the same true of firebase as a company as well? Even pre-acquisition, all you need is for them to bring in an outside CEO who wants to monetize their userbase to screw things up.

That's pretty much true of any online service as opposed to software you control.

I appreciate the hardwork you guys are putting in. But what you are saying is tangential to what parent wants. parent wants a committed vision/plan from google towards customer support. Allowing developers to talk to customers is all cool but what's required is commitment from google as a company to invest in customer support resources.

So, when my Google Apps is down, I don't want to geek out and talk to an engineer on the various technical issues. I want it back, up and running asap.

Google Apps !== Google Cloud.

Speaking as a former Google Cloud customer (App Engine), while I had my gripes, the one you cite wasn't one of them. They already provide what you're looking for in my experience.

> Google is known to not give a damn about paying customers (ref: all the Google Apps customers who lose their email (for whatever reason) and get redirected to a FAQ page with answers to unrelated questions).

Just in case any Googlers are reading: you have a contact form for adsense questions that rejects my email address because my real name has "Cocks" as a part of it.

Is it this[1] form? If so, I'll find the owner and file a bug.

[1]: https://support.google.com/adsense/contact/contactsales?hl=e...

Just imagine what businesses based in Scunthorpe have to go through ;-)

It's okay, there's nothing important based in Scunthorpe anyway.

We've had a lot of vendors, like Firebase, approach us at Poll Everywhere over the years. Despite how awesome they are as people, a company, and the huge problems they solve, I've always avoided it getting in bed with any vendor for something that I think is fundamental to a realtime web application. As a result, we developed our own realtime web framework at http://firehose.io, open sourced it under the MIT license, and made ourselves immune to these circumstances.

>That's a pretty big risk to take as a startup that fully depends on Firebase for their data storage.

Fully depending on any third party for any important part of your business is a risky strategy. If you're contracting out something as core as data storage, you'd better have a good plan B regardless of the provider's economic situation.

Google is also known to Be Evil: I'm not sure I dare waiting until the terms change such that my user's data is subject to googlebot scanning.

I don't believe that claim, especially nowadays.

That's an excellent observation. I often feel that in the rush to acquisition the future of the product line can get lost. For example, one of the previous non-profits I worked with used myfamily.com for communications. Myfamily.com was bought out by Ancestry.com not too long ago, and progress on the MyFamily site - a completely separate but corollary product line - stagnated until they simply ended the product's run with just a few week's warning. After a while, when the acquired company's goals no longer apply for the new parent - or when they simply become too much of a hassle - they are simply left to twist in the wind.

Just an fyi in case you weren't trying to snipe on purpose, but there haven't been any data loss "issues" (e.g. stupid decisions by Google) with Apps for several years now.

That said, if I were using Firebase I'd be concerned, too. Google is well known as a place startups go to die, or morph into something The Borg wants rather than something aligned with the startup's original vision and the expectations of their paying customers.

Good luck and godspeed!

> That's a pretty big risk to take as a startup that fully depends on Firebase for their data storage.

Er, versus fully depending on a startup that could run out of money or be acquired at any time?

Would you purchase a company which was dependent on this Google service? Hmm, well Google might.