Processes and practises for informing our direction

we're not actually building tools here (just reusing existing ones)

This is key? It underlines the fact that, when tool infrastructures are designed/ developed, what in practice is being designed is the work of those who mobilise them in practice: ‘the users’. So no, we won’t need to do much (software) tool design here (maybe some FLOSS hacks?), and configuring existing apps will do just fine most of the time, but we will need to design the work that we mean to do here, the collaboration that we mean to enable - the society of social.coop. A large part of the ‘technology’ will be culture, agreements, narratives, roles, valuations.

It’s ‘design of design’ that’s at stake? This is challenging but not the first time it’s been attempted . .

In the 80s/90s - when there was great concern over ‘deskilling’ through ‘the new technology’ - there was a movement starting in Scandinavia, being taken up in the US, for ‘work centred design’, with a ‘tool’ and ‘skill’ orientation. It became part of the field of Computer Supported Cooperative Work and became labelled ‘participatory design’. Those folks always remained aware that it’s the work that’s at stake, not the code. And that the design of new ways of working (while retaining valued older modes of skilful working) was the aim, so that the work could be done skilfully and comfortably, to achieve the workers’ aims. The digital tech is just a means (sorry coders ;-).

In another comment I’ll cite some stuff from this background.

Today this is harder. The digital tech is highly distributed now, so more layers of (digital) architecture are implicated in the choices of ‘which tools’. The tool infrastructures are quite fully configured, off the shelf, especially when platformed - although they also are often in smaller modules (all the way down to individual code objects). They come ready wired with cultural/economic forms (or honeytraps, as with all things Google). Some are difficult to refuse or reconsider because they have a huge installed base on mobile devices. They are seductive because many of them seem to be ‘free’. So the 90s game can’t be played today as it was then. Some innovation to be done, in ‘design’?

So no, we won’t need to do much (software) tool design here (maybe some FLOSS hacks?), and configuring existing apps will do just fine most of the time, but we will need to design the work that we mean to do here, the collaboration that we mean to enable - the society of social.coop. A large part of the ‘technology’ will be culture, agreements, narratives, roles, valuations.

The core task to me, is running and maintaining a server. A sysadmin job basically. This often ends up very detached role from the whole project, and I think that has happened in this case. The discussions about what tools have become disconnected from tasks about running the server.

It's not actually that much work, but it needs to have the culture, roles, etc. in place, at least for it to be interesting/motivating to me. On our projects I work on we manage to run mailservers, forums, chat, basically whatever services we find interesting or useful with not much extra effort. It's fun even.

But in those other projects it feels like that work is done much more in the context of the project - the software tool we develop + the community of it's users. In the case of social.coop I'm kind of missing the bit about what it is. It has a community of users, but I suspect most of them see it as a mastodon instance. Aside from that a small number of people in the loomio seem to have a bigger vision, but not all the same bigger vision from what I can see.

Illich and Schumacher . . .

Illich isn’t talking directly about the design of tech. His argument is with imposed ‘radical monopolies’ of service provision, which are in the hands of techbros of one kind or another (including medical doctors, agricultural scientists, administrative 'scientists', ‘domestic scientists’, ’management scientists’, pedagogical professionals, etc), but which serve the extractive and controlling purposes of corporate organisations and States. So it’s a deeply important argument, but not directly about the tech form of tech infrastructures.

Schumacher and intermediate technology may be nearer the mark. His argument was pitched in an era of ‘development’, in which technologies were being implanted in ‘developing’ countries via 'aid' which hooked them into value chains that delivered profits in 1st world countries, notably the US, and had unacceptable costs for the client populations in money, dependency and lost ‘sense’ of tradition and place. ‘Appropriate’ technology was designed/selected to keep things under the control of indigenous populations, within vernacular capability, affordably. Today we would say, sustainably. The argument is close to Illich. But closer to the tech choices.

I’m not very knowledgeable regarding where ‘appropriate tech’ practice has got to today, under ‘post-development’ consciousness. Must have diversified and diffused quite a lot? Who else here knows? Obviously, P2P hardware approaches are an aspect of this - design global, build local? Fablabs etc? Guerrilla Media Collective is pursuing this principle, with their evolving design for DisCOs. DisCO is a global coop design that includes organisational/cultural ‘tech’ (care work, commoning), value-accounting tech, work-coordination tech: and digital-mediation tech (actual apps). So maybe the upcoming Reading Group discussion on DisCO will feed in here?

