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
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.
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. :(
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.
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.
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.
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?