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

@robertbenjamin my point exactly. There is a reason the multi-stakeholder cooperative is called that way :)

@michelekipiel

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.

That's what I thought you meant. I fundamentally disagree, as I tried to explain with my discussion of forking practice. My point is that that good programmers are exactly like rock stars, and this is a good thing. They know how to play their instruments, and what sound they're going for, and they're engaged in a fundamentally creative and technical practice that cannot be improved by committee style decision-making.

The music of Pearl Jam (or insert any band whose musicianship you deeply respect) would not be improved by allow their fans to democratically manage Eddie Vedder's singing, or Matt McReady's guitar solos. However, if the fans could organize themselves to create a platform cooperative for booking concert tickets, they could help both themselves and Pearl Jam break free of the Ticketmaster monopoly that screws all of them. The same is true of the record companies that manage the finances that allow Pearl Jam to record and release an album, Amanda Palmer (formerly of the Dresden Dolls) showed that crowdfunding could be used to facilitate this financing without a corporation taking the lion's share of the rights and revenue, but this too could be organized as an ongoing platform cooperative.

[forking] should be actually frowned upon and considered a waste of time and energy

It used to be, because the source code versioning tools that existed at the time made it very difficult to merge forked code back into the upstream project. Git totally transformed this. Not only is it the best way to avoid zero-sum ego battles over whose code is better, but forking is now the standard way of contributing to a free code project, which is why that banner saying "fork me on GH" is all on the homepages of so many projects.

If I want to suggest a code change to Mastodon, the first thing I do is fork the Mastodon code repo on GH, then make my changes, then do a "pull request" to invite Gargron to merge my suggested changes back into the core repo. If Gargron doesn't want to do that, I can throw my toys, or I can just use my variant of the code on my instance, as can anyone else who likes it better than Gargron's version. Unless both versions scratch distinct and mutually exclusive itches, one or the other will attract the majority of users, and eventually either Gargron will relent and marge, or I will accept the will of the crowd and abandon the extra effort of maintaining my fork. Nobody is coerced, and there is no need for a pissing contest. It's "rough consensus and running code".

To return to the musical analogy, if Stone Gossard writes some songs that the rest of Pearl Jam don't want to play as PJ songs, he can fork Pearl Jam, by creating a side band (Brad) to play these songs. If Curt Cobain hadn't died, Dave Groehl would probably still have formed Foo Fighters, because Curt didn't think Dave's songs were suitable for the Nirvana aesthetic, but Dave could have continued drumming for Nirvana too. Like forking in free code development, none of these things are mutually exclusive.

Benevolent dictators are only benevolent as long as they please, not one second longer.

Sure. Your point? As soon as they stop being benevolent, people can take a copy of the code and vote with their feet. Again, the examples of LibreOffice and NextCloud show that this is effective. Linus Torvalds' protohuman interpersonal skills (calling people "morons" on official mailing lists etc) are tolerated only because he is the most technically competent person in Linux kernel development. The day ... no, the hour that stops being the case, the rest of the developers can start working on one or more forks, and GNU-Linux distros can choose a fork to start using instead of Linux. Linus would continue to be the king of Linux, but he would rule a kingdom of one.

Here's a hypothetical example from the music world (I don't know the real story here, I'm totally guessing). Let's say Zack de la Rocha blocked consensus on playing a bunch of songs the other three members liked as Rage Against the Machine songs. So the rest of the members got Chris Cornell to sing them, and released them as Audioslave.

Zack got to protect his vision of the RatM aesthetic, but at the cost of getting sidelined for the next decade or so. However, when RatM reformed, their fans remembered them for albums like Evil Empire and Battle for Los Angeles, not the radio-friendly unit shifters Audioslave put out. In this instance, Zack's benevolent dictatorship didn't stop the rest of the band from making the music they wanted to make, but it did prevent the musical impact of RatM being watered down as a consequence.

Just think of the disaster that was the witches.town shutdown...

What about it? All their former users can just move to another instance, or set up their own. Yes, they have to re-establish all their follower/ followee relationships on their new account, but that's not a problem caused by the governance style of witches.town, it's a missing feature in fediverse software in general. It's a problem that Gargron and co are all working on, and when it's solved, users who don't like the governance decisions on their host instance get easily vote with their feet. Instances whose admins drift towards despotism will quickly find themselves nations of one.

As it happens, it's a problem Mike from Hubzilla already solved with Zot, it's just a shame the W3C Social WG refused to use this work in ActivityPub. But again, Zot exists, and AP exists, and developers can decide which standard to implement in their software, and users can decide (by their choice of software) which standard will have the most users. What cooperatives can do is help large groups of users make those decisions together, in an informed way. Thus funneling attention and funding to the projects that provide the best solutions to technical problems, rather than just to the ones with the best marketing departments (which is how we ended up with the FarceBooks and birdsites in the first place).

I don't agree 100% with the music analogy, as music is art, to which the maxim "Ars gratia artis" applies, whereas code (or at least code serving a true purpose) is not. This said, let's see where this goes.

The music of Pearl Jam (or insert any band whose musicianship you deeply respect) would not be improved by allow their fans to democratically manage Eddie Vedder's singing, or Matt McReady's guitar solos.

I might have expressed myself poorly, but this is precisely what I said in my previous reply, when I wrote "Developers would then have to agree among themselves what is the best way to achieve the goal defined by the users". Nobody except the core members of Pearl Jam (ie. the core developers, in my example) can say anything about the way PJ are supposed to sound. The only difference here is, as I pointed out in the first paragraph, that music is art and PJ were free to do whatever they wanted, while a codebase serving actual user needs has to follow... well, user needs. I hope this makes it clear.

only because he is the most technically competent person in Linux kernel development. The day ... no, the hour that stops being the case, the rest of the developers can start working on one or more forks

A fantastic way to waste millions of man-hours on narrow pet-projects, led by pet-benevolent dictators. Hardly a positive outcome, in my opinion, but let's agree to disagree.

