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.

@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 :)

Sorry to reply so late, I had a draft reply i didn't finish, and am catching up with Loomio. To respond to @michelekipiel question and to add to @idmyn's reply (and think out loud):

How can rival goods (people’s time and energy) and non-rival ones (code itself) coexist as parts of the same commons?

Well... why not? You might consider a natural ecosystem to be a common good for the inhabitants - who are also co-creators of it. Equivalents of "rival goods" might be food and energy, space, materials) and "non-rival goods" might be temperature/compositional homeostasis, genetic diversity, and the cycles of matter and energy through the ecosystem (all of which which allow it to sustain
itself).

So you might consider code analogous to an organism's genotype. Say it is currently well adapted for the environment. In principle this genotype is just information and won't change or degrade. But if the environment evolves to become hostile, perhaps a new disease variant evolves, that goodness can be undermined, unless the organism's (or strictly, its descendents') genotype evolves to compensate.

Code is the same. When it stops being able to evolve - people stop maintaining it - it stops being able to adapt, and as it is left behind it becomes unfit for purpose.

So the point about reputation is true, but it goes further than this: the code can become literally unusable. Absence of maintainers is really a big clue that previously "flawless" code has become moribund, and undiscovered flaws or obsolete formats mean you could find your systems breaking down, or worse, being attacked.

Are they two sides of the same coin, or are they radically different?

Yes, they are mutually co-dependent. The code requires people's time and energy to come into existence and evolve its function. People spend time and energy on the code because they get value from it.

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?

Categorically yes, it can. As an extreme example: the "Word Perfect" software might have been an excellent word processor once, but now you fill find it hard to install and run. Even then it might malfunction when presented with modern printer devices, or be vulnerable to some general exploit. Being able to recompile it is not a fix for this, without maintainers who can adapt it to modern systems. It's a constant process.

Emphasizing these points from @wulee:

"How can rival goods (people’s time and energy) and non-rival ones (code itself) coexist as parts of the same commons?

Well... why not? You might consider a natural ecosystem to be a common good for the inhabitants - who are also co-creators of it. Equivalents of "rival goods" might be food and energy, space, materials) and "non-rival goods" might be temperature/compositional homeostasis, genetic diversity, and the cycles of matter and energy through the ecosystem (all of which which allow it to sustain
itself)."

And this one, re code-as-genotype and downside's of hackability: "Yes, they are mutually co-dependent. The code requires people's time and energy to come into existence and evolve its function. People spend time and energy on the code because they get value from it."

What I read here are the two essential communicative functions of living systems. Modern/contemporary society emphasizes the short-term control aspect of information, neglecting the longer-term control function of culture. It's the interactions that make a system, and the quality of those interactions that determine the health of culture--which is measured in human interrelationships.

Apologies for being such an infrequent and inconsistent participant here. I am interested just got a heavy juggling thing going on ;) There's something about free-riding that seems relevant...maybe it's applicable to me (?) and/or maybe it's worth more conversation. Why do we consider persons who are active in other networks to be irrelevant to our own? There's more resiliency and robustness the more deeply intertwined we are....

Terrific thread this! Sorry to arrive so late with such a conceptual contribution to offer - and in the midst of the #ForkOff tumult, which is a very important moment. Nevertheless: a comment on traditional constructs in economics and philosophy that need to be carefully reframed, appearing in this originating comment by @michelekipiel . .

a non-rival good . . . it would be more useful to refer to code (or any other artefact) as non-rival material. That makes things very clear, we're in a practical world of objects, this is a particular kind of object which is available for multiple simultaneous uses. The idealist notion of 'a good' is pretty murky, and wrapped up with all sorts of C18 liberal jaw-flapping. Let's cut that crap, and be materialist? If code were not material, nobody would be able to fork/modulate it or dump it in a repository!

crystallized knwoledge . . . again, here's an idealist construct - 'knowledge' - which is so commonly and casually mobilised - a careless meme - that we may even be inclined to believe there's some kind of 'thing' (the notion in sciences of a 'body' of knowledge, etc). But what actually happens is knowing by concrete historical collectives of persons, in material working relationships with each other and with pivotal material things and media of many kinds (lab equipment, documents, objects in nature, pieces of kit, things in the everyday environment, communication channels, etc etc; their own bodies too - interoception, equally material). What actually exists is the concretely configured collective labour power of the knowing person or community/ies, which enables the folks to 'know' some aspect of the world into shape (verb; transitive) and then mobilise some kind of action in relation to that object-as-prepared-for-action-by-knowing. We can call this 'competence', which is produced, as a material capability of a community or person, by a practice of knowing (verb; transitive).

