Oh dear :( Sorry to see sandstorm go. I attribute the failure to many reasons:
1. The UI was very sloppy. For the user, one had to learn many new concepts (what is a webkey? why do apps not work on mobile?)
2. New app developer model meant that it was impossible to create apps easily without insane complexity. If you see all the apps, they had to fork from the main code base and generally lagged behind because packaging for sandstorm required a LOT of work.
3. The web frame that they added around each app was annoying. This frame could not be disabled and thus made many use cases like having a public forum, blog impossible.
4. Their own infrastructure was not self-hosted including using github (when gitlab exists), google groups (when nodebb app exists). They continued to use irc despite having a rocket.chat app as the main showcase. They should be dogfooding.
1. We know the UI needs work and have plans to improve it. We are very aware that webkeys are not user-friendly; they were always meant as a stopgap measure while we build better UI. Some things about mobile here: https://github.com/sandstorm-io/sandstorm/tree/master/roadma...
2. The amount of work an app port requires varies a lot depending on the type of app. Self-contained apps that don't talk to the outside world can often be ported in a few minutes. But, indeed, some apps need work to integrate with the appropriate Sandstorm APIs. We've been working to make this easier by, for example, setting up an HTTP proxy inside the app which can make communicating with external OAuth services mostly transparent, while still respecting the Sandstorm permission model. With better tools we think we can automate most things, we just haven't gotten there yet.
3. There are multiple Sandstorm apps which let you post e.g. blogs with no Sandstorm UI frame around it. We have some features in-progress which extend this to more apps. But note that part of the goal of Sandstorm is to generalize a lot of the UI such that apps don't have to repeatedly build the same things, like login, access control, notifications, etc. We need to hang that UI somewhere, hence the need for that frame. But we have ideas that will make it look a lot more like an integrated part of the app UI in the future.
4. We dogfood a lot. We write design docs in Etherpad, manage tasks in Wekan, etc. Our github, google groups, and IRC existed before Sandstorm was functional. The main reason we haven't switched over is because switching is costly and it seems like there are better things we could do with our time.
I apologize for not thanking you for the project and just criticizing. Thanks for the amazing project, Kenton. I meant for it all to be constructive and I hope you take it well.
About 4), please do consider the fact that this is the exact same issue most of your users face. We have existing wordpress blogs, forum that we would like to migrate but cannot. Most apps have import/export which is broken (including wordpress which is supposedly mature) :/
I agree, import/export in Sandstorm rarely works today, and that's a problem. It's one of those things that we've wanted to address but haven't been able to get to, because there are so many things.
But we're getting close on this one. We recently made some big strides implementing the Powerbox, which allows apps to request permissions to talk to each other and to the outside world. We've also implemented the basics of the in-app HTTP proxy which allows HTTP communications to feel transparent. With a little more work, an app like Wordpress could make a powerbox request to connect to your old Wordpress blog in order to migrate data.
Honestly, a lot of what's wrong with Sandstorm boiled down to "we need the Powerbox to do that, and we haven't had time to fully implement it yet, because we need to focus on things that generate revenue in the short term." We finally implemented some critical pieces of the Powerbox in the last month (app-to-app powerbox is now functional) and, as the Powerbox was always my favorite part of the whole design, I'll probably be working on it more soon.
Hey Kenton - sorry that the business hasn't been as successful as you were hoping for. I am very surprised to hear that you had 0 paying customers though.
One of the UI changes that I would make is that Oasis defaults to the free plan. I actually selected a paid plan on the website, but decided to wait and see if the free plan met my needs. It seemed like it did, so I never took the time to upgrade.
> I am very surprised to hear that you had 0 paying customers though.
Not exactly true. We had a handful of paying customers for Sandstorm for Work, and we have enough paying customers of Oasis to pay for all of Sandstorm's services. But not enough to pay for employees -- people are expensive. :/
We have experimented with ways to push people towards paid plans on Oasis, but it's a tricky balance between revenue and user growth. I agree we should experiment further.
Would you consider just adding a donation box? I for one think that it's very important that this thing gets developed. I think you're doing a lot of things right, and it could encourage proliferation of self-hosted applications. This needs to stand as a challenge to the companies that would own our data, and I understand that it does not lend itself to a normal business plan.
I imagine a lot of people feel this way, and may be inclined to donate in addition to or instead of their Oasis account.
I'm thinking about maybe extending Oasis with ways to specify a donation amount separate from the subscription fee, for finer-grained control over donations. It's most efficient for us to have any payments go through our existing payment system there, rather than use other services that charge higher fees. No concrete plans at the moment, though.
One of the things that would probably be super helpful, is figuring out how to donate to Sandstorm app authors and promote the growth of the ecosystem.
Thanks for building Sandstorm, Kenton, and I found the model interesting, though there was no way I'd use it yet because it's a risk to bet on an unproven startup / project.
This is the same reason I'd use Node or Rails, not some niche web framework no one has heard of. Or Swift or Java, not OCaml, say. And so on.
I wish there was a solution to this chicken-and-egg problem, so that genuinely new and better ideas like yours take off.
Open-source helps, but isn't enough, since there are so many abandoned open-source projects, and I don't want to take on the responsibility of maintaining Sandstorm if the team moves on to other things.
Yeh such a shame that such a promising open source project couldn't find a way to make the business model work. I really like/use it for a number of NGOs in the field who really needed something self-hosted but quick to deploy and easy to manage.
I tried it a while ago and was blown away by the weird restriction of requiring federated login from providers like Google to use a system designed to be decentralized. Seemed like a really strange arbitrary restriction that prevented its use on private networks for one.
That was a restriction very early on, but we've supported e-mail login for a long time. And as of today, LDAP and SAML login are now available in the base project as well (used to be paid features), so you can run a local LDAP server or SimpleSamlPhp for self-contained login.
There is also the passwordless email login method, where it sends you an email with a token to login. You can use this with any email account.
The reason a traditional "Sandstorm account" option has been skipped is I believe because they felt things like 2FA and such and other security features common to accounts like Google and GitHub would take a lot of work to implement themselves and that these already offered that.
It has also always been on their roadmap to figure out a way to do some sort of GPG login or something.
The outsourced login is the default, but it's optional. You could easily set up email/magic link based login on both Oasis and the self-hosted version.
Two things I feel deserve note here beyond what others have said:
1. Sandstorm has not "gone"! It is still here, will still be worked on, and all of the current services they run will continue to run!
2. As much as I am a fan of Sandstorm's approach first and foremost... I've been following news from Cloudron and they are pretty cool too. When I first looked at them they were closed source, and now they are open and supporting self-hosters and everything.
And I love the UI, but I pretty much... hate modern UI.
I wish I felt your optimism that opensource projects just chug along with no monetary motivation/investment :) Keeping apps updated and the platform secure is a lot of work. I am also reading in other places that kenton will keep oasis running pretty much single handedly. All this seems like a lot of responsibility (might not be much work though).
I suspect you may be overestimating how many people have kept Oasis running so far! Sandstorm.io never had a large group of employees, and managing Oasis has never been a large part of what they were doing. Ergo, I suspect I'd be accurate in saying Kenton was already keeping Oasis running pretty much singlehandedly. :) He has confirmed he will still have a couple other people able to tend to it if he is unavailable as well.
Indeed, I've been essentially single-handedly running Oasis since it launched (there was a mechanism for others to help if I wasn't available, but in practice it was only ever used once or twice).
Oasis upkeep requires only a few minutes of my time each week, and that's mostly for the purpose of pushing an update.
1. The UI was very sloppy. For the user, one had to learn many new concepts (what is a webkey? why do apps not work on mobile?)
2. New app developer model meant that it was impossible to create apps easily without insane complexity. If you see all the apps, they had to fork from the main code base and generally lagged behind because packaging for sandstorm required a LOT of work.
3. The web frame that they added around each app was annoying. This frame could not be disabled and thus made many use cases like having a public forum, blog impossible.
4. Their own infrastructure was not self-hosted including using github (when gitlab exists), google groups (when nodebb app exists). They continued to use irc despite having a rocket.chat app as the main showcase. They should be dogfooding.
The alternatives today are at https://github.com/Kickball/awesome-selfhosted#self-hosting-.... I recommend https://cloudron.io. They focus simply on installing things and don't invent a new developer model (it's based on docker)