All their former users can just move to another instance, or set up their own. Yes, they have to re-establish all their follower/ followee relationships on their new account, but that's not a problem caused by the governance style of witches.town, it's a missing feature in fediverse software in general.

You seem to dismiss the incredible amount of effort it takes to remember all of one's followers/following handles by heart, not to mention the emotional labor needed to recover those after seeing 1 year's worth of social interactions being wiped out overnight. Also, the missing feature argument is invalid, because even if exporting a graph was a one-click feature (which is not), users can hardly export anything, once the platform that holds their social graphs is shut down without any notice.

One more thing, that might put some of my previous comments in a more helpful context ...

@robertbenjamin

This way you can have the entire pipeline be owned by the cooperative

Can you? Isn't that what Microsoft tried to do (Windows, Internet Exploiter, Office365, Azure Cloud etc)? Isn't it more democratic to leave each team in the pipeline to be autonomous (self-owning and self-governing)? Isn't the ability to choose which teams to include in their own pipeline one of the things that make GNU-Linux distributions more democratic?

In theory, each team is its own worker-owned collective, and whether they structure themselves as an informal affinity group, a non-profit association, a cooperative company etc will depend on their size, age, shared goals etc. To me that seems totally compatible with constituting user interface organisations like distributions and hosted platforms as user-owned cooperatives.

(BTW just started reading 'Ours to Hack and Own'. Maybe I might meet some of you F2F in London in July?)

Nor sure they are mutually exclusive. Kind of like Nike has their own marketing and development teams but also uses outside agencies when it's a better fit.

From let's say a platform like social.coop's perspective I'm more saying that we could have our in-house development team(s) which are either run democratically or managed in a more classically hierarchal way but that have democratic/representation at the overall cooperative.

It's really about what way would most effectively and efficiently maintain continuously improving coverage.

But like you said we can also effectively steer development in the marketplace by creating a large enough pool of resources and using outside "agencies" that align with our needs and standards.

Nor sure they are mutually exclusive

Sure. User-owned coops will certainly want to employ some teams of in-house developers, especially if we define "developer" loosely to include not just back-end engineers, systems architects, and protocol designers, but also the people working on interface design, UX, graphics, and so on,. My only point is that this will never be owning "the entire pipeline". Even FB and the birdsite don't try to do that, everything is just too interdependent for that now (that's why they try to "own" users instead). To return to my musical analogy, although you might want to have a house band, it's not necessary (not really even possible) to own all bands you'd want to play at a music venue cooperative owned by the music fans who go there.

either run democratically or managed in a more classically hierarchal way

I'm confused by this. I'm not aware of any significant free code projects that are run in a "classically hierarchal way". Can you give me some examples?

If you mean the "benevolent developer", this is a quality control role, not a comand-and-control one. The title is a hacker in-joke like St IGNUcious, riffing on the fact that this person - often a volunteer - has to take more responsibility for the quality of the software that anyone else involved. While still having absolutely no top-down control over how developers spend their time working on it, or whether the canonical version they control commit access to will be the one people choose to keep using (rather than a fork or distribution that does things differently).

Only Bowie could release Bowie albums, but he couldn't control the writing process of the people writing songs for him (only decide whether their songs would become Bowie songs or not), or control whether people listened to his versions, or psy-trance remixes, or pan flute covers. Bowie was the "benevolent dictator" of albums by Bowie, and clearly a lot of people like how he did the job.

If you mean teams working on self-contained programs inside a single corporation, especially those whose managers go all-in on the Agile(TM) Scrum cargo-cult, then yes, some of these are quite hierarchical. Given the chance, such teams might be keen to take the free code they're working on, vote with their feet, and decamp to a cooperative owned and run by their end users. But this is the classical hierarchy of corporations, not open source, and is a rare exception to how most free code development works, even when corporations pay programmers to work on it.

Thinking more along the line of project managers, timelines, and a more formalized quality control and Remuneration system I suppose but I'm not from the FOSS development world. I'm thinking of it more from point of view of say a platform who wanted some kind of specific tool developed.

I'm not from the FOSS development world

I'm kind of the opposite. I'm familiar with the general theory of coops, and (tried and failed) to start an IT coop once, but I've had a lot more to do with the free code world than the cooperative business world. There will be a lot of myth-busting to be done on both sides as we bring the two together more ;)

There will be a lot of myth-busting to be done on both sides as we bring the two together more

This is very much the point of this thread, and I'm glad to see it is drawing a lot of attention!

Wow, an evolutionary design is super sexy! :)

Crucial is decision-making. Ya'all been working this hard from what I can tell.

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

Seems related to the so-called free rider problem, too.

@michelekipiel @strypey
As it seems like you two are actually agreeing on 80% of it, how about this for a for thought experiment?
1: Whether there is agreement on the auteur developer mentality there is probably consensus that software development benefits from some degree of centralized visionary leadership (shepherding) and doesn't fair as well if run fully by large committee.
2: The best software isn't developed in a vacuum but rather as an evolving organism that routinely takes into account feedback and demand signals from users and organizations.
3: Cooperative ownership could provide a needed degree of stability and contributor equity to the development process and can be segmented to balance the different interests of connected and reliant elements.
4: As forking seems to be a common and valid way to continue and extend FOSS development projects beyond their "benevolent controllers" why not form a Mastodon multi-stakeholder cooperative that takes over development of Mastodon (V.X) fork which gets its User demand signals from Instances that choose to become federated members?
5: As members, Instances would have input on what tools were developed but not at a granular level. In exchange they would provide easy to understand and reliable reoccurring donations (based on user thresholds) that would be used to attract and engage the best and brightest developers.
6: Social.coop could actually take the lead on this simply by creating a voluntary contributed pool of Mastodon development resources to get the fork started and then overtime help other federated Instance members cooperative themselves if it was good organizational fit.