So knowing - as a collective or individual practice - and the skilful (and formally or informally regulated) mobilising of the resulting capability, are the real-world stuff that exists: these are practices, bodies doing stuff in the material world. 'Knowledge' isn't helpful in handling this - but it's an awful hard meme to ditch!

If we're commoning, we're commoning the knowing-and-mobilising - the practice, the material doing. Also, the artefacts that are part of the practice (documents play a big part). There is no quote-unquote knowledge, so we don't need to worry about commoning 'it'. There isn't any 'crystallised knowledge' - just the current state of capability (multiple capabilities) that can be mobilised in the collective of people-and-artefacts (multiple, overlapping collectives: the core artefacts are non-rivalrous objects, and people can wear more than one hat: hacker, voter, householder, etc).

This kind of distinction between artefacts and practices is part of the way into tangled questions like: How can rival goods (people’s time and energy) and non-rival ones (code itself) coexist as parts of the same commons? Can it be that hard, to address the commoning of artefacts and the commoning of mobilisable/mobilised labour-power (practices) in two parts of the same mind ;-) And conduct them as mutually-enabling threads of the same practice?

Legal-wise - contracts, licences, trade, ownership, etc - this could be a whole other story :-( But a whole other framework of property law, etc, may be called for? Law is not the most materialist domain of thinking! Smoke & mirrors, your honour!

Sorry to be so verbal, but developing a practice of cooperating and commoning won't be helped by idealist thinking. Theories of practice are materialist: people, doing stuff, with people and things, in material bodies, in actual locations. Nothing ever happened anywhere, without material bodies being mobilised and modulated! But the language pivots on its verbs, not its abstract nouns.

Interesting report from the Sustain conference on some ways of sustaining FOSS projects. Explicitly mentions Ostrom's institutional design for figuring out governance rules. Has a section on 'Creating sustainable incomes' but fails to mention cooperatives. https://sustainoss.org/assets/pdf/SustainOSS-west-2017-report.pdf

Thanks for sharing, I'll read through it ASAP

Is it worth trying to outline what we'd aim to achieve in such a 'white paper'? I feel that if we broke it down into questions like 'what is a FOSS cooperative' and 'why are FOSS cooperatives a good idea' then we might be able to have more focused discussion. Thoughts?

Seems like a good idea. Perhaps start a page on the wiki to capture the thoughts that have been shared here?

@dav

Is it worth trying to outline what we'd aim to achieve in such a 'white paper'?

The two most obvious questions to me are;
1) what does the cooperative model have to offer free code projects
2) what does the free code model have to offer cooperatives?

These can be broken down into subsidiary questions like;
1b) what organization and financing models have free code projects used up until now?
1c) What's worked and what hasn't?
2b) what software procurement/ development models have cooperatives used up until now?
2c) What's worked and what hasn't?

One possible answer to question 1) can be found in the Sustain report shared by @doubleloop

"Our​ ​ collective​ ​ challenge​ ​ is​ ​ to​ ​ support​ ​ those​ ​ working​ ​ on​ ​ essential​ ​ digital​ ​ infrastructure​ ​ as​ ​ a ​ ​ public good.​ ​ Commercial​ ​ organizations​ ​ are​ ​ beginning​ ​ to​ ​ see​ ​ the​ ​ value​ ​ in​ ​ giving​ ​ back​ ​ to​ ​ the​ ​ community, but​ ​ no​ ​ individual​ ​ company​ ​ or​ ​ organization​ ​ is​ ​ incentivized​ ​ to​ ​ address​ ​ the​ ​ public​ ​ good​ ​ problem alone.​ ​ In​ ​ order​ ​ to​ ​ support​ ​ our​ ​ digital​ ​ infrastructure,​ ​ we​ ​ must​ ​ find​ ​ ways​ ​ to​ ​ work​ ​ together"

Getting more coops operating in free code allow creating paid work for people who as well as doing their day job work for the coop, will also be empowered to be evangelists for the common good of the whole free code ecosystem. Unlike traditional companies, which are structured to put their own bottom line first (even at their own long term expense), cooperatives are structured to care about community wellbeing as well as their own financial needs. Unlike Foundations/ Trusts/ Trade Associations which have typically provided the trans-company coordination layer in open source projects, cooperatives have their own revenue source (through selling goods and service), so they don't need to be financially dependent on the companies in their orbit.

