FOSS cooperatives - A white paper (?)

@doubleloop

Are there any examples of coops explicitly developing a FOSS project?

Loomio!
https://loomio.coop/constitution.html

https://resonate.is/strategies/

Resonate.is are also pursuing an open source strategy, structured as a multi-stakeholder FairShares Cooperative under society law.

Anyshare.coop plan to
be open source, but are not there yet (see https://anyshare.freshdesk.com/support/solutions/articles/17000048699-is-anyshare-open-source-)

Structured as a FairShares Cooperative under company law.

I'm just reading the interview with Dmitri Kleiner on "The Telecommunist Manifesto" on the P2P Foundation's wiki here, which seems relevant:

https://wiki.p2pfoundation.net/Telekommunist_Manifesto

In it he describes a "Venture Commune" which might be a sketch that could be a basis for a FOSS co-op.

DK: The venture commune would work like a venture capital fund, financing commons-based ventures. The role of the commune is to allocate scarce property just like a network distributes immaterial property. It acquires funds by issuing securitized debt, like bonds, and acquires productive assets, making them available for rent to the enterprises it owns. The workers of the enterprises are themselves owners of the commune, and the collected rent is split evenly among them, this is in addition to whatever remuneration they receive for work with the enterprises.

...

The model I currently support is that a commune owns many enterprises, each independent, so the commune would own 100% of the shares in each enterprise. The workers of the enterprises would themselves own the commune, so there would be shares in the commune, and each owner would have exactly one.

So, incorporate, sell bonds or P2P finance such as described elsewhere on the wiki to raise funds to pay for up-front development and/or service creation and/or equipment, and use it to create revenue which makes the whole thing capable of providing an income to the cooperative, and via the cooperative, the members.

The devil is in the details of what is used to create revenue, I suspect. Services are easiest, software might require a custom or dual FOSS license, I'm not sure. The difference with social.coop is that the members pay fees to use the managed service, so there's no external revenue source, and members have to have their own.

On the topic of licenses, Kleiner says these need to explicitly allow members of "the community" to make a living using the created works:

What we mean [by the Creative Commons as an anti-commons, peddling a "capitalist logic of privatization under a deliberately misleading name"] is that the creative “commons” is privatized because the copyright is retained by the author, and only (in most cases) offered to the community under non-commercial terms. The original author has special rights while commons users have limited rights, specifically limited in such a way as to eliminate any possibility for them to make a living by employing this work. Thus these are not commons works, but rather private works. Only the original author has the right to employ the work commercially.

I've not fully thought this through, but putting it out here as food for thought.

This is very interesting, thanks for sharing. In a way, it mirrors my understanding of what a "commons + coops" system could look like, especially in the "commons commune" bit. I really like the idea of the common good not being explicitly owned by a single group of people, but rather managed by a group of cooperatives, since it's basically the way all organisms on earth are built: the common good (ie. survival, health, reproduction etc...) is not the exclusive achievement of one single organ, but rather a collective effort of all organs. Following this pattern, we can assume single individuals to be like cells, who become part of larger entities (cooperatives) in order to achieve a common good (code development, maintenance and distribution in this case); just like cells in a living creature become part of organs all working together to achieve survival.

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...

This from Michele is solid visioning:

"the idea of the common good not being explicitly owned by a single group of people, but rather managed by a group of cooperatives, since it's basically the way all organisms on earth are built: the common good (ie. survival, health, reproduction etc...) is not the exclusive achievement of one single organ, but rather a collective effort of all organs."

@wulee

So, incorporate, sell bonds or P2P finance such as described elsewhere on the wiki to raise funds to pay for up-front development and/or service creation and/or equipment,

This sounds a lot like what blockchain startups are doing with ICOs. I know there's a lot of snake oil for sale in the blockchain world, but this is a fascinating example of "move fast and break things" at work; the VCs who thrive on "disruption" are now getting the Venture Capital industry "disrupted", their chickens have come home to roost ;)

Back to the point though, a cooperatively-run VC fund (mutual fund? savings pool?), for helping new platform cooperatives get up and running, could be a game-changer! Finally, free code could be financially "self-hosting"! How many established coops might be willng to invest in such a fund?

Yes @doubleloop there's basic thinking to be done here, andI don't myself find it easy to untangle the threads. Kleiner is definitely a good place to start.

One thing that's basic is the relationship between livelihood and stewardship in the collective. Coops are traditionally about livelihood - taking or making resources of some kind, holding them in common, and mobilising them in the market, to gain livelihood (which is then distributed according to collective decision). A traditional ('natural') regulated commons is fundamentally about stewarding some resources, and mobilising them in ways that continue to maintain their integrity and value (where 'value' is a deep, non-financial notion). 'Livelihood' isn't in the foreground (or is seen in traditional culture and spirituality as being 'the same' as the stewardship: identity with the Land, songlines, etc).

Commoning and cooperating have different roots. But there are now some complex hybrids, and that's what the future holds: commons that are curated as well as found-in-nature, and livelihoods that are - let's say, 'generative' in Marjorie Kelly's term - coupled with relationships of development and nurturing of the core resources that are conducted in a spirit of stewardship.This is way beyond 'social enterprise'?

This is a wonderful but difficult mix, and traditional thinking on coops doesn't necessarily cover these bases. We're stretching into new ground now, and although the multi-stakeholder coop form is basic, again it don't furnish a straightforward form for a commons?

Here's a few more thoughts:

How can rival goods (people’s time and energy) and non-rival ones (code itself) coexist as parts of the same commons? Are they two sides of the same coin, or are they radically different? Answering this question requires the correct understading of the mutual relationship between the people who work in FOSS projects and the artifacts they produce (the code itself).

I believe we should begin with understanding whether and how code-as-a-commons can be exploited and abused, so we can identify ways to protect it from damage (ie. one of the core aspects of commoning as a practice). @wulee argued that “Software can be abused in various senses: misused, subverted, hacked etc.” which is a perfectly valid statement, albeit partial. Does hacking or misusing a compiled version (ie. a snapshot of the code as it used to be at the moment of the release) affect in any way the existence, the nature or the structure of the “pure”, uncompiled code that’s stored on some remote server? Does such misuse actually deplete or otherwise damage the commons, or is it but an unethical handling of a byproduct of such commons? In other words: is this kind of misuse akin to overgrazing a pasture with too many sheep (ie. an action that’s detrimental to the commons as a whole), or is it instead like selling the wool of the sheep instead of their milk, as agreed between all the users (an unethical action that leaves the actual commons untouched, nonetheless)?
If FOSS code is to be a commons (and I believe it is), there need be a clear definition of what constitutes an acceptable behaviour by commoners, and what does not.

Another important thing to consider is that code itself (the actual strings, not the binary compiled versions of it) is at the same time both an artifact produced by the people working on it, and a snapshot of their collective knowledge and skills. As a matter of fact, said code can be compiled and run as a program or left uncompiled and used as learning material (something the GPL licence makes very clear). The philosophical potential hidden in this peculiar nature of code as a non-rival good and as a form of crystallized knwoledge appears very promising in determining the nature of the relationship between the code and the people working on it.

I don't have an answer to your first question (other than a general inclination that an understanding of them as part of the same commons would be simpler and therefore perhaps worth pursuing).

I do have a response to your question about the abuse of software, however! If the code of a particular project is somehow misused or hacked, does the damage to the reputation of the project count as damage to the commons? The 'pure' code might remain untarnished, but the project might receive less support from developers and might see less uptake from users.

I suppose an analogy would be a group of people engaging in unsavoury activity in a public park. Although the physical space itself isn't damaged in any way, its reputation might be.

It seems to me that the 'perceived goodness' of the code should be associated with the code itself, but that the detriment of that perception might be better understood in terms of its effect on the people developing and using it. Perhaps this ties into your last point about the snapshot of knowledge and skills? Although the knowledge and skills represented in the 'pure' code are unaffected, they might be seen and appreciated by fewer people as the result of a sullied reputation.

Great feedback! I didn't consider loss of good reputation as a potential risk of hacking, thank you for bringing this up! I'll have to don my thinking cap again and see how this fits into the larger picture :)