Illich isn’t talking directly about the design of tech. His argument is with imposed ‘radical monopolies’ of service provision, which are in the hands of techbros of one kind or another

To my limited reading (i.e. just reading this comment, but not the source) this seems highly related - in that the ability of social.coop to provision other services is dependent on our practises/processes for doing so.

Some of the discussions in this thread suggest using hosted app platforms, which, in the case of cloudron, on the one hand open up the possibility of service provision by non/less-tech people, on the other hand it then uses this to re-enclose those service provisioning capabilities inside a private company and their proprietary software (cloudron is no longer open source, and even if it was a significant portion of the burden of running that service would still remain out of the ability of most people).

I’m not very knowledgeable regarding where ‘appropriate tech’ practice has got to today,

nor me :) but I would just love it if technology (in the case of social.coop, running various web services) was designed to be accessible to people to run, instead, all the tooling/processes/practises (software libraries, apps, frameworks, server management, etc) we use are borrowed from standard businesses, which work on the assumption there is a pool of skilled/ready/willing techies and other workers to implement it all, and a huge bulk of the development of technology goes towards enclosing capabilities, not sharing them. Oh what a world it could be.

So glad to see my favorite friends Illich and Schumacher here:)

My inclination is to take a highly experimental and playful approach, testing out various tools on a trial basis and seeing what people like. I'm particularly interested in ideas like the DAO experiment and Matrix, which is a really fascinating project.

My recommendation is to create a [testing] framework in which we run trial efforts to test user interest and technical requirements, for say a month at a time.

To date, the tech team (of which most of it is me right now) has barely had enough motivation/capacity for keeping mastodon running and updated.

I do like an idea to add more tools, and a methodology to work out how to do it, but it has to be grounded in the reality of now too. You can see a nice place to sit across the valley, but how to get there when there is no bridge?

I have a feeling there is a possible fork in the approach here:

1) work with the small seed that I hope is still growing in our tech team, we can work to build up a bit more communication between people, and find out how to motivate people more... step by step

2) re-imagine social.coop as a cloudron/yunohost/sandstorm/collective-tools/fairapps instance

Personally, I can work with 1 - most of my life the past few years has been working with tech projects that lose all the developer/tech motivation, and help build it back up (not really happening with social.coop so fast, in truth, social.coop doesn't motivate me very much, I don't really know what the project really is besides the place I go and scroll posts occasionally, and only really joined the tech team to save it from being turned off entirely).

If 2 is the way, then it wouldn't be for me for a variety of reasons, but I could help the transition.

A couple of significant prompts put up by you here today @Nick Sellen thanks. I'm a bit snowed, and can't respond substantially at present. But I feel these are things all social.coop folks should be pondering.

We still don't seem to have a core (or identifiable, recruitable cores) of collaboration to organise around - except hosting and moderating a mastodon instance - two commitments which, as you're pointing out, fall into two distinct buckets of attention anyway, and lack somewhat in real-world grounding?

The collaboration that there is, happens in streams of toots (yes?). But THAT isn't 'a project' by a collective, is it? It's peer-to-peer communication in multiple networks. Is being a 'common carrier plus ethics' what social.coop set out to be? Twitter plus ethics? Telegram plus ethics?

Work-oriented design of computer artefacts

Some references attached, to Scandinavian 80s/90s tradition of work oriented design of computer artefacts, and 'collective resource' tradition of codesign with labour unions . . From the days before git/P2P/agile code hacking, web apps & digitally mediated organisation, this tradition invites remixing in today’s coop practice. Its 'tool' notions, coproduction principle and weaving of tech/theorising/democracy are valuable for us here?

A key item is Pelle Ehn’s 1988 PhD thesis/book drawing on 20 years politicised design practice in Denmark Sweden Norway: Work oriented design of computer artefacts. It's posted here.

The approach cross-fertilised in the 90s, as trade union drivers faded, field anthropology (ethnography, ethnomethodology) made an appearance, and cooperation tech became generic. The fields of Computer Supported Cooperative Work and Participatory Design emerged. There’s a 2016 Handbook of Participatory Design. Some samples of this stuff are here.