Mozilla has the worst elements of both structures, a for-profit company wholly owned by a not-for-profit Foundation, but financially dependent on Google for years, leading to many other perplexing anti-community decisions. Ubuntu/ Canonical is an example of the same unhealthy co-dependence between a not-for-profit umbrella body and a corporation that owns it's name and logo. The W3C being forced by the corporate browser makers to shoe-horn DRM into the HTML standard is another example of the inability of the 'Foundation' model to get corporate members to wait until after dinner to eat their pudding.

The answer to question 2) seems so self-evident to me I'm not sure how to articulate it. Anyone else want to have a go?

the inability of the 'Foundation' model to get corporate members to wait until after dinner to eat their pudding

I believe this captures the essence of the problem. A foundation is, by definition, an organization that needs capital to flow in by means of donations et similia, whereas the cooperative model is capable of generating and capturing capital autonomously, via the work of the members, if it's a workers' coop, or via "investor" and "customer" member tiers, if it''s a multi-stakeholder coop.

In our case, given the nature of FOSS, multi-stakeholder cooperatives seem like the better option, as they allow for a multi-faceted approach to both decisionmaking and capital flow. For instance, social.coop could very well evolve in a multi-stakeholder coop, with a customer tier (members who want to participate but don't have skills/time to invest), a worker tier (members who can actively perform development and/or sysops taksk) and and an investor tier (members who want to contribute capital to the coop).

Pretty much every FOSS project I can think of could easily adopt this model, from small scale projects all the way up to colossal entities like GNOME of KDE.

I am fine with this, I just think focusing on the Foundations puts the cart before the horse; they're not where the problem is, just one place (among many) where symptoms show up. If you replaced the existing Foundations and standard bodies with cooperatives, but most of the institutional members were corporations, you'd get most (if not all) of the same problems. On the other hand, if more of the members/ partners/ funders of the existing Foundations and standard bodies were cooperatives, and less were corporations (ideally none), they would work fine (as they used to before corporations got so heavily involved).

There's a post in the Commons Transition loomio about the Commons Management Agreement, a particular type of contributor license agreement that can be used for free software projects, an example is cryptpad. https://www.loomio.org/d/7pkblwdQ/commons-management-agreement

Not sure how I feel about it, but worth sharing. It appears to be one approach to free software conservancy - simplifying dual licensing for commercial ends while aiming to guarantee the freedom of the project in perpetuity.

I've been following that thread as well, it looks primising. I was even considering posting some of the questions we're facing here in the CT group...

Finally able to read through thread so far. Great stuff. I'm short on knowledge of FOSS but maybe can add something on the Cooperative side. I've been trying to figure out what kind of animal Social.coop is so that I might raise some questions around what the exact mission of the cooperative is, the primary value the cooperative provides to its members, and in turn, how it is to be healthy and financially sustainable in order to fulfill its mission?

At first I thought it was primarily a consumer cooperative but that didn't seem quite right as it really wasn't about pooling buying power. A producer cooperative? Not so much, as the intent is not market an independently produced product to sell under one brand. What Michele posted about "Social Cooperatives" feels like the best fit so far. One which seems to have (2) primary stakeholders A: the users of the platform/service and B: the administrators of the platform. As the platform was built on Open Source software the developers are then a separate group and would be considered a sort of Vendor rather than a stakeholder?

I guess this is where the larger FOSS Cooperative conversation comes in. Mastodon could be structured as an umbrella Social Cooperative with developers as the primary stakeholder and Instances (like social.coop) as the secondary members? And the Free aspect? That is for anyone who wants to tinker and use the software but not plug into the Mastodon network?

I guess I have never fully understood the rationale of the F in FOSS as there is always someone or something subsidizing in ideas, time, labor, and/or capital and that seems like it has to be valued and supported in some way beyond transient and inconsistent donations.

Great stuff! I'm so glad this thread is slowly picking up steam, as the amount of frustrated people complaining on Mastodon about this or that FOSS project treating them like shit is steadily increasing and this only makes the case for FOSS cooperative adoption stronger. I believe we should schedule a call to address some of the most relevant questions raised in this thread. If this makes sense to you, just let me know and I'll do the rest.

Because of the heady nature of the conversation and the depth of material it might be helpful if you compiled a few statements that you threw out as a quick poll to see what level of FLOSS consensus of understanding is out there. It might be a way for the larger social.coop community to engage more as the material can be very academic and not as accessible for people who lack the time or desire to wade through. I could add some from a cooperative perspective if needed.

Good point. It will help me wrap my head around some of the more "hazy" topics.

> I guess I have never fully understood the rationale of the F in FOSS
The ambiguity of the F word in FOSS is sadly a long-running source of confusion. The one-liner to disambiguate it is: "Free software is a matter of liberty, not price. To understand the concept, you should think of free as in free speech, not as in free beer." (Richard Stallman). I think libre software is a better phrase but it never seems to have taken off (in the English language at least.) There's generally no issue from the free software movement with people making money from libre software, as long as the four freedoms are preserved.

> I could add some from a cooperative perspective if needed.
Yes that would be great.

> I've been trying to figure out what kind of animal Social.coop is
I think that's an open question, there's some good discussions on loomio - here's one recent one: https://www.loomio.org/d/Zx2RDNAl/the-common-bond-scaling-strategy-of-social-coop-

Great that helps a lot. That makes a lot more sense. So the four freedoms are really built around maintaining the workability of the source code for others and not restricting what some one can do with it commercially and doesn't mean that what is value added like other tools or services (unless it's modification of the source code) has to made available to others with or without charge.

