One of the common misnomers around the migration away from toxic tech stacks is that the options are either 1) services managed by a company or 2) everyone #selfhosting themselves.
There is however an often overlooked 3rd option of community-scaled infrastructure. Here a group identifies their needs, plans & deploys to meet them. Much like a community garden, that infrastructure has people skilled & dedicated to its upkeep in providing for that group, working bees & skillshare as needed.
1/n
Here are some examples of this at work, in this case the Slack alternative Mattermost:
1. Our own instance in DE, used for online training
2. My friend's instance served from under her desk, on which I teach her students in CA
3. An instance in CH hosting thousands of environmental defenders that I deployed
4 An instance we deployed in IS hosting a US immigration support NGO, resistant to ICE warrants
There is no one deployment for all here, each instance meets the unique needs of the group
@xr1st0ph Can compile that out easily if handy with Go, or just use the drop in binary from Frama:
@xr1st0ph It's just a few lines and a diff quickly shows it's gtg. If concerned about the fork, just grab the source, patch and compile. Takes a few mins.
Even so, Framasoft have a longstanding great rep.
@xr1st0ph We work very hard at this, and have been at it for years. Nonetheless, you may be better at convincing groups to use tools you think they should use than we are.
We find trying to convince folk is not always the wisest end game. Rather, a compromise is sometimes necessary for a successful staged migration away from jurisdictionally or materially compromised services, with outcomes of higher platform morale, so lower chance of regression &/or splintering, & better overall org opsec.
@JulianOliver THIS!
Are you interrested in a videocall? taking this further? I would love to learn something about your work.
Julian Oliver
CRS