This basically anticipates where I was planning to direct the above discussion!
I find all 6 points absolutely valid, though I'm not sure forking Mastodon is a necessary step in order to develop it into a cooperative. Besides the risk of fragmenting the codebase, we might incur in the even worse risk of becoming a minor version with zero attractivness for the brightest talent. If I were to make the call, I'd rather try and introduce the idea to gargron and those working with him as a way to ensure the best possible survival chances for the project. It might seem a lofty goal, at a glance, but if the guys at Mondragon can run a multi-million € network of cooperatives, why can't we? :)

PS. For those reading "Ours to Hack and to Own", chapter 28 of the book is basically an intro to what we're trying to achieve in this discussion.

I agree presenting a cooperative structure to Gargron first is definitely a better option. In fact the 1st step should be to speak through regular re-occurring support contributions from a Social.Coop Mastodon development fund (being discussed as part of an overall budget discussion in Finance working group) that shows the cooperative potential.

Agreed! There's no better way than to lead by example. Let's focus on that Mastodon development fund and see where that leads us. In the meantime, let's keep this thread alive with links, news, updates and comments. I believe there's a lot we can achieve by pooling all our competences and resources!

Open source and cooperative business can be combined through application of the FairShares Model - www.anyshare.coop has done this by adapting a FairShares Company constitution to register a business that has been awarded the .coop marque. However, they varied the clause covering
members IP and this was tigthened up is FairShares V3.0.

You can generate FairShares constitutions for registration as companies, cooperatives, associations and partnerships containing this clause (53) by using the FairShares Rules Generator accessed at http://www.fairshares.coop/ownership/

Next week, we send revisions to the FCA for a specific UK option for ‘FCA Accepted Model Rules for a FairShares Cooperative. It must be registered in the UK but can cover EU ventures too. This contains clause 53 (all submitted revisions are based on FCA legal advice).

Sounds good in general, and IANAL, but here are a few points on clause 53 as it pertains to free code, free culture, peer production, and related issues from an activist POV:

• "Intellectual property" isn't a thing. See:
  https://www.gnu.org/philosophy/not-ipr.en.html

• this isn’t just splitting hairs about preferred wording. As Stallman’s essay explains, the key point is that the areas of law that get included under the “IP” umbrella (copyright, patents, trademarks, and so on) have totally different purposes and work very differently. Clauses that work if you're talking about one don't always apply the same way to the others, and some of the points below are examples of this.

• specifying that creators get to keep ownership of their own work is cool when it come to copyright, as its a strong protection against proprietary relicensing, but is usually inappropriate for trademarks. If I am paid to design a logo for the cooperative, it's not really appropriate for that logo to be owned by me as a private trademark, and licensed to the cooperative. Software patents are a misuse of patent law, and in some countries (like Aotearoa/ NZ) software is not covered by patent law “as such” (only as an embedded part of a hardware invention). Neither the company nor the creator of software should ever apply for software patents nor recognise their validity (see the short film ‘Patent Absurdity’).

• I’m an enthusiastic support of CC licenses (I helped start CC Aotearoa/ NZ), but:

  • they are copyright licenses, and they only apply to things subject to copyright law. Although you could apply a CC license to a logo, not only does that not confer trademark protection, it actively breaks it (every CC license permits all verbatim re-use). You can’t apply CC to other kinds of trademark like generic words used as a brand name, and if you could, it would break them as well. You can’t apply CC licenses to patents. Publishing a detailed description of an invention creates “prior art”, thus making it a sort of “open patent”, but this puts the invention in the public domain, with no ability to stop anyone from doing anything with it (except patenting it).
  • CC licenses are not the only commons licenses (others include the Free Art License, the Peer Production License, and all the free code licenses), and each CC license does a different combinations of things (even more so if you include CC0 and the CC Public Domain Dedication). Rather than specify that people apply CC to every copyrightable thing they create at work, it’s probably better to think about what you want the license to allow and forbid, for each kind of work, and let the creator choose a specific one (or a subset) that does that.
  • only the subset of CC licenses that are “free culture” licenses (see: https://creativecommons.org/choose/), are appropriate for licensing any work to be included in a free code project, and CC themselves say their licenses are not appropriate for source code, and that an FSF or OSI approved free code license should be used instead for code.

• In order for 53.a and 53.b. to work, the CC license chosen can’t include a NonCommercial clause. But this is directly contradicted by the point in 53.b.i about the company having “exclusive right to use and commercialize the IP”, in fact, using a CC license at all directly contradicts that aspect of 53.b.i. That clause is certainly incompatible with a free code license of any kind. None of this makes any sense when applied to patents or trademarks.

• You can give ownership of copyright to a work to both the creator(s) [53.a] and the company [53.b.i], but what’s the point? Especially when the copyright is being released through a CC or free code license allowing commercial re-use, and anybody can use it for anything anyway? Why not just decide whether it makes more sense for the creator or the company to defend the conditions of the copyright license and make them the nominal copyright owner? Again, none of this makes any sense when applied to patents or trademarks.

• The purpose of 53.c is unclear. For a copyright, patent, or a trademark to be “owned collectively” implies that is held in trust by the company, as the agent of the current members, which would happen automatically when the copyright is assigned to or bought by the company.

• Or is 53.c saying that when a copyright is assigned to or bought by the company, each person who is a member at the time becomes a co-owner with the company? If so, what happens when a new member joins? Do they also become a co-owner of all copyrights held by the company? What happens if a member resign their membership, do they remain a co-owner? If not, it’s a bit meaningless. If so, how does this ever-growing crowd of legacy co-owners make decisions about uses of the copyright not covered by the CC or free code license it’s under, or legal action to defend that license?

• all the same questions apply to 53.c when it applies to patents.

• 53.c makes no sense when applied to trademarks.

• 53.d contradicts 53.c. If you’re going to manage “IP” as an “‘intellectual commons’ for the benefit of company members”, why restrict “IP” assigned to the company or bought from third parties to “non-commercial use and private study”? In copyright law these are pretty much just their Fair Use/ Fair Dealing rights in most jurisdictions anyway. Patent law doesn’t restrict either of these activities anyway. How would anyone use a trademark for non-commercial user or private study anyway?

• 53.e this is the only clause whose meaning doesn’t have a hole big enough to drive a truck through. But free code projects often delegate this work to specialist organisations like the Free Software Foundation, Software Freedom Law Centre, Software Freedom Conservancy, or Software in the Public Interest. Unless your cooperative is a legal firm, or has a dedicated legal department, I’m not sure offering to take on complicated legal work for all comers really engages with how complex and contentious defending copyleft or other aspects of commons licenses can become. For example:
  https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003580.html

If the version in that image is the “tightened up” version, and they paid a lawyer to review it, then IMHO they deserve a full refund. This clause opens up multiple cans of works and need significant refactoring to be a useful guide, let alone a legal agreement.

Thanks for the comments - I’ll work with law scholars to see if any changes are needed. A few clarifications.

1. You ignore the emphasis on voluntary transfer of IP. If a member creates a logo, they can voluntarily transfer ownership of that IP under Clause 53, so the trademark issue is moot. Alternatively, commission the IP from a third party in which case ownership is help collectively (not jointly as you imply).

2. Agree with the attitude to patents - these clauses are designed to break the idea of patents.

3. Power rests with the member to choose the licence. In practice, BY-SA, BY-NC-SA and BY-ND all have productive roles to play in a FairShares enterprise.

4. Unilateral powers to enforce CC licences are needed to cover what might happen after a member leaves (to stop privatisation).

As I said, I'm an activist, not a lawyer, and this is not legal advice, just suggestions based on my reading and experience. I suggest consulting people like Lawrence Lessig, Eben Moglen, Karen Sandler, or Richard Fontana, all of whom are qualified in law, and have extensive experience in the field of commons-orientated copyright licensing, and trademark and patent issues as they relate to peer production projects.

1. Who owns the trademark is not the major problem here. It's that applying a permissive CC license to a trademark work (where it's even possible), as required by 53a and 53b, negates its value as a trademark (I explained why above). Clause 53 needs subclauses that deal specifically with trademark issues separately from copyright (or patents). See:
   http://www.softwarefreedom.org/resources/2008/foss-primer.html#x1-600005
   http://fossmarks.org/

