Digital infrastructure/protocol

Nextcloud is released under the AGPL, this is one of the strictest Free Software license that is available, see Why the Affero GPL. The manner in which Nextcloud is marketed is orientated towards business, because selling to this sector is how they pay the bills, but there is no doubt that their committent to the Free Software movement is solid, look at the Wikipedia summary of the ownCloud split, and listen to this talk.

The provisioning of the Collective Tools stack is based on Ansible code I wrote.

@Stacco Troncoso Where are the Guerrillas at, regarding the mainstream tools you use in DisCO - Slack, Trello, google stuff. D’you have a migration plan (eg the NextCloud stack)? And if so, what are your favourite alternatives?

We wrote about this in the Guerrilla Translation Handbooks. Here is an excerpt:

These are the tools we are using right now: the tools themselves are subject to change, but the logic behind their use probably won’t.  Our priority at the moment is to maintain both flexibility and resiliency, so we have chosen tools that we can rely on right now, while keeping our options open for when a change becomes necessary or would present an improvement to our existing systems. We want to use more open source tools and are invested in co-creating our own tools with sympathetic allies to help deploy the technical/structural aspects of our governance model.

Right now the bulk of carework hours are begin spent on project dev and urgent legal/financial issues, combined with the time we spend on Pro-bono work and paid work, there's not much time left over for tool migration and systematization atm. We need to do it properly, so this includes mentoring, documentation, rewriting the wiki and manuals, testing features etc.

It's always on the radar and we're looking at CoBox with interest as that's probably the easiest plug and play solution.

Aha! Cobox is built on Dat. So, it differs from anything else that's going. Stacco's link to Cobox worked.

CoBox is built on Dat. Dat is a modular peer-to-peer technology stack. You can find a good explanation of how it works in the guide ‘how Dat works’, and you can find out how we’ve made use of Dat in our developer docs. At CoBox, we’ve used Dat to build fully encrypted private spaces that synchronise seamlessly across multiple devices.

CoBox aims to encourage small- and medium-scale infrastructure as a service. This means non-technical people can plug in a small computer in their home and begin providing back-up services for their friends, neighbours and themselves.

CoBox is a Dropbox-like shared filesystem built on top of Dat.

Data is stored on your device, and we sync across the network if it is available, or across your work or home wifi.

Ah! Cobox is a Dat server, literally in a (Unix) box, plug and play. If you want to be a server admin, this is for you. For the rest of us . . well. The demo video has more techspeak than I really want to be listening to. And Cobox is just the secure P2P network tech (eg 'backups for your friends'), no user-oriented tools on it (apps). So, not in the same class as other things discussed in this thread. Not remotely similar to @Graham 's 'cooperation as a service' for example.

I love the P2P principle of dat, and experimented with it a while back, as a way to create a website in markdown. I quickly ran aground on seeming lack of non-geek guidance and support. With Cobox, looks like things haven't come on that far, even though the hardware/operating system is now packaged as a kit? What do others feel?

It's a shame, bcos the public presentation of the project, and the team, and their ethos, and their supporters, all look very appealing. But who's wanting to be a server admin? Seems to me, the apps, the interface and the naive-user service relationship is some way down the road.

Our priority at the moment is to maintain both flexibility and resiliency, so we have chosen tools that we can rely on . . . We want to use more open source tools and are invested in co-creating our own tools . . \[but] . . there's not much time left over for tool migration and systematization atm. We need to do it properly

That's pretty convincing.

The tools themselves are subject to change, but the logic behind their use probably won’t

@Stacco Troncoso Could you provide a pointer to where the logic is spelled out clearly (in the Handbook somewhere?)? Seems like we should be taking that in to our present discussion. A frame like that would be good to have - maybe OpenCoop can adopt it?

Sure. Check the Guerrilla Translation Handbook on tools, it starts at page 139. The proprietary tools let us pilot the features and functionality we want to see in free tools. The key is in having shared practices and agreements on how to work the tools together.

pilot the features and functionality

Yep . . so, a phased, evolutionary approach. With an intention to refactor things, some way down the line? getting out of the proprietary honeytrap? Does OpenCoop have the long-termism, to just 'get on with it' - the collaboration, the project - and assemble an ideal, politically correct tool system somewhere a little way down the line?

The key is in having shared practices and agreements on how to work

The work protocols are the thing? The apps and platforms are . . just tools 😆 The users' common work-focus, and their skill at doing 'collective' and 'commoned', are the core things? I would say that, I'm a culture hacker 😉

The logic underlying the toolset is still something that we need to build around? Handbook page 139ff.

Maybe take a bit more time, put up with the free, low privacy stuff for now, and meanwhile get some sort of architecture governance set up, with a small team accountable to the rest of the coop for transparent design and choice (according to weighted principles and basic requirements). Everyone votes on the principles / requirements and the weighting, not on the solutions. The architecture team make a rational choice of designs (not just products) justify it and live with it... and they implement and maintain it for us through a lifecycle. Or is that too corporate?

Sounds terrific Nick! Very unlike the way most 'voluntary' formations proceed. So this will be a challenge? It's simply state-of-the-art practice in participatory design of an infrastructure . . so as I said, quite challenging 😉

This means making a temporary agreement/protocol in June, around free, low-privacy means. Providing for a more durable, systematic protocol (and development undertakings?) later . . end of the year? Sooner? What's realistic?

@Oli SB @Simon Grant how d’you feel about this approach? Are you inclined to go straight for ‘the final’ protocol in June? Or to factor in an evolutionary stage of a few months?

I think this has the basis of something worth going with. A couple of tweaks from me...

1. What really seems to me to matter for requirements gathering is that people -- users that is -- get a real chance to express and have their needs and values understood, alongside them understanding those of others as well. This seems to me necessary in order to get beyond the "why don't you just do it may way, because it's better / simpler / more ethical / more obvious".

2. This kind of empathic listening to / understanding of others opens the way to something that is way beyond 'voting'. Once I really understand what matters to you (and others) my imagination -- and indeed our collective imagination -- can work on this to find solutions that serve more or less everyone.

3. If the governance is set up to work in the longer term, my guess is that it will serve well in the short term too. So to me it's not a case of finding a 'final' protocol (though who knows, with a really good process that might just appear) as finding a workable commons-governed way of working out when a change is needed and how to change it.

Having said all that, I'm not at all against a really good simple solution just because it happens to have been invented by one person. I'm thinking e.g. JSON. But much much safer if it is not promoted by its inventor, but recognised by others as a really helpful way forward.

So referring back to @Nick Meyne , how can we most effectively gather the "principles and basic requirements"? I'm not sure about this, but some process of dialogue seems to me to be key. An idea of the top of my head: everyone's requirements are written down by someone else after that dialogue process.

It's not a coincidence that again here I'm trying to point a way away from an individualistic methodology towards a collective, commons one.