How to guarantee continued operation for an SaaS startup

This is an interesting idea (I applaud the effort) -- the devil is in the details.

For starters, if your shop closes their door... you are likely doing it because you ran out of money/time. Why would you go through the effort to package your work as open source code and help users figure it out?

Second, you can't just say "open source". You should specify a license, or at the very least say: "under a license approved by the Open Source Initiative".

Third, what exactly is open sourced? Are their proprietary services you use, did you license these for your users?

I suppose, if you want to make this promise, you could publish your entire stack on GitHub and put it under a license that its time-boxed: "If for any reason XXX stops operation, this source is released under the MIT; tell then, you may copy it only for archival purposes". But, in this case, what constitutes as "stopping operations"? What happens in an acquisition where the parent company is interested in some parts of the technology you built?

UPDATE: Edited to directly respond to _their_ effort to make this Guarantee to their users.

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

You should also look into software escrow. Large corporations often require this of smaller vendors delivering enterprise solutions (SaaS or otherwise).

Your agreement is great in spirit, but I believe the moment your company ceases to exist your customers will lose legal recourse over your commitments. IANAL, but I would assume that includes this open source guarantee. That's why there are a number of third party companies who provide escrow services. Iron Mountain is an example:

http://www.ironmountain.com/Services/Technology-Escrow-Servi...

Edit: Fixed formatting, wording.

I do very much appreciate the intention, but I feel like this should be mentioned:

While it may be realistic for UserApp, it doesn't take much to make it difficult, complex or even impossible. There have been similar discussions on HN at least a couple of times. The first that comes to mind is the release of the DOOM3 engine source code by id Tech / Carmack[1]

On a personal level I can see the excuse of saying "screw license, we'll just email the source to our customers and what they choose to do is up to them", but there may be unlicened changes in dependencies.

While some ideas fail, some of those are carried on to new ideas, and you may have written code as part of the failed startup, which would be a significant IP to you, and might be an integrated part of your next idea's success.

Yes, the latter comment is not very "open source" minded, but given how many projects start out as proprietary (or at least partially), it is a scenario one should keep in mind.

So overall, the intention is good, and can work for some projects, but you never know what the future brings (which, ironically, is why you draft pledges like this.

Thanks for your willingness to take responsibility and I hope you'll go the distance.

[1] https://twitter.com/ID_AA_Carmack/statuses/13661445988720230...

This makes me think if there might be demand for a consultancy-like startup, which has the business idea of taking over a SaaS service if the company is discontinued, and running it for x number of months/years. The business model would presumably be charging the SaaS company an insurance-like fee, and the value proposition would be that they can advertise their SaaS as a "safe" service.

Did a user ask for your policy in this area?

It's true, a lot of startups go out of business and it's a good, honorable intent you have.

But sometimes sales is the correct solution, especially when there is time and effort involved in offering a remedy to a problem that does not currently exist. My answer would be to focus on the positive as opposed to negative outcome, i.e., UserApp is the best solution to x problem on the market.

But if this is a recurring question in the sales/customer feedback loop, then going beyond a sales solution may be a good idea, but you may benefit from going even further than the proposal in your post and offering open source now (noncommercial). 99% of your customers will not know about the open source version esp. if you don't sell it. Create noise around positive outcomes as opposed to negative ones by offering a solution that quickly resolves any hesitation on the part of your customers.

For example, one of the few things I know about UserApp is that it may go out of business.

While I think the idea in general is very good, it does not guarantee "continued operation" at all.

Firstly, the user has to invest a massive effort to get the whole infrastructure running and host the service themselves. This is a major hurdle for a non-technical user, and even for a technical user it may actually be quicker to migrate to another SaaS than to set everything up...

Secondly, your license does not guarantee that the users will also be able to export and re-import their data. You should a) add that to your paragraph and b) have that code ready. A simple DB backup would contain the data of ALL users... and, in case you have to shut down, you may not find the time to write export/import functionality.

Anyway, good luck with your SaaS! Let's hope you won't need the clause ;)

This will make more sense if/when you have a customer-hosted solution. There's a lot more to packaging/integrating an application for a specific install than is usually included in the application source code, and people paying for SaaS solutions are usually doing so because they want to avoid all of that. At least if you have a packaged solution it shows that you've done some of that work in a reproducible fashion.

Plus, as a parting gift the code could be a bit of a booby trap, depending on how gnarly and idiomatic it is. Open-source applications can't get away with as many dirty hacks as closed-source ones. Not that I'm saying that your code is bad, but it represents an unknown for your customers!

I applaud you for doing this, and I think it's a fantastic idea. As mentioned by other commenters it's not quite as simple as releasing the source-code but it's better than nothing.

However, this isn't going to work for any SaaS that has any VC, as your code is part of your IP. Selling that is quite common practice when investments fail and investors want to recoup some of their losses.

While execution may be tough depending on various factors - type of business, the way the software is structured, etc...I have to say the intent and concept are very admirable!! Certainly, a very forward-facing and humanistic organization who thinks that way!

Have you considered A/B testing showing vs. hiding the warranty to measure any diff -- positive or negative -- in conversions to both click-throughs to the signup page, and also paying customers?

If your users can run your stack on their servers, why not offer self-hosted edition for a fee like Atlassian?

I hope you'll be sharing with us what the results were!

"the whole source code would be released as open-source to our paying customers."

The "as open-source" part there seems not entirely true. It's not truly "open" if only paying customers have a copy. Just "would be released..." would suffice, without the buzzword compliance thrown in.