2. How? Patents work completely differently from copyrights (or trademarks), for the reasons I offered above, and others. Sometimes patents may be appropriate to temporarily protect new commons against enclosure by highly-capitalized corporations. Other time, they may be totally unethical (IMHO neither software nor drug patents are necessary or justified, ever). Clause 53 needs subclauses that deal specifically with patent issues separately from copyright (or trademarks). See:
   http://www.softwarefreedom.org/resources/2008/foss-primer.html#x1-390004

3. So why limit their choice to only CC licenses? At the very minimum, for this constitution to work for cooperatives working on free code software, clause 53 needs to allow members creating software at work to use a license approved by the FSF and/or OSI:
   https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software
   http://oss-watch.ac.uk/resources/cclicensing

4. Once a CC license (or any other commons license) has been publicly issued, it can't be revoked, and anyone can use the work under any license the copyright holder has issued at any time. However, the copyright holder can issue new licenses on the same work with different conditions (eg issue a commercial license on a work covered by CC BY-NC-SA, or allow a company to opt-out of the copyleft clause of GPL for a fee). Is 53.b.1 meant to prevent this? If so, wouldn't it be simpler just to make it a joint copyright between the company and the creator, right from the time copyright applies (when the work is "published")? That would make all of 53b unnecessary, as permission from all joint copyright holders is required to engage in any kind of proprietary relicensing, "exception sellng", or exclusive commecial licensing.

I want to make it clear that despite my niggles about the details, I think it's a fantastic idea to offer open source constitutions (so to speak) that groups can adapt and use to reduce the barriers to forming new cooperatives. It's precisely because I see the immense value in it that I want to make sure it is applicable to free code software cooperatives. The constitution for Loomio Ltd. (the cooperative company that develops Loomio and hosts this service) might be useful for comparison:
https://loomio.coop/constitution.html

You over complicate this, I think, and also place too little trust in people and cooperation. On trademarks and patents, I think the easiest solution is to exclude them right at the start of Clause 53. But even if you do not, I’ve only ever known logos to be commissioned so they are covered by the third party provisions.

I was director of a worker coop (an IT company) for 12 years before going into academia (where I have been for the last 15 years). The best use of the law and contracts is to write in powers for both parties that prevent either ever going to court (or even threatening it). For the software projects I negotiated, we wrote in rights for both supplier and customer to be able to amend code supplied for their own purposes. In 12 years, we never got into a legal dispute with any client about IP for any reason.

I share offices (and work with) a law scholar on this particular issue, and three additional lawyers looked over this coop constitution last month. Lastly, law professor in Australia is particularly supportive of this clause precisely because it commits to opening up IP and ensuring public benefit from it (bearing in mind it covers more than code) I’m a professor of cooperative social entrepreneurship, not law, but my expertise is in crafting governance systems that forge cooperation, not competition.

My law scholar colleagues do not share your concerns, but I will alert them.

You over complicate this

Seriously? We're talking about the constitutions of businesses that people's livelihoods will depend on. To paraphrase Lessig, law is code". It runs exactly as it's written. If it's not written precisely, you get bugs coming back to bite you at run time.

and also place too little trust in people and cooperation.

Not at all. I trust that people will do their best to follow the rules they've agreed to. If those rules tell them to divide-by-zero, it's going to cause stress and disunity as everyone tries to figure out which of the self-contradictory rules to follow. I would not join a cooperative whose constitution has this clause in it (as currently written), and would strongly discourage anyone from using it for a software coops.

On trademarks and patents, I think the easiest solution is to exclude them right at the start of Clause 53

That's a good start. Then they can be addressed in their own clauses. No company can be without a trademark policy, even not-for-profit free code projects have one. Coops developing free code software, in jurisdictions where software patents are recognised, are strongly advise to have a patent policy, although you don't necessarily need one for every kind of coop.

