FOSS cooperatives - A white paper (?)

I think I'm arguing more against viewing these parts as separate, and thinking of them more holistically as a system. Just like you're saying FLOSS users and producers need to be more closely knit.

I'd like to then say how... but I need to think more about that before I could articulate anything.

"Double-layered" as a description could be productive as an entry (via Michele) to getting at the simultaneity Nick refers to. Diction is indexical -- that is, the actual terms we use have a "life" that extends into the future. So we need to set the base well in terms that are distinctive enough to avoid ambiguity (such as "holistic" which could mean anything) . . . doing an academic-y article could be a means to sorting out the language we all agree to...

doing an academic-y article could be a means to sorting out the language we all agree to

this is indeed the (long-term) goal of this thread! The devil hides in the details, as they say... :)

Michele @mi Pointing to the people rather than the code is a deeply important point. There is great value in the commoning of artefacts like code (code is just a document, an executable document). But when we get into the areas that are normally theorised in terms of knowledge or skill, then what we're dealing with is labour power. The commoning of labour powers is quite another thing, and utterly important. I understand 'culture' to be the totality of labour powers in a collective; so we'd be talking of 'cultural' commons in that (rather technical) sense, as distinct from material commons: code is a material commons (material with special digital characteristics as identified by Michele - non-depletable, non-rivalrous, etc).

I've a whole bunch of thinking to do on these lines and right now have nothing to offer that spells this out clearly. But in due course . . . Meanwhile - yes, do think about the commoning of skilled hacker labour-power alongside code.

Great discussion, thanks for the excellent kickoff Michele.

I think I agree with Nick's point that you can't fully separate the code (and designs and build systems and etc) from the people and processes around it.

But that only reinforces the original point. From what I've seen so far of knowledge commons the assumption seems to be that the problem to watch out for is the free rider problem, or collective inaction - not that people overuse a resource, but that they don't bother to contribute. (Which does need addressing in it's own right.) But it feels like it has been ignored or given less attention at least that there is a resource that can be misused/overused, i.e. people's time and energy.

We're all saying the same thing I think, that without strong governance FOSS contributors can get burned out and that has to be addressed.

I do still think there's some merit to exploring the differences in commons terms between the code/artifacts and the people/processes (the code and associated artifacts are undoubtedly non-rivalrous, and people's time and energy rivalous, right?). If for nothing else as a way to help shine a light on why the latter has been neglected.

Sorry for the late reply, I somehow missed your comment! I absolutely agree on the need to investigate the "double nature" (sorry for borrwing a religious term!) of the FOSS knowledge commons. The separation I proposed in the above points is precisely meant to bring the difference between code/artifacts and people/processes under scrutiny, as they are two fundamentally different yet interwoven things.

Interwoven....simultaneously....co-producing or co-creating or co-constructing code/artifacts and people/processes ..... it's the relationship among/between code and person, among/within artifacts and processes...

@doubleloop

The code and associated artifacts are undoubtedly non-rivalrous, and people's time and energy rivalous, right?

Yes! This an important insight, because as @wulee pointed out, any piece of free code loses compatibility with the rest of the digital environment unless it's maintained. This requires not just labour, but highly specialized labour. There is another rivalrous element too, that's thrown into sharp relief by hosted software like GNU Social or Matodon, which is server resources (processing power, storage, and bandwidth).

It does seem like there's quite a few hosting coops, coop clouds as Nathan called them. There's a few software-focused tech coops here in the UK but I'd describe them more as cooperatively run digital agencies.

Are there any examples of coops explicitly developing a FOSS project? If not (or regardless) might be worth having a thought experiment, e.g. what would Mastodon project look like if were produced by a FOSS coop. (Doesn't have to be Mastodon :P )

It is interesting, at this point, to introduce the concept of "cooperativa sociale" (social cooperative) as it is defined by Italian law:

"social cooperatives are meant to follow the general interest of the community in the human development and social integration of citizens by means like:
a) handling social, medical and educational services;
b) carrying out diverse activities -agricultural, industrial, commercial or service-based - meant to allow disadvantaged persons into the workplace"

Which is basically what a FOSS cooperative could achieve, as developing code for a userbase that joined a specific coop because they have interest in the software being developed by that coop can be intended as a service...

A hypotetical "Mastodon coop" could then be organized as a service coop in such a way that all the members would share the burden of the cost (eg. a monthly fee), get one vote each and recieve two different things in exchange for their participation: working members would get paid, non-working members would enjoy the service provided by the cooperative itself (ie. the code produced by the coop). Social.coop would fit perfectly in such a model, as we could become members of the Mastodon cooperative and contribute to both the development and financing of the whole project AND get a vote too.