Again, drwaing out framework-type language/guidance (from @robertbenjamin): "what kind of animal Social.coop is so that I might raise some questions around what the exact mission of the cooperative is, the primary value the cooperative provides to its members, and in turn, how it is to be healthy and financially sustainable in order to fulfill its mission?"

And the bit about four freedoms.....

Meanwhile my brain is percolating along the lines of comparison/contrast with other kinds of cooperatives--that is, those working on the ground, face-to-face. Cross-pollination, adaptation, etc...

It's a slightly different beast, but the Software Freedom Conservancy is an interesting organisation to look at for contrast. They provide some of the wider governance needs for FLOSS projects, taking the load from developers. They do it as a kind of umbrella non-profit. Income still seems to be through donations. So perhaps a similar goal, but a different approach. https://sfconservancy.org/projects/services/

Sounds like a cool organization. In general what I think cooperative models could offer over Non Profit ones is that they come baked with representative (if not democratic) governance, an ideal and process for valuing contributions of any form through patronage, and a recognition that in order to become sustainable they must continually provide a clear value to their member stakeholders and must become market competitive. I see the market competitive aspect as a really important attribute if we are to envision a future where more sustainable and democratic entities are built and adopted at scale eventually supplanting the current extractive capital owned platforms.

what I think cooperative models could offer over Non Profit ones

Totally agree about the benefits cooperatives could bring to the larger free code ecosystem, but as a replacement for the corporations and VC-funded startups, not as a replacement for the not-for-profit coordination layer. They already work in a fairly cooperative fashion, but that gets distorted by the current dominance of corporate members, as with EME getting pushed through the W3C.

I recently discovered that there exists an international equivalent to the Italian "cooperativa sociale" (social cooperative), namely the multi-stakeholder cooperative. As I already commented earlier, this model seems to be the most relevant for this discussion, as it allows for the flexibility needed to accomodate both developers and users in the same organization. Here are a few resources I found searching the web:

http://cultivate.coop/wiki/Multi-stakeholder_cooperatives
http://wiki.p2pfoundation.net/Multi-Stakeholder_Cooperatives
(+ see the attached PDF)

A further aspect that makes the multi-stakeholder cooperative even more interesting is that it allows for "investor members" (with capped return rates), something that could truly help FOSS projects achieve sustainability in the mid-to-long term without straining the user base.

Leaving aside the interesting, but ultimately academic, debate around code-as-a-commons, we might want to focus on this concept to further understand how it could be applied to FOSS projects and to social.coop as well. What do you think?

I developed a full set of multi stakeholder cooperative org docs (working with a great cooperative Attorney) using Limited Cooperative Association (LCA) Statutes. It allows for classic financial Investor members and I think more importantly for this FOSS conversation has a Builder/Founder investor member class that captures a lot of the sweat equity value that goes into developing something like this. Working on boiler plate versions so I can share the Model more broadly.