I share offices (and work with) a law scholar on this particular issue, and three additional lawyers looked over this coop constitution last month.

Have you seen the film The Castle? Do you remember the scene where the smalltown lawyer was trying to argue constitutional law? Digital commons law is a new and highly specialized field. I strongly recommend you seek comment on clause 53 from at least one of the people I mentioned.

law professor in Australia is particularly supportive of this clause

That wouldn't be Professor Brian Fitzgerald would it? If not, he would definitely be a good person to seek comment from, and specifically mention that this "IP" clause would cover code as well as other kinds of publshed work.
https://creativecommons.org/author/brianfitzgerald/

precisely because it commits to opening up IP and ensuring public benefit from it

Don't get me wrong, the intent is great. I'm just suggesting a few patches that might encode that intent a bit more clearly.

"We're talking about the constitutions of businesses that people's livelihoods will depend on."

Yes - which is why I shared with you that I ran an IT coop for 12 years in a way that protected people's livelihoods (which I notice that you do not acknowledge). Legal agreements can be framed in ways that encourage and reward co-operative (joint) decision-making when disputes arise, rather than set out a 'follow the numbers' approach that kills both the human spirit and business relationships.

"To paraphrase Lessig, law is code". It runs exactly as it's written. If it's not written precisely, you get bugs coming back to bite you at run time."

If you think the law is like software, think again. Code is interpreted by machines that have no conception of ethics. The law is interpreted by human beings who are social, ethical and political all the time. But, if that is how you see it, I will never persuade you that it is folly to approach the law (and people) like this. It is the Weberian philosophy and perspective on law that I've spent my entire (cooperative) existence opposing.

