Time to Say Farewell | Hacker News Reader

Time to Say Farewell

goinstant.com

52 pointsknes20 comments

For the Canadian startup scene, this is rather sad news.

GoInstant was started by Jevon MacDonald. Before starting the company, he ran a popular Canadian blog called Startup North.

The team, I believe, was still based in Halifax, Nova Scotia. I wonder if they'll relocate now?

One month should not be the industry standard for shutting down a service. It should be at least double that.

In August, no less - a month during which people frequently travel and use their vacation time.

I'd be pretty frustrated (to put it mildly) if I took my 2 weeks in August, and suddenly found out right before going that we'd have to migrate our entire backend to a different provider by the end of the month, leaving me with three options:

(1) Spend my vacation working

(2) Not go on vacation

(3) Postpone the migration until I get back, have it hanging over my head the whole time, and hope that I can scramble to get it all together before August 31

There's probably no one-size-fits-all "standard" for this. Did you use GoInstant? How did this shutdown impact your business?

I have never used their service, but reading this a few points come to mind. It seems like the fact that the service we be useable until August 31st will likely 'delay' the decision of most users to export their data until the last minute. If users export too soon, there is a risk they continue using the service and not export right away since the exported data will not reflect the latest usage. I would recommend having at least a few buffer days between the service being discontinued and data export.

That and the fact it is a short lead time if their clients are small shops. Most likely a lot of people are on vacation and will not be able to export their data by that time, or even realize or be aware that they need to export it.

This is why people who rely on BaaS/XaaS need to have some sort of contingency plan. There are too many paths a startup can take (death, acquisition/sunset, pivot, or rate increase) to not have some plan in place for when it happens.

Whether that's using cloud providers with open source code, holding proprietary code in escrow (think enterprise deals), or something else.

It doesn't take a whole lot of effort to plan for this ahead of time while benefiting from the XaaS.

I'm constantly amazed at how many people act like their core, mission-critical won't ever fail. It's like the concept of having a "Second Source" has somehow been forgotten.

I don't care how reliable and "guaranteed" something is - if everything collapses if we don't have it, we need backups. Even if everybody does everything right, there's always the "Hit by a Bus" style of risk. ( http://c2.com/cgi/wiki?HitByBus )

Maybe one should only use BaaS providers that promise/guarantee to release the source code as open source when they go out of business. What about Firebase? I hope they're better off.

(Super duper disclaimer, I'm with Fanout)

We are a realtime as a service company and our Pushpin code is all open source (https://fanout.io/open/) so that you have some peace of mind.

Sad to hear that. This was interesting work, as a non-google (albeit salesforce-hosted) alternative OT API.

Why do these interesting OT-powered projects never live long enough? Notable exception being Etherpad... /rant

Questions to GoInstant folks:

1. Quill is a good project. Will it live on? I remember noticing Quill when starting work on a very similar product (not yet released) with the same working name. ;)

2. What happens to the OT API? Will you open source it for the benefit of the public?

Shameless plug: The WebODF [1] Editor is a very powerful but rather underfunded project that aims to surpass Etherpad in terms of features, which is possible due to it's technical design. Funding would ensure that people would get something that could one day approach Google Docs' word processor, feature-wise. I've been working hard on it with three other developers for the past two years but money is always required. :(

[1] http://webodf.org/

I've also been following Quill development and it looks very promising.

It's worth noting that the same GoInstant developers have been working on a project called Tandem, which is an OT server implementation that uses the same underlying delta format as Quill: https://github.com/tandem/tandem

I hope that they will continue to work on it as an open source project now that GoInstant is going away.

Tandem looks interesting.

However a cursory look at the source reveals that it actually uses the diff-match-patch technique and not OT, which is fine for plaintext, but ultimately a bad choice for Quill...

To be fair, I have not investigated the implementation more.

Tandem does implement OT and can handle rich text. The dependency on diff-match-patch is just for their diff function, not their sync system. We actually recently switched to jsdiff as well.

Quill maintainer here. Yes Quill will live on. It was originally open sourced at Salesforce while I was on the GoInstant team but is not dependent on either for continued existence.

What's the postmortem? Looks like a useful service.

Don't know but according to Wikipedia they bought it in 2012 for $70 million. http://en.wikipedia.org/wiki/Salesforce.com

This is rather alarming since they also recently shut the doors on do.com that was also an acquisition: Manymoon (February 2011) – now known as Do.com[6] "bought the company for $25 million to $35 million" - http://techcrunch.com/2013/10/27/salesforce-coms-odd-decisio...

That's $105 million down the drain between those two. Not to mention whatever they invested in the couple years they owned them. Ouch.

Moral: Roll your own backend. I do like FireBase but hesitant to use them for this same reason.

Wasn't GoInstant acquired by Salesforce?

Yes. Second sentence in the OP: "Being a part of salesforce.com [...]"

Reply on news.ycombinator.com