

How to guarantee continued operation for an SaaS startup - ActionFigure
http://timothy.userapp.io/post/67053194467/how-to-guarantee-continued-operation-for-an-saas

======
clarkevans
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.

~~~
jdangu
Open source is not the best way to call this.

This is more of a simplified version of the software escrow agreement, where
you continuously push your code base to a trusted third-party in case your
company goes belly-up.

I had to deal with a software escrow in the past, and this is a smart
alternative to it - if the customer agrees. There is clearly less protection
though.

~~~
timothy89
Sounds very interesting :) Will investigate the alternative. Thanks for the
feedback!

------
davidjgraph
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](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/](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](https://github.com/raldenhoven/downloadify).
We add a parameter to the URL to enable that -
[http://jgraph.github.io/draw.io/war/?flash=1](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](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.

~~~
erikpukinskis
Every customer doesn't have to do the work to re-host the service, it only
takes one. Promising to share the source means you just need one enterprising
individual to do all the work you described. For them they get for free a
validated business idea, a set of highly interested potential customers, and
90% of the engineering work done.

Now you might say the business is the opposite of validated if it closes up
shop, but the opportunity is for someone to reopen it in a "lower energy
state". The original startup has a large staff and presumably some ambitious
growth plan. The new startup can have a smaller staff, more realistic
ambitions, and the benefit of hindsight.

------
skue
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...](http://www.ironmountain.com/Services/Technology-Escrow-
Services/Software-as-a-Service-Continuity-Services.aspx)

Edit: Fixed formatting, wording.

~~~
timothy89
Thanks, will look into that. You don't happen to know what it might cost?
Maybe I should apply for a free quote :)

~~~
skue
We did use software escrow at my last company (hospital customers). I believe
we just did source code hosting and it was roughly $1000 to set up and for the
first X customers, and additional customers were a smaller additional fee.
Given how aggressively SaaS services are priced these days, companies like
Iron Mountain may have special pricing for SaaS. Getting a quote is the best
way to go!

Also, if it's too expensive to do for everyone, you can of course offer it as
a premium feature or a differentiator for an enterprise pricing tier.

------
klapinat0r
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...](https://twitter.com/ID_AA_Carmack/statuses/136614459887202305)

~~~
timothy89
Thank you very much for you feedback.

As I see it; either we (the founders) could feel safe knowing that the source
belong to us whatever happens. Or our customers could feel safe knowing that
they can continue their operation without us. We've decided to go with the
latter.

I guess time will tell... :)

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

~~~
skue
Would the numbers ever make sense? If a company does fail it's either
technical failure or an unsustainable business model. I doubt a consultancy
would want to inherit the former, and if the business model fails then it's
hard to see how a third party could continue operations when it was only being
paid a fraction of prior revenue.

Plus, keep in mind that most startups fail - this isn't like fire insurance.
If anything, a consultancy like this might make it easier for founders to walk
away sooner and with less guilt knowing that someone else will bail out their
customers.

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

------
CookWithMe
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 ;)

~~~
timothy89
The problem we face is that it can be hard to migrate from our service once
integrated. If course this is something that we want to improve, for example
we've added the availability to export all your data. But then there's the
problem with a few similar competitors to change to.

But as I wrote in another reply we would of course make it as simple as
possible and probably provide the system as an AWS instance. But sure, it
won't not be totally friction-less.

I will try to improve the clause based on all the feedback I've got today.

Thank you! We will do everything in our power to not ever have to use the
clause ;)

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

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

~~~
timothy89
Our decisions (including this one) is based on what's best for our company and
customers, not any future VCs. And also, this clause is mainly an insurance
for our customers during our first "risky" years. Hence the expiration on the
clause (October 31, 2015).

Anyway, thanks for your feedback :)

~~~
dmoney
I applaud your intent. But to play devil's advocate, what's to stop an
acquiring company from shutting the service down the day after the expiration?

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

~~~
timothy89
The concept/clause is something that we will refine to make it as "perfect" as
possible.

Appreciate your kind comments :)

[http://images.wikia.com/horadeaventura/es/images/3/30/919px-...](http://images.wikia.com/horadeaventura/es/images/3/30/919px-
Happy-oh-stop-it-you-l.png)

------
adrianscott
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?

~~~
timothy89
I answered you comment on by blog :)

"At the moment I'm tracking clicks on the title "Open-source warranty". But I
will try to perform an A/B test later."

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

~~~
timothy89
This is something we will have in the future, a "on-premise/enterprise"
solution. Though it will cost a bit more than $9 a month :)

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

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