(Lastest article opposing this kind of Weberian rationality was published in the Journal of Business Ethics this year - see https://link.springer.com/article/10.1007/s10551-018-3794-5

My 30 years of experience in cooperatives is that democracy (i.e. deliberative processes) are much better at determining when rules should be enforced and when not enforced (don't leave it to lawyers!). Democracy can be extended to clients / suppliers if your constitution allows you to extend it. It is also possible to write legal agreements that incentivise mediatory rather adversarial justice. The papers I've published on this reported research findings that people who go through mediation are much happier than those that pursue court alternatives, and are also able to preserve important relationships.
[See https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1468-2338.2011.00614.x

If you really believe the Lessig quote, we'll have to agree to differ. Give whatever advice you think is right and I'll continue to give advice (and write constitutions) that take account of (social) scientific evidence.

Relax guy! I'm not attacking you, or your project. I'm giving a detailed bug report. It's a contribution to your project.

The law is interpreted by human beings who are social, ethical and political all the time

Sure, which is precisely why lawyers have a job; it's really hard to write rules that clearly communicate your intent, and will be interpreted the same way by all parties. Put it this way; if it can all just be left up to deliberative democracy, why have a constitution at all?

I have been involved in many informal organizations that work on the Bill and Ted principle; "Be excellent to each other, and party on dudes!". It works fine for many low-commitment projects (not all), but I would never try to run a business without a formal constitution. Doing everything possible to make it legally bombproof is just due diligence.

Legal agreements can be framed in ways that encourage and reward co-operative (joint) decision-making when disputes arise,

I'm all for co-operative decision-making, but copyright and trademark licensing aren't just about what the coop members can and can't do. They're also about what an entire internet of potential external contributors and re-users can and can't do.

You could fix a lot of the problems in clause 53 by replacing every instance of "IP" with "copyright" (and adding separate clauses for trademarks and patents). But even then the current wording still creates issues, even with total goodwill on all sides. For example, 53.i.b is totally incompatible with free code software development.

Let's say I do some programming for a coop using this constitution. Under clause 53, I hold the copyright (53.a), and I have to license it under a CC license (53.b), but I also have to give the coop exclusive commercial rights (53.b.i). Huh? How can I do both.

OK, I can use a CC license with a NonCommercial clause, and give the coop a separate exclusive commercial use license. But then it's not free code, because both the Free Software Definition and the Open Source Definition exclude any license that reserves any commercial rights. Also, making NC clauses compulsory totally clashes with your assessment (one I agree with) that "BY-SA ... and BY-ND all have productive roles to play in a FairShares enterprise". You see the problem?

Also, what if want to re-use an existing piece of GPL software in my coop work? If I make any improvements to that code, the license obliges me to share them under GPL, but the constitution obliges me to license them CC NonCommercial. Huh? How can I do both?

I ran an IT coop for 12 years in a way that protected people's livelihoods adoptin

Let me ask you a question though; did this IT coop produce free code software, or proprietary software? Because clause 53 looks to me like it was written with the latter in mind, and CC shoe-horned in after-the-fact with no regard to the overall coherence of the clause.

(which I notice that you do not acknowledge)

Because it's not particularly relevant to whether or not this constitutional clause is workable. Any more than it's relevant that I co-founded a CC jurisdiction project, and have been involved in CC and software advocacy for about 15 years. I don't expect you to believe me because of what I've done. I expect you to evaluate the logic of what I'm saying (or lack there-of) , and seek advice from domain experts (like those I've mentioned) who know more about this than either of us.

I am relaxed - that's why we must agree to differ. Talking about 'bugs' in contracts simply reaffirms that we see the world differently and won't reach agreement on this. That's okay - you give your advice, and I'll give mine. The conversation was fruitful and I will amend Clause 53 as a result (to exclude or reframe issues on patents and trademarks) - for that I'm grateful. So we part amicably, even if we don't see eye to eye.

@roryridleyduff1

The conversation was fruitful and I will amend Clause 53 as a result

Glad to hear it. As you redraft it, it might be worth thinking through how it would apply if a foundation/ association like Apertus transitioned to being a cooperative, operating under your proposed constitution:
"Our intention is to create affordable, free software (FOSS) and open hardware (OSHW), digital, motion picture technology for the professional production environment ... We release all of our software under the GNU General Public License V3, all our documentation under the Creative Commons License, and all hardware under the Cern Open Hardware License. "
https://www.apertus.org/mission-statement

Nadia Eghbal published a good potted history of free code development.
https://medium.com/@nayafia/we-re-in-a-brave-new-post-open-source-world-56ef46d152a3

Scroll down to the section called 'Code is not above the law' for an insight into potential problems caused by code being automatically license under CC on Stack Overflow.

Thank you for sharing!

As it turns out, there's a long running thread on Mastodon governance on the Mastodon Meta discussion board with a little bit of recent discussion: https://discourse.joinmastodon.org/t/mastodon-project-governance/215

I can't wait to be out of office to read through it!

In the wake of the ForkOff situation ( https://social.coop/web/timelines/tag/forkoff ) I believe there is no more time to waste: we should reach out to Gargron and pitch the cooperative idea to him and whoever else is now at the helm of Mastodon.

The kind of drama happening now (ie. devs ignoring specific requests put forth by some users) is the natural outcome of the benevolent dictatorship model and proves that, no matter how decent, good and caring a person is when starting a massive FOSS project, they are ALL bound to reach the "I make the rules" stage, because that's the nature of human beings when exposed to massive stress.

It's interesting as a thought experiment: how would social.coop (as it stands now) manage the forkoff situation differently?

I'm seeing a potential connection between this and the MaaS co-op conversation we had a few weeks ago. The biz model could look like instances that host with the co-op are members, with a % of the monthly hosting fee devoted to the development fund, with instances hosted elsewhere also allowed to become members by making a minimum financial contribution to the development fund (per-user fee. Each member would have one vote, and could elect a council to oversee development, with some decisions put out to a vote of the full membership.

Some questions to consider:
- How would we deal with single-user instances? Would they have equal voting power as an instance with thousands of users? Or should voting be weighted by # of instance users, so more people effected = greater governance weight? Or should voting membership be limited to instances above a certain scale?
- How collective vs. representative should the governance be?

@michelekipiel agree that this would be a good opportunity to broach the subject with Gargon (et al). Couple considerations-

1: We should have a pretty solid rough alternative to pitch that shows how it would be less head ache and more financially stable.

2: A good number of FOSS developer community that have been primary contributors to Mastodon so far should be identified and approached at the same time to gain their support.

3: Some consideration should be placed on enshrining the contributions of the "founding" developers of Mastodon both symbolically and by an ability to earn a % based royalty on the work they have done thus far and for turning over the reigns of Mastodon Prime development to a cooperative entity.

@matthewcropp to weight in on your considerations.

The most fair and manageable option might be to have representation at the Federation level to be based a number of votes for user thresholds and monetary commitments. A fairly low bar could be set on the per user contribution and my guess is that is would still be much more than what is being contributed to Masto development under current donation system.

On Representative vs Direct democratic governance the Federation Council could determine what things go up for popular (individual user) vote and what is voted on by Instance Representative. Similar to how State ballot measures are used vs State governance. My guess is that things like new Functions would be where the popular vote gets used.

Agreed on points 1, 2 and 3.

As for the representation part, I believe user count is the fairest method: 1 representative each X users. It will allow every instance to have at least one vote, while allowing the largest to be granted a reasonable number of votes. Based on a one-head-one-vote rule, each instance would elect a number of delegates to represent it in the "global assembly" at Mastodon Coop. How each instance would handle such election would not be Mastodon's problem (ie. one less thing to manage).

Delegates wouldn't act as MPs in a parlimenti, but rather as liaisons between the global assembly and their instances: instead of voting on behalf of their instance, they would be responsible of taking the matters discussed by the assembly to their users, where such matters would be put to the vote. Once the vote is cast at the instance level, the delegates would then vote accordingly ot the global level, thus expressing the direct will of their instance.

One reason to not tie representation directly X amounts fo users but have it weighted (described in comment below) is to not allow for the largest instances to gobble up the representation and crowd out the voice of smaller instances.

One factor when looking at how much direct democracy vs representative democracy to include is to keep intact the self autonomous instance aspect which seems to be a primary draw to Mastodon. The majority of the instances aren't run democratically so not sure collective governance in all decision making aspects is a good fit?

to not allow for the largest instances to gobble up the representation and crowd out the voice of smaller instances

Good point, let's elaborate on this to reach a solid proposal.

The majority of the instances aren't run democratically so not sure collective governance in all decision making aspects is a good fit

That's hardly a problem from the Mastodon Coop point of view, in my opinion. How instances self-manage is their private matter, though Mastodon Coop could lead by example and even provide some high-level guidance on how to democratize instance governance.

This is very exciting! Happy to help on a proposal.

This seems very exciting -- I have no sense how realistic it is, not knowing the players and history well enough. Two general thoughts: a) a clear and strong statement of principles is needed to orient the proposed transition (including strong language on instance autonomy) and b) we need to clearly separate money from voting rights -- i.e., you don't get more votes if you put in more money. This raises the need for an Inter-Cooperation Working Group or Cooperative Development Working Group, I think.

Yes you should not be able to buy more representation although User count alone is also not a fair marker either as User count can be gamed fairly easily. Which is why a middle ground might be to set thresholds. Something like-

Class A: 1-100 Users 1 Vote (seat/representative)
Class B: 101-1000 Users 2 Votes (seat/representatives)
Class C: 1001-5000 Users 3 Votes (seat/representatives)
Class D: 5000-20,000 Users 4 Votes (seat/representatives)
Class E: 20,001....

Overlay that with an expectation of a tiered (A:$0.50, B:$0.25, C:$0.20, D:$0.15. E:$0.10/... user count) monthly dev contribution range per instance and you would have representative system that respects smaller instances as well as larger instances at the representative level but allows for popular vote when applicable at the user wide level.

This of course would be a big departure on how Masto dev and instances function right now but this could all start with an "expected" rather than a required financial contribution to allow for a more representative/democratic process to take hold while keeping some visibility on the finical sustainability aspect to all of this.

Not sure how Developer representation would work at the Federation level. Maybe they would have be a part of separately managed Coop/Collective dev group and have certain percentage of Votes in relation to the overall Federation council like (40%)?

I like the idea of scaling the contribution according to the user count. Larger instances will end up contributing more anyways, despite lower per-user fees.

I think the max number of representatives must be capped, otherwise you are putting pressure on the greater community to make big instances.

Or even go regressive, if they get too big.

On the #forkoff, it has raised a larger question for me around whether we should have a long-term goal of maintaining our own fork that is optimized for democratically-governed fediverse instances?

I think being able to maintain the server consistently stable and running a recent version of Mastodon would be a great first step on this path.

TruFax

@matthewcropp . . . 'maintaining our own fork that is optimized for democratically-governed fediverse instances' . . . a commons to be skilfully conceptualised and curated and stewarded with rigour and determination (much labour, some kit, some ££, and not a little legal/licence stuff?).

But not (?) a means of livelihood? Perhaps yes, this too? #Mastodon does this for @Gargon? But for most stakeholders, no? Careful balancing of multi-stakeholder coop form/governance.

Totally with you on this one: if we ever get to fork our version of Mastodon (whether this is a good idea is still to be seen) it should definitely offer a livelihood to those working on it. It can't be stressed enough how important it is for the FOSS community as a whole that we make it clear that the multi-stakeholder cooperative model we''re debating here is meant to replace the current donation model and the unsteady and volatile income stream tied to it.

A terrific and significant thread this @michelekipiel thanks. Is it sufficiently complex now that it would benefit from a bit of judicious editorial forking to make it more usable for the thread-purpose? Or a contents list in the context field? . . .coupled with a few editorial comments aggregating links to sub-threads? The latter we can contribute to. The former are open only to you.

Maybe run a poll on what the sub-threads seem to be? But maybe, wait until the dust of #ForkOff is settling a bit?

@mikeh8

Is it sufficiently complex now that it would benefit from a bit of judicious editorial forking

One thing that often helps with long-running Loomio threads is for a volunteer to edit the context box at the top, to summarize the discussion so far. That way, anyone arriving in the thread for the first time can get up to speed without reading a huge wall of text ;)

