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.
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.
Thank you for your awesome feedback. I believe that this could be done fairly easy with UserApp. We've built the system using well-known technology and standards and haven't bought any third-party software that has been integrated into our code.
The clause is not clear about everything. The code would of course be released in the same state as when we are developing in it. If of any reason we would have to close down, why would we want to make it hard for our customers? In that case we would probably give it out as an AWS instance together with instructions and documentation.
And you are right about the open-source license - we definitely need to clarify that. It will probably be under MIT.
>What happens in an acquisition where the parent company is interested in some parts of the technology you built?
One solution would be to not sell the company for the technology only. And the clause mentioned in the blog post is only valid if there is no intent of further operation. An acquisition would be considered as intent.
The purpose is to make our customers that depend on us to feel comfortable knowing that the service would still be available for them in another form whatever happens to UserApp.
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.
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.
Of course it wouldn't be totally friction-less. But as we see it it would be very easy in contrast of writing the user management all by your own. And regarding updates etc. - that is something they would have had to to with their own systems as well (considered they had written their own user management).
As I mentioned in a couple of other replies, IF this were to happen we would of course make it very easy for our customers to continue on by giving them instructions, documentation and nicely packaged as an AWS instance (or other formats).
This might not suit all SaaS's and would mostly be useful for SaaS that are developer focused (as we are).
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:
Releasing source code to paying customer is not "open source", it's just a clause in a contract. Microsoft allow some larger companies can get their hands on the Windows source code. Is Windows "open source"? I wish people would stop throwing around "open source" as a buzzword. IT'S NOT FUCKING OPEN SOURCE.
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.
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.
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.
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.
Or, the startup could save that insurance fee up each month, when the standard funds are gone, they declare EOL and burn through the savings doing maintenance while users migrate (of course, they'd burn through the extra, so the third-party does work better there).
The problem with a third-party is the complexity of handing over a full system and the fact the majority of startups fail early, i.e. the insurance fee would be much higher earlier in the life of the startup.
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 ;)
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 ;)
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.
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).
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?
"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.
[+] [-] clarkevans|12 years ago|reply
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|12 years ago|reply
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|12 years ago|reply
Thank you for your awesome feedback. I believe that this could be done fairly easy with UserApp. We've built the system using well-known technology and standards and haven't bought any third-party software that has been integrated into our code.
The clause is not clear about everything. The code would of course be released in the same state as when we are developing in it. If of any reason we would have to close down, why would we want to make it hard for our customers? In that case we would probably give it out as an AWS instance together with instructions and documentation.
And you are right about the open-source license - we definitely need to clarify that. It will probably be under MIT.
[+] [-] timothy89|12 years ago|reply
One solution would be to not sell the company for the technology only. And the clause mentioned in the blog post is only valid if there is no intent of further operation. An acquisition would be considered as intent.
The purpose is to make our customers that depend on us to feel comfortable knowing that the service would still be available for them in another form whatever happens to UserApp.
[+] [-] seivan|12 years ago|reply
[+] [-] davidjgraph|12 years ago|reply
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.
[+] [-] erikpukinskis|12 years ago|reply
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.
[+] [-] timothy89|12 years ago|reply
Of course it wouldn't be totally friction-less. But as we see it it would be very easy in contrast of writing the user management all by your own. And regarding updates etc. - that is something they would have had to to with their own systems as well (considered they had written their own user management).
As I mentioned in a couple of other replies, IF this were to happen we would of course make it very easy for our customers to continue on by giving them instructions, documentation and nicely packaged as an AWS instance (or other formats).
This might not suit all SaaS's and would mostly be useful for SaaS that are developer focused (as we are).
However, appreceate your feedback :)
[+] [-] skue|12 years ago|reply
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.
[+] [-] timothy89|12 years ago|reply
[+] [-] jsoo4|12 years ago|reply
[+] [-] klapinat0r|12 years ago|reply
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...
[+] [-] timothy89|12 years ago|reply
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|12 years ago|reply
[+] [-] skue|12 years ago|reply
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.
[+] [-] davidjgraph|12 years ago|reply
The problem with a third-party is the complexity of handing over a full system and the fact the majority of startups fail early, i.e. the insurance fee would be much higher earlier in the life of the startup.
[+] [-] brianmcdonough|12 years ago|reply
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|12 years ago|reply
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|12 years ago|reply
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|12 years ago|reply
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|12 years ago|reply
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|12 years ago|reply
Anyway, thanks for your feedback :)
[+] [-] mxuribe|12 years ago|reply
[+] [-] timothy89|12 years ago|reply
Appreciate your kind comments :)
http://images.wikia.com/horadeaventura/es/images/3/30/919px-...
[+] [-] adrianscott|12 years ago|reply
[+] [-] timothy89|12 years ago|reply
"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|12 years ago|reply
[+] [-] timothy89|12 years ago|reply
[+] [-] namenotrequired|12 years ago|reply
[+] [-] jsoo4|12 years ago|reply
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.