I'd love to read those docs, please share them if you can! :)

Just picked upon this thread. Very interesting. My experience of working with FOSS projects is limited and as I'm not a developer I'm maybe looking at the whole thing from a slightly different angle, but...
I've long thought that FOSS software projects and the communities that develop around them are in many ways well suited to the cooperative model. So it seems pretty weird that real-world exmaples are somewhat thin on the ground, to the extent that I've never heard of one (although there are now emerging examples of platform cooperatives that could be defined in this way).
I recall some years back, when Drupal 5 was still riding high, a brief exchange with an active member of that community. I think at that point they were in the early stages of developing what has since become the Drupal Association, and there was active discussion about whatthe right organisational approach should be to fit well with the Drupal community. I suggested that a cooperative could potentially be a great fit, as it sat well with many of the values that I saw in that community. I think the idea was given some consideration, and was then thrown out, with the response that it wouldn't fit as the Drupal community was a do-ocracry, and therefore not democratic. The idea of having what the developers might see as relatively 'passive' users of the software that they built having the same level of decision-making influence and power as they had was anathema to their world view. that was maybe 15 years ago.
I've had similar conversations within the the much smaller CiviCRM community, where the idea was given a fair degree of consideration. I'm less close to the centre of things there now than i was then, perhaps 5 or 6 years ago, and as far as I'm aware nothing has changed there, and the core group continues to bump along, seemingly struggling for the resources they need each year to keep the show on the road (and on the whole they are doing a good job).
My analysis, having watched these communities change and mature over the years is this: during the early stages of a software project, the focus is very much on the developers and the importance of building and maintaining a strong core development team to ensure that the product has some quality and can do what it sets out to do. We can eqaute this to the start-up phase in a business, and at this stage in the life cycle I think that do-ocracy is a pretty good model.
However, as the product matures the development focus shifts necessarily towards a more evolutionary approach, with more time and energy going into security, stability, bug fixes and understanding the needs of the target market as it evolves, and consequently the community around the developers takes on more important role in terms of influencing the design of the software, providing the financial resources to sustain the project, and just in terms of sheer numbers, is likely to outnumber the developer community by a significant margin. It is in this more mature stage of the life cycle that i think a cooperative model makes a lot of sense. But the project is still under the control of the developers and they likely don't want to cede that control.

It's a fascinating area. I flagged up the following opportunity the other day in the CoTech community, and I'll do the same here, as it seems highly relevant:
https://ford-foundation-6.forms.fm/digital-infrastructure-research-rfp

I think the idea was given some consideration, and was then thrown out, with the response that it wouldn't fit as the Drupal community was a do-ocracry, and therefore not democratic

I had the same experience a while back when i joined the ubports forum right after Canonical dropped Unity 8 (for which I'm still mad at them, btw). The community was planning to pick up the development of the mobile part of the DE, which was the one I was most interested in, so I proposed to form a cooperative (I didn't know about multi-stakeholder cooperatives at the time, but the idea was basically the same). The replies I got went from "fuck no" to "what the heck is a cooperative" to "we might consider that but we prefer the foundation model". They eventually went for the latter, as far as I can see (I no longer participate in that forum).

The problem I see here is that do-ocracy is basically techbro code for "we lead because we can code", which oftentimes results in pissing contests between devs (I left ubports after one such contest) that alienate good chunks of the community and sour the relationships between those working on the project. Introducing democratic decisionmaking could dramatically reduce the chances for such bitter altercations to happen, while paving the way for that "second phase" you mention, where customers and/or users should be allowed to get into the decisionmaking process too.