Could someone do that with this thread perhaps?

In most Loomio groups I've been part of any group member can edit a context box in a thread in that group. Seems that in this thread only @michelekipiel can edit the context box. Hmm. Is this a group level setting or something you set Michele?

No idea... I don't recall changing any setting when first opening the thread. I'll double check and let you know!

This is the kind of editorial thing I generally like to do. But right now I'm up to my ears, so am not open to this helpful work on this significant thread at this time. Sad to say. Any takers?

From the POV of an outside observer from GNU Social land (only recently moved to a Mastodon instance), a lot of the current conflict in the Mastodon community seems to derive from three things;

1) As @saper pointed out in the governance thread on Discourse, some confusion about which decisions only affect Mastodon.social (the flagship instance), vs which affect Mastodon (the software/ network of instances), vs. which affect the fediverse (the meta-network of all instances of all the social apps that can inter-operate)
2) Two overlapping but different sets of design goals for the UI
3) Two very different and conflicting sets of expectations about how to govern and manage the software development process

Issue #1 could be mitigated by user education, based on clear, user-friendly documentation explaining the boundaries between each layer. Issue #2 could be solved for instances that don’t like @Gargron’s UI design choices, by swapping out the vanilla Mastodon web client for something like Pinafore or Halcyon.

But I think the deepest and most difficult problem here is #3, and this one has no technical solution, because it’s a social problem, not a technical problem. There was an attempt to solve this problem by having @maloki employed as a Community Manager, but this doesn’t seem to have solved it. I agree with Maloki that the only solution that will allow everyone to get their needs met is a fork; a new project with its own name, identity, code repo(s), documentation, and community processes.

I've posed some discussion questions for the would-be forkers here:
https://discourse.joinmastodon.org/t/mastodon-project-governance/215/41?u=strypey

the only solution that will allow everyone to get their needs met is a fork; a new project with its own name, identity, code repo(s), documentation, and community processes

Mastodon is already borderline impossible to get for the layman as it is, let's not make things worse. I'm not against specific groups forking their own version to serve their peculiar needs, I'm against spreading the idea that fragmentation is the only viable solution.

