FOSS cooperatives - A white paper (?)

Great idea. Shall we collect the resources here?

The chapter "Free/Open-Source Software as a Framework for Establishing Commons in Science" in Understanding Knowledge as a Commons is good (https://scholar.google.co.uk/scholar?cluster=15665048939801225643&hl=en&as_sdt=0,5)

The book "Social Architecture: Building On-line Communities" shared by @horatiotrobinson on the instance looks very good - some Ostrom style design principles on successful FOSS projects. https://hintjens.gitbooks.io/social-architecture/content/ It would be interesting to see how the coop model could help fulfil some of those principles.

Yes, let's use this thread to collect all the material and, in due time, to schedule calls and/or other meetings.

I haven't come across any literature on FOSS and cooperatives, but The Craftsman by Richard Sennett has some wonderful things to say about the potential for good 'craftsmanship' in open source approaches (as opposed to private corporate ones). It could act as supporting material singing the praises of open source in itself, although I'm not sure how useful that would be for the discussion happening here...

https://books.google.co.uk/books?id=SRAV0KvuOQwC&lpg=PP10&ots=DCJgrr-Och&dq=the%20craftsman%20sennet&lr&pg=PP10#v=onepage&q=the%20craftsman%20sennet&f=false

Brilliant! Thanks for sharing, the more material, the merrier

My own thinking around this has focused on the idea of "cooperative clouds," of which Social.coop is one, and which could be a replicable model that combines co-op business with FOSS: https://ioo.coop/clouds/

Thank you very much for sharing

Is there a short overview of the essential concept of "cooperative clouds" somewhere? I followed the link but was a bit overwhelmed with information.

Here's a few points I'd like to address and hear opinions about:

Is code a true common good?

- it cannot be depleted or otherwise abused (unlike any other material good)
- it doesn’t require constant care to thrive (even outdated code can still compile and work to some extent, albeit with lesser performance)
- it is agnostic to community (sometimes important projects are maintained by just one developer)
- if abandoned, it doesn’t decay (code can always be forked and be reborn as a new project)

What if the true common good was not the code, but the people working on it?
- people have finite resources (patience, skill, energy, enthusiasm can all be depleted and abused)
- people require constant care to thrive
- people gain large benefits if strong, healty communities exist around them
- even the most interested, talented and motivated can let go, if abandoned in a toxic environment

Why cooperatives? Caring for this type of common good (ie. The health, motivation, skill and wellbeing of those working on FOSS projects) could be a lot easier if those who benefit from the the work of these people were more closely knit into the fabric of the projects themselves. Potential benefits would include
- democratic decisionmaking and clear accountability
- easier funding (through both membership fees as well as donations and/or tax exemptions)
- a drastic reduction in toxic feedback (bylaws and codes of conduct would be binding)
- fair compensation for those doing the actual work

FOSS cooperative structure?
- likely to be a service coop, where memebers pay other memebers to do something for them
- non-members would still have access to the produced code, but no voting rights
- great attention should be put on balancing memership fees

Although you might be able to argue those leading points for some definition of "code" akin to a painting, I think in practice I find very much the converse. Software can be abused in various senses: misused, subverted, hacked etc. It isn't stand-alone, passive, platonic, it's part of an evolving ecosystem of other software and human needs, and will become dangerous, faulty or useless unless evolved in step with its environment.

Saying that, I find I am not truly disagreeing! I am really only reacting to the way you framed code as an eternal platonic resource and people as the true commons requiring maintenance - they are a system. My reaction comes from working with managers and customers. The idea that software just needs to be "developed" once, then it works forever, needs to be strenuously avoided!

Your main point stands: "Caring for this type of common good [...] could be a lot easier if those who benefit from the the work of these people were more closely knit into the fabric of the projects themselves."

The value - the common good - does not lie wholly in one part or the other, but their interactions. Software engineering as permaculture, I suppose?

Thank you for your feedback! The points I made above were meant to kickstart a discussion and I see they succeded :) So, if I understand correctly, we have to deal with a "double layered" commons, when it comes to code: we have the actual code (in whatever form it may come) and the people working on that code. The first layer would be a "knowledge commons" and the second would be something like a "material commons". Would that be correct?