At the risk of going totally off-topic (I'll try to bring it back at the end) ...
@michelekipiel

right after Canonical dropped Unity 8 (for which I'm still mad at them, btw)

This is what you're mad at them for? But they've made so many bad decisions! Like letting Amazon spy on their users, and refusing to free the server code of Ubuntu One (resulting in its death), or building Unity on their own replacement for X Windows (Mir) instead of contributing to Wayland. Making Unity their default desktop in the first place, instead of working with the GNOME community to improve GNOME, was also a bad decision, especially since this is where they've ended up anyway. IMHO Abandoning Unity and Mir is one of the best decisions they've made for years. But the question remains, why do non-coder users and software commons advocates like ourselves so often find ourselves frustrated by being left out of these decisions?

The problem I see here is that do-ocracy is basically techbro code for "we lead because we can code"

Without wanting to make excuses for the sometimes protohuman behaviour of some male developers, you can't design software by committee, for two reasons. The first one is the same reason you can't design a plane or a bridge by committee; programming is a form of engineering, and doing it well requires specialist knowledge and skills that most people don't have, and may never have, regardless of how many code camps we run. The second reason is explained by Fred Brookes in his book 'The Mythical Man Month'. TL;DR beyond a certain threshold, involving more people in a software project makes it proceed slower, not faster, because of all the social overhead added each time you add a new person into the process.

This is why open source communities make such heavy use of forking, both within projects (forking, changing, and submitting patches), and in forking new projects off existing ones (eg LibreOffice forking off OpenOffice, NextCloud forking off ownCloud). Rather than get their code into use by means of winning arguments with other developers ("politics"), they try to prove their argument in the form of a fork, which can be used by those who agree with them, while those who disagree can continue using the original code. Sometimes a consensus emerges on which approach is better and the fork is merged. Other times each variant has legitimate uses, and the fork continues as a new project in its own right.

The "pissing contest" you mention is an example of what happens when developers choose politics over forking, and its seldom pretty. If we approach the potential intersection of cooperative democracy and open source as a way to get free code developers to conform to the will of democratic majorities, we will fail. They will vote with their feet and go elsewhere, as they have when corporate acquiHirers like Oracle tried to tell them how to work.

Where cooperatives have value to add to peer production communities is in the areas of community management (dealing with UX, designers, and user participation), and perhaps most importantly, financial management. Where open source is a way of organizing tech workers in their own interests (sometimes using worker-owned cooperatives like Loomio), platform cooperatives can be a way of organizing tech users in our own interests. By pooling our financial resources to support the open source communities who create and maintain the software we use, and using democratic decision-making to decide what software to use together at any given time, we can send strong signals about what we do and don't want from software, without trying to micro-manage the peer production processes themselves. If benevolent dictatorship produces good software, and people willingly choose to work under that dictator, what business is it of ours to tell them not to?

I agree generally with your focus on the cooperative platform not having to own the entire process and that it can utilize "demand signals" to get the product/software it needs. Though I would say that cooperative ownership does not have to mean collective management or collective development. You can also segment interests (developers, worker administrators, users) into different member classes and weight the overall representation to balance out the different interest. This way you can have the entire pipeline be owned by the cooperative and have the organization communicate internally to get the desired results. The same way it works in most large consumer products companies - management sends demand signals to sales who sends demand signals to development and marketing.

Hi @strypey thanks for participating in the thread. I mostly agree with your points (especially those regarding Canonical :) ) but allow me to clarify a bit:

you can't design a plane or a bridge by committee; programming is a form of engineering, and doing it well requires specialist knowledge and skills that most people don't have,

I never meant to say this (in fact, I made it clear at the end of my post that widespread participation should be "phase two" in a FOSS project). What I meant to say is I am under the impression that several developers are actively against democratic decisionmaking becuase of a poorly disguised rockstar complex. An impression that's only reinforced by your "pro-fork" argument, which basically translates to "if I can't have it my way, I will just go and waste hundreds of man-hours to reinvent the wheel so I and only I can be quoted as the author of the code". A pretty childish attitude, if you ask me. This kind of behaviour should be actually frowned upon and considered a waste of time and energy (unless of course special cases, like in the OpenOffice case etc...).

If we approach the potential intersection of cooperative democracy and open source as a way to get free code developers to conform to the will of democratic majorities, we will fail

We need to define what a democratic majority is, at this point. For intance, in an ideal multi-stakeholder cooperative where developers and users exist as two separate membership classes, the influence the latter could have on the former, when it comes to software design and development would only be limited to an "informative" role (ie. "we need this thing to work like this"). Beyond this stage, users would have no voice in the matter of how code is written. Developers would then have to agree among themselves what is the best way to achieve the goal defined by the users. Honestly, I can't see a way this would lead to failure. Quite the contrary: when a project is based on actual needs from the start and a strong community spirit is kept alive by democratic, transparent and honest decisionmaking, I believe success is the most likely outcome.

If benevolent dictatorship produces good software, and people willingly choose to work under that dictator, what business is it of ours to tell them not to?

Benevolent dictators are only benevolent as long as they please, not one second longer. Just think of the disaster that was the witches.town shutdown...