"If we consider the OECD findings on computer literacy accurate, Mastodon is inaccessible to all but maybe 25% of the population. It has a high social friction coefficient and a disturbingly exponential technical friction coefficient."
(Quote from: https://hackernoon.com/my-journey-into-mastodon-three-ish-days-of-overcoming-friction-d8d80285c23c )

I responded to this by email, but the reply seems to have got stuck in #TheClacks ;) TL;DR a) the fork is a happening whether we approve or not (eg see: https://elekk.xyz/@maloki/100184064777891255) b) I expect Gargon will be relieved to see most of these people go. c) I think this is all a distraction from building coops around hosting and improved #UX (an area where user-driven design can help a lot), but if you want to make a proposal I suspect Maloki's crew will be much more welcoming of governance input than Gagron

think this is all a distraction from building coops around hosting and improved #UX

Agreed. The UX of Mastodon as a whole (ie. everything from understanding what federation is, to picking an instance, to finding people etc...) is frankly sub-par compared to corporate social media.

This thread is getting a bit tangled to follow! @strypey says "this is all a distraction". But if this is the question of taking a stake in a Mastodon development fork, and instituting a coop to govern this, then I would say that this is very much about creating the conditions for developing the Mastodon UX, through user-driven design as Strypey advocates. And as @michelekipiel says, the Mastodon UX sure as hell does need improving!

A question to those who are more technically familiar with the app . . . do you believe that the architecture of Mastodon is open to a very much redesigned UX? Strypey has been wowed by his new UX of the Pinafore skin for Mastodon - and I do think that it is cleaner, which is a step up. But still a bit nerdy, requiring a lot of tech- and fediverse-literacy, and not very accommodating to folks like me who don't sit all day in front of a screenful of dev tools and internet feeds, but just want to 'see' a community's traffic flowing by in a filterable, attributable, trackable, searchable, non-intrusive, beautiful way. If the Mastodon architecture can be framed that way, great, let's take a stake and build a coop to build the UX.

I'm very impressed by the way that social.coop folks talk carefully and collaboratively together. And it would be great to have an app/UX that supported conversation comfortably in these kinds of considerate and diverse and diversifying and purposeful community.

Not a distraction at all then? Rather, a great gift to humankind and a great leap forward in the history of internet cooperation and literacy? If there's something clunky in the underlying architecture of Mastodon, which means it always will feel nerdy - forget it. But maybe it's the fediverse that's nerdy, in which case the solution is to develop the UX that welcomes and makes comfortable and inspires a different user community, who are not nerds (all the time! self included)? And not the undisciplined ego-blasters who trip-out in commercial social media and in the widest Mastodon public feed ;-) Am I really saying 'Build it, and they will come'? Hmmnn not sure about that. But as a designer and a cooperator, I do have faith that a lovely tool will find a community of skilful loving users.

Based on my insight as a developer who haunts the Mastodon github on and off and has several pet issues ... yes, it's very very possible to use Mastodon with presentation layer (like Pinafore, or any number of mobile apps) that isn't the same as the official mainline UI. I do probably more than 90% of my activity in the fediverse on my phone, in part because I've moved to mobile for a lot of my interaction, and in part because I don't like the mainline UI. The software is set up such that it's not that difficult to put different front ends on it.

As for the rest of the conversation... I don't think contributing to #ForkOff in the near future is a good idea for social.coop. There is a great deal of nastiness involved, and the entire thing exists as someone else said due to a social problem, not a technical one, and further, it's not a social problem that the co-op model will necessarily go a long way to solve (in my opinion anyway).

I strongly agree that the fediverse could benefit from better UX, but I think a particular UI to suit the needs of co-op modeled instances should be its own concept/project completely separate from #ForkOff.

There are two things tangled together in this thread as I see it. One is the broader issue/opportunity/potential of the applicability of the cooperative business model as an effective sustainable solution to the challenges of running successful FOSS projects. The title talks about developing a white paper as a start point to move that on, and I'd support that approach.

The second is the specific opportunity(?) presented by the current debate within the Mastodon project. I've not got involved in the guts of that debate, but it looks/looked pretty fraught, so whether there is actually a real solid opportunity there or not I don't know. I'll leave others to assess that and act accordingly.

Other possibilities/opportunities. The Drutopia project, for example (don't know it that's already been mentioned in this thread) which describes itself as a 'software cooperative', might provide a better place to learn, develop and refine the thinking?

@mikeh8 @michelekipiel
I've used a cafe metaphor to explain how I see the situation. It got long (who, me?), and I thought it might be of more general interest, so I blogged it:
https://www.coactivate.org/projects/disintermedia/blog/2018/06/12/from-digital-cages-to-cooperative-digital-cafes/

TL;DR the distraction I meant was the ongoing Mastodon drama, something I think the fork is the most likely way to resolve. Yes, I see #ForkOffTogether as on opportunity to bring coop governance to a new fediverse project, go for it. But social.coop has many software options either way.

I agree with Muninn that working on a cooperative model/concept/project for the larger Mastodon (Fediverse) in which SC resides is and should be separate from the current #ForkOff activity.

That being said I do believe that the lack of (democratic or other) representation into main line of Masto dev nor a verifiable process to air grievances by users has contributed to and exacerbated the current and past social ills of the community at large and will continue to do so in any community/fork that fails to address that.

I wish we could dis-entangle this idea - posted 3 months ago now as I write this - from #ForkOff. There are people behaving quite unpleasantly under that banner at present.

Perhaps we could make a separate thread, and send a couple representatives of our community to their meeting once they get the time set up and everything, and then discuss any potential for working with the #ForkOff folks after their initial meeting? Hopefully I'm not just adding more noise, but this thread is already pretty long, some other people were talking above about how it's hard to get into.

Hell, maybe two separate threads - a Part 2 on this one, and a ForkOff-specific thread, and lock this one?? Just throwing ideas out there to keep the discussion(s) focused..

I wish we could too. Even though it was an accelerant and maybe an opportunity to catch the attention of some dissatisfied users, admins, and devs the label is more of a distraction. possible @michelekipiel could get rid of the ForkOff language in the Proposal but I think it's now colored the thread a fair bit. Given the split of support and concerns of diversion away from things that critically need to do get done for SC alone there is a good chance this may be split off from SC activities for those like myself and Michele (or any others interested) who might want to explore deeper into a Federated Mastodon Coop model. Once there is something solid it could be resubmitted back to SC for feedback, etc.

Hi,

thanks for asking the question. I believe the "ForkOff" label in the poll is being misinterpreted a fair bit. I didn't mean it as a declaration of allegiance, so to say (ie. I'm not taking sides here), but rather as a keyword to better ground the poll in a given context (ie. the whole situation that erupted around the #ForkOff hashtag).

I am by no means willing to tie this thread to the fortunes, or lack thereof, of the ForkOff group, as the matters at hand are MUCH more important than the mere squabble of a few disgruntled users.

I'll remove the label at once to avoid further confusion.

Thank you and sorry for the inconvenience.

There are people behaving quite unpleasantly under that banner at present.

... and since this appears to be their typical modus operandi, if you read some of the Mastodon GH issues, this is precisely why I suspect Gargron will be thrilled to see them go. Sadly, a lot of their ill-mannered noise included demands for "democratic governance" (reading between the lines, systems they could more easily game to put themselves in charge of the active developers), so I suspect it will be a while before Gargron won't be re-traumatized by any proposal to democratize Mastodon dev.