[webmaven]

Release Orchard backend as open source? Note: Consider why fig took off and Orchard didn't...

No one wants to be stuck on a provider that might not succeed and have to migrate to a different one unless the new provider is drop-in compatible. It is nice that you are providing migration instructions and help, but the very idea of being at the mercy of an acquired platform's team is what stops me from trying such services in the first place (after being burned by ep.io, 30loops, etc.).

[bfirsh]

The nice thing about using Docker is that everything is drop-in compatible. You can push your images to a provider such as Tutum or Google Cloud and they'll be able to run. If you've written any software that used the Docker remote API on Orchard, you can just point that are your own Docker daemon and it'll keep on working.

[webmaven]

If that were really true, the migration instructions would be more along the lines of "change the endpoint URL to your new provider", or "push this one button and authenticate", instead of https://www.orchardup.com/docs/moving

That said, kudos to the Orchard team for making it as easy as they did, I'll just stress again that the fear that migrating would be even more involved was what stopped me from trying their service in the first place.

There are several ways of addressing that fear:

1. Be so big that you know the service is unlikely to be shut down or acquired (that just leaves the usual lock-in concerns over future price hikes and the like, which isn't going to happen until the market stops growing).

2. Ensure that a fluid marketplace of drop-in replacement competitors exists (an Open Source release of the backend helps with this)

3. Document how easy it is to switch away from the get go, not just when you're shutting down: see https://web.archive.org/web/20140209113413/https://orchardup... and http://www.joelonsoftware.com/articles/fog0000000052.html

[skrebbel]

Not sure that was the reason.

By using Orchard, we allowed ourselves to avoid doing any server management at all. Even without a drop-in replacement, the alternative would have been to set up our own Linux servers somewhere and learn to secure them and to securely send Docker images over and all that. Assuming Orchard wouldn't break overnight, the only real risk we took was that maybe no more decent competitors would pop up in the space and we'd be forced to put our own Docker on an EC2 anyway.

If your biggest risk is to be forced to choose your only alternative, but later, then that's not a very grave risk is it?

[webmaven]

Only if you've eliminated various PaaS offerings from consideration as an alternative for avoiding administration costs.