Support exclusively Sandstorm


#1

I’m a big fan of Sandstorm. At the same time I understand that not every Wekan users want to use it, and prefer more traditional hosting and administrating using either Docker containers or vanilla NodeJS+MongoDB installation. I have also encouraged Wekan integration on various cloud platforms.

Sandstorm has improved significantly since my first Wekan package on it more than a year ago. It is the easiest platform for installing and updating Wekan. It’s way most secure than alternatives. And it’s about to get even better.

The Sandstorm shell will indeed soon receive its Powerbox UI that is really at the core of the platform design. In short, it will make an application like Wekan more powerful by being able to have some solid integrations with services provided by third-party applications.

I believe that using the full potential of the Sandstorm platform would benefit Wekan. However it will become difficult to maintain different feature implementations for different platforms. Things like sending an email, registering a user, uploading an attachment file, backing up the data, sending usage statistics to a third party application, and many other desirable features will have very diverging implementations on Sandstorm versus other platforms.

So as the Wekan lead developer, I wonder if we should focus Wekan development to support Sandstorm exclusively. I’d like to heard from users using Wekan on Docker or with vanilla-installation, what will need to be improved about Sandstorm before they consider a switch. To give an example I think that it is not easy to host a public board with a clean URL (http://myproject.io/roadmap) on Sandstorm. I’d like to learn more of these edge cases from Wekan users, I would also like to read what other teams like Rocket.Chat are thinking on the matter. And if there is any question arising about Sandstom capabilities, I’m confident that their core team will provide some valuable responses.

If you don’t know Sandstorm, I recommended reading the “How Sandstorm Works” article.


#2

I just added wekan to our quickstarters . sloppy.io only needs a working docker-compose.yml. If it works with compose, it will work with sloppy.io. so from my pov you should not forget about docker :smile:

best

mike


#3

I love Sandstorm, its a great idea and the implementation is very impressive. I tried it locally as well as their demo and played around with their vagrant-spk for building images. It really opened my mind to the possibilities.

So, after that I also watched some videos of Sandstorm to get a better idea of where they are and where they are going. The vision is amazing and I am also waiting eagerly for the moment they will turn on Powerbox and enable communication between grains. it seems this is where they have always wanted to be and huge congrats to them.

However…I would recommend you don’t build yourself into this corner just yet. Wekan and pluggability has so much potential in its own right that I fear that right now you would be severely limiting adoption and uptake if you build only for Sandstorm. Right now Sandstorm is a promise, a good one, but still just a promise. They have some ways to go yet before efforts such as sandstorm only Wekan efforts can help them along. You have already a good integration with them. Thats great and it certainly helped me think about how all these pieces could fit together but my recommendation is to leave it there until you see more uptake of the sandstorm platform (I think Sandstorm still a difficult idea for people to understand and this might be their biggest hurdle).

As I said, I love Sandstorm. Its great there is a Wekan app there but I suggest waiting to see where it goes before you build yourself exclusively into that approach.


#4

I love the things sandstorm is doing, and for sure the people writing it. Great group of people!

But, that being said… I don’t think going exclusive to sandstorm is a good move. When I see a piece of software completely locked into one platform, i’m going to pass it on by and keep on looking. The beauty of things right now is you have many deployment options.

So really the issue here isn’t about whether or not sandstorm has the features we need. Sandstorm is awesome, and its getting better every day.

The issue is platform lock or no platform lock.

My vote is no platform lock.


#5

I definitely think independence is the best approach. I don’t want the Sandstorm ecosystem, I just want the benefit of the Wekan app. Fast, small, and easy to manage without the headache or overhead of another platform and it’s own inherent issues or bugs.


#6

Our goal is to make Rocket.Chat as widely available as possible, so we are definitely against being exclusive to Sandstorm. But we love the love the platform so much, we are committed to go the extra mile (or km in my case) to make Rocket.Chat fully compatible and embrace the platform when it detects that it is running on Sandstorm.


#7

I second Rocket.Chat approach - even though it’s more work.

I believe Wekan has a huge appeal and potential (just look at Trello), and limiting it to Sandstorm would cut off all the people that may not have the choice to use that platform.


#8

IMHO exclusive support for a specific service makes little to no sense.

I mean what if I prefer to use sandstorm alternative such as cozy or yunohost ? what if I know what I’m doing or want to learn to host by myself ?

I know to stay away from floss that goes the “excusively support” route. It is obvious that people will want to and will use wekan out of sandstorm which often leads to fragmenting the code base and reinventing the wheel and decreased security and so on.


#9

So, as the tech lead of Sandstorm, I am biased, but let me try to make a few points here…

First, I would point out that to some extent—which will increase over time, as Sandstorm gains new interesting features—Sandstorm is more like a tech stack than a target platform. No one would fault Wekan for being exclusive to Meteor nor argue that it should also support Ruby on Rails in parallel—that makes no sense, since it would require rewriting the whole app. Also note that Sandstorm is open source and can be installed in almost all the same environments where you might install Wekan today, so it seems to me that you could think of Sandstorm as just another dependency of Wekan.

Second, keep in mind that it is very easy to say “No, I don’t want my software to be exclusive to one platform” when you aren’t the one maintaining the code. Of course, who would ever say “Yes, all things being equal I’d rather have fewer choices!”? Nobody, obviously. But keep in mind that time Maxime spends maintaining non-Sandstorm ports is time he is not spending adding new and useful features to Wekan. Sandstorm as a platform alleviates quite a bit of work from the developer, such as authentication, access control, and collection management. As a Sandstorm exclusive, Wekan could delete those parts of its codebase and focus on the parts of the app that are actually unique. But as long as Wekan still supports other platforms, Maxime will need to keep maintaining and testing this code, which is real, significant work. Are you sure you dislike Sandstorm so much that you’d forgo new features in Wekan for the ability to avoid using it? (If so, I’d love to know what we’re doing wrong…)


#10

Sandstorm is a great product but I wouldn’t use Wekan if it was only sandstorm compliant. It doesn’t suit my use case.


#11

I was drawn to Wekan specifically because I am in a situation where I cannot host business-sensitive data on Trello. If it goes all in on Sandstorm, I’ll be forced to fork or reimplement.

As much as I respect you, @kentonv, you’re wrong on this one. It’s not about liking or not liking Sandstorm. It’s about on-prem versus hosted. Many, many, MANY organizations will simply refuse hosted options for something as sensitive as software engineering. Sandstorm is cool but it would be an automatic dealbreaker for me for this use case, because we’re basically back to a neat clone of Trello that encourages installing in the cloud, which was the entire reason I looked for a Trello alternative in the first place.

This is of course mitigated by the fact that I can install Sandstorm on my own gear, but that’s a whole different ball of wax. I haven’t investigated standing up an on-prem Sandstorm, but if I’m finding myself down that rabbit hole just to get something like Wekan going, I’ll likely move on.


#12

@jeds It sounds like you think that Sandstorm’s self-hostability is some sort of sideshow but that we primarily want people to use Oasis (our managed hosting). That’s not true! Self-hosting is our main focus! Oasis exists because some people just don’t want to self-host, and we want to make sure that Sandstorm apps are still available to them.

Installing Wekan on Sandstorm is probably overall less work than installing Wekan without Sandstorm. We’ve put a great deal of work into making Sandstorm really, really easy to set up, and then making it really easy to install apps from there. Installing Sandstorm on a Digital Ocean box, for example, should take five minutes, including setting up DNS and getting an SSL certificate. Once installed it auto-updates itself and apps so you almost never need to spend time on maintenance. Please consider trying it before dismissing it as too much work… https://sandstorm.io/install

That said, my previous reply was intended to be a bit of “devil’s advocate”. I do not actually want Wekan users to be forced to use Sandstorm if they don’t want to, but I do want to learn why people would prefer not to so that we can fix it.


#13

Fair point! Its a great platform, Sandstorm. I think there are two issues that I’d like to see improved…first, the UX could improved a great deal. It has a very dated feel and feels very much like a DIY app. if that is deliberate then it works! (thats not a sarcastic comment, I can see good reasons for keeping the UX rather lowfi at times). If you don’t intend this DIY kind of feeling then I would recommend a good clean up of the UX.

Second, when I first went to the site I felt like I had to wade through a lot of ideology and large claims while trying to work out what exactly sandstorm is. I get it that you guys have a big vision, and I applaud it, but honestly, this is too much information:

Plus there were some statements that made me cringe…like:
“That means you can put sensitive secrets in any app and be rest-assured that your data is safe.” (really?)
"Most bugs that would be serious security problems on other platforms either don’t matter at all on Sandstorm or have drastically reduced impact. " (very very vague statement)

and many things left unexplained eg, this is the first time the world ‘grain’ appears on this page:
“You can always see who has access to your grains - including people with whom you shared and other grains to which you connected it – and you can revoke these connections at any time.”

yikes!

You guys have a great vision, I love it. I hope you win! But I think you need to simplify your messaging and make a sleeker UX…both of these, by the way, are operations of ‘external communication’ and I sense you guys aren’t putting enough emphasis into this aspect…

Good luck. I hope you rule the world sometime soon! its an awesome project.


#14

@kentonv Fair. But keep in mind, I’m in corporateville. Standing up a DO box, while cool for personal stuff, isn’t how my world operates. To even consider getting Sandstorm going in my world would require about a month of process. A Docker container, on the other hand – I might already have Docker stood up, and with Wekan’s license, I can just try it out.

Exclusively Sandstorm would undermine all that, no matter how easy it is. And totally, I didn’t mean to sound like I was dismissive. I just know my process and I wish it were more Google-y or startup-py.


#15

Here is my story:

I actually wanted to try out wekan on a local virtual machine (using virtual box on my debian notebook) and I chose sandstorm for my first attempts because I was appealed by “one click installation”. However I did not even mangage to configure the dns stuff correctly because the vm running sandstorm is only visible within my local network so the url for the setup token

https://ongu5.sandcats.io/setup/token/2632217b2367823c8409bea9b1742b67054bc157

was not reachable.

Using just the wekan docker image seemed easier for me because there was one layer of potatial problems less.

So I would like a solution/guide for trying out sandstorm on a local vm (even without connection to the internet (after downloading all necessary stuff)).


#16

I would prefer a vanilla NodeJS + MongoDB installation.

I hate Discourse because they are Docker-centric.
I will hate Wekan when they will be Sandstorm-centric.

I am a linuxian, and as such, I greatly prefer universalism.
So if you do that, I will migrate from Wekan + Gogs to GitLab with its Issue Board.


#17

@HLFH

Wekan is available on multiple platforms, including vanilla install, Docker, Sandstorm etc.

We are adding more platforms, not discontinuing them.


#18

@xet7 Discontinuation was a concrete idea one year ago. But time has changed.

Thank you for being part of this project.