DAdavidjgraph·Nov 15, 2013
TL;DR good start, I just don't think it's enough in practice.
We thought about this too, it's a really, really commonly asked question when the company size involved > 10.
We think the process a user would go through after the service was no longer, as:
1) It needs to run in the immediate and medium-term future with minimal effort from the user. Open source isn't much use, you've an entire codebase/architecture to learn. "Open source" is a red herring, it just need to allow the user to user and edit it.
2) Without maintenance, the product will rot (new browsers, etc). You need an easy way to keep users running for 6-12 months, but assume they'll migrate to something else after a year.
3) The key problem is how to migrate users' data to a new system that they don't want to spend ages setting up.
The app is https://www.draw.io. We've two no
Read the rest
n-static parts, the save/load and the image export. (The data I'll come to later)
First thing we did is enable the gh-pages branch on the repository - http://jgraph.github.io/draw.io/war/. On modern browsers with FileAPI support, the load can be done locally, so that works. The only way to save locally without a server round-trip, that we found, was downloadify, which unfortunately is flash - https://github.com/raldenhoven/downloadify. We add a parameter to the URL to enable that - http://jgraph.github.io/draw.io/war/?flash=1 and you now have local save/load without the need for a back-end.
For the image export, we're thinking about possible solutions. My favourite is something like a Docker image that does the image/PDF export as a stand-alone server, but is lighter weight than a full VM. You could extend this concept to include all of the back-end processing your app does, and create the image automatically as part of the build process.
But also there's a print preview function. You can print that locally to PDF, etc.
For the data, we specifically selected bring your own storage for this reason. You can either persist locally, using localStorage, using Google Drive or Dropbox (https://db.draw.io). The reason for this decision was very much around this topic, users should own their own data and it shouldn't be tied to the lifespan of a service.
OK, maybe that isn't practical for some SaaS', but even if the data were in some DB, you could make life easier for users in the event of shut-down. You could have an AWS image built as part of the build process and anyone can run up. This replicates your DB environment (and if your DB is on AWS, frankly this should be part of the build process anyway). You give them the means to simply move the data over when required and now you have the static app part, the dynamic part and the storage.
The last part is the hardest, this is why BYOS is a _really_ user centric thing to do.
Two other important side-effects of doing this:
1) The github gh-pages gives us a second, independent serving of the app. There was a DNS problem with .io domains in the summer, some people couldn't resolve us. We could say go here in the meantime.
2) By creating something that doesn't need anything more than a static web server, you create an environment where the user's data doesn't have to leave their computer, which seems to be popular for some reason...
Oh, and we're not going anywhere, it just doesn't hurt to show users you think about this stuff.