[Meta] Tensions between commons-based peer production and managerial hierarchical models of development in Enspiral (and Holodex)

[simontegg]

Commons-based peer production (CBPP) has established governance principles and practices[ Y. Benkler, Peer Production and Cooperation ]. I'll post these in the thread below and reflect on how Holodex has performed in the last half year.
Many open-source/open-governance projects have proven these practices to work, and even out-compete Managerial Hierarchies (MH) in the same domain.

A tension I have often perceived in Enspiral is that contractual or contractual-lite ("I will complete stakeholder valued task X by Y time") task/role allocation prevalent in MH conflicts with a fun and autonomous task selection common in CBPP ("I will work on what I'm personally interested in, on my own time") .

MHs achieve coordination by enforcing negative consequences for contract-shirkers (diminished reputation and/or opportunities for future paid work), and reducing uncertainties (at least in principle). This allows MH to execute projects with multiple interdependent parts, at the expense of the task completer's autonomy and learning.

CBPP projects achieve coordination by primarily through establishing a community of peers with a critical mass of contributors with a diverse range of motivations.

Team Holodex wishes to establish the project as a successful example of CBPP and establish a system of interoperability in line with our values of the commons, provide value back to Enspiral and influence Enspiral to grow in a more CBPP-way.

While the concept of interoperable apps has gained currency in Enspiral, current tensions include:

(1) "Interoperability" is often (but not always) viewed through the lens of "Loomio as the central hub"

(2) The Namaste grant is the main locus of interoperability work. This work is framed in a way more in line with a MH style of development: "deliver Loomio and Cobudget Interoperabilty by Y time"

(3) Established CBPP communities have reduced uncertainties through scale. If 50% of a large community choose to engage in high risk or uncertain value creation we can still be sure that the community as a whole will still generate high priority value. Holodex has two people part-time. When we favour autonomous/intrinsic task selection we create a lot of uncertainty. In my view, this has a number of follow-on consequences:

(3a): Communication with stakeholders becomes difficult (3b): Potential open-source contributors may be reluctant to invest time into a project without a threshold of certainty ("if I contribute, will it all be for naught?")

These issues have been on my mind and invite others to share their perspectives.

[simontegg]

1. Communication. Unlike the standard game-theoretical assumption of no communications best response systems; a critical design focus of cooperative human systems is to assure extensive communications. Communications systematically improve cooperation in experimental set-ups; human, unstructured exchanges, rather than canned messages, are important; and face to face, or more humanized exchanges, are important too. Low cost communication has been a pervasive feature of economic models of peer production, and the persistent role of open and continuous communications has been core feature of anthropological and sociological descriptions of peer production.

http://www.benkler.org/Peer%20production%20and%20cooperation%2009.pdf

I would give us a C- for communication both internally and externally. With our first release we now have a tangible thing to anchor our external communications. Before this point I've felt that our communications were too conceptual and abstract for anyone unfamiliar with interoperability to engage.

[simontegg]

1. Fun. A repeated finding in surveys of FOSS developers is that fun, and a sense of self-efficacy, or the ability to do something well under one's own direction, are important motivators.. While fun is not a prosocial motivation, it is a fuzzy, intrinsic motivation that will drive behavior without requiring that it be formalized into price or command allocation mechanisms.

Overall I would give us a B. I've had fun coding a challenging UI. I've also been a bit desperate to get out a release to met our commitments and unlock easier communications (see above)

[simontegg]

Normative framing and norm setting. How a situation is framed normatively effects the set of motivations most salient to an interaction. Framing cannot, in the long term, be an exercise in manipulation, because participants learn when the framing is inauthentic. Rather, the normative framing of an interaction must be authentic and sustained in order to permit the relevant motivations to develop and become fixed in the interaction...

I haven't thought enough about this one to comment

[simontegg]

Reciprocity, reputation, transparency. Reciprocity has long been understood as a central mechanism for sustained cooperation. Over time, evolutionary biology in particular has shown that looser and looser definitions of indirect and network reciprocity can sustain cooperation in a population of strangers. The surveys of FOSS programmers have long placed reciprocity at the heart of FOSS practices. Algan et al 2013 show that a behaviorally-measured proclivity for reciprocity indeed predicts a substantial amount of contributing behavior among Wikipedians. As the set of people who engage in reciprocity increases, reputation mechanisms that enable some persistence of identity across contexts, and a level of transparencyregarding past behavior of participants can all improve levels of contribution.

I would give us a C+ overall.

[simontegg]

Fairness. Extensive experimental and observational work has documented the importance of perceived fairness of outcomes, intentions, and processes to maintaining levels of prosociality. Repeated studies of FOSS and Wikipedia emphasize the suspicion of power (There is No Cabal TINC), and continuous negotiation of assuring that the processes, outcomes and intentions of participants and leaders in particular are accepted by participants as fair.

C I've felt like my stepping in to do design and deliver on our commitment to Services, (despite having two other jobs) was unfair.

[simontegg]

Empathy and solidarity. Cooperative systems perform better when they emphasize other-regarding motivational vectors. In particular, systems that allow an agent to see and interact with, or take the perspective of other individuals improve cooperation. They effectively include an argument in each agent's utility function that takes the payoffs of the other into account (albeit, mostly discounted). Moreover, ingroup bias, or solidarity, is a distinct motivational driver that triggers higher degrees of contributions to public goods and cooperative games where present. Measures to develop collective identity, sometimes as simple as naming a team or wearing a uniform, can significantly affect contribution levels...

B+. @ahdinosaur and I have a good relationship. We frequently express empathy and solidarity for each other.

[simontegg]

tagging others with an interest in this, the above is a part brain dump, part retrospective. @mixmix @rdbartlett @joshuavial @charlie-ablett

[joshuavial]

Very interesting, I'm not sure I can relate to the underlying tension about keeping commitments and having fun.

I think it's up to individuals in a decentralised system to make good contracts that fit in with where they want to go. The main response I would suggest is that we need to support each other to make better contracts and the example you cite in the fairness reflection sounds like the symptom of a suboptimal initial contract. Or maybe having someone make a promise to you that wasn't fulfilled.

On your initial points

1. You've been talking to too many Loomions :) - my perception of interoperability is of Loomio as a component not a hub. It is the most mature app and brand though and it makes sense that gives the project a natural gravitational pull.
2. I think that resources also add gravity and as a collective we made some promises to deliver certain things that we need to keep. I agree that the Namaste grant is more centralised than I would like and in the future I would be keen to try an experiment where we cobudget a decent pot of money and have lots of actors independently choose what they will fun. At this stage I think our accountabilities over bucket outcomes are too weak for that to be a reasonable option.
3. The main criticism I have of CBPP is that it is all voluntary labor - if we're going to pay for people for their work I think we need a vibrant marketplace where there are enough micro-contracts so there is a good intersection between intrinsically motivated tasks and things which will pay the rent.

[mixmix]

Disclaimer: skipped some of those quotes

Fun

It sounds like you're drawing a dichotomy where MH = not fun, CBPP = fun. I totally agree that fun is important. I'd also like to make space for fun looking like different things for different people.

e.g. For me, too much big picture thinking and experimental tech is not a fun time, but this is other people's life-blood.

Contracts

Both MH and CBPP employ social (or legel) contracts to manage expectations, and minimise communication overheads. We need to talk about what informs the contracts (rather than higher level implementations like MH and CBPP). I think we've been skirting this conversation and as a result experiencing muddy contracts and their damaging fallout.

Highest valued outcome

My experience is that while it's common for people to share their top-5 values, it's common for the ordering of positions 1 & 2 to be different. Common contenders are:

• autonomy / self actualisation
• research / exploration
• working products

NOTE: these are not mutually exclusive, that would be crazy. Also, fun is not on that list, rather it's found at each level and probably most densely in an individuals number 1.

The way you prioritise your valued outcomes will pre-dispose you to strongly preferring different sorts of organisation and contracts.

[mixmix]

couple of other responses:

Namaste I think it's important to hold the context of the Namaste grant. It was won by communicating with a (probably) MH organisation, using a framework which would make it easier for them to resource us, which, unsurprisingly was more MH. If you know how to crack attracting resourcing from an MH-like org into a CBPP-like org, then I'd love to hear about it. It's a very hard problem. One solution is to put a wrapper on a CBPP to give it MH-like interfaces. I think that's what we've done with Namaste. The problem is it just moves the location of that negotiation internally and puts incredible stress on the internal contract signatories to reconcile these cultural tensions.

Scale => less uncertainty ? I didn't follow. I'd suggest that scale forces the contract conversation, because the overheads of unclear contracts and unclear shared values start to overcome cohesive social forces.

[simontegg]

It sounds like you're drawing a dichotomy where MH = not fun, CBPP = fun. I totally agree that fun is important. I'd also like to make space for fun looking like different things for different people.

I agree with this. What I intended to highlight (and as you discuss in your later comment) is that Intrinsic motivation (an important subset of fun) depends on a sense of autonomy, and the way contracts are framed and negotiated often impedes a sense of autonomy.

Note: I'm not talking about my own sense of fun in particular. Rather, my noticing of a general tension between these two paradigms at a high level.

[ahdinosaur]

re: contracts, https://github.com/holodex/app/issues/86#issuecomment-107260293.

[simontegg]

@mixmix:

One solution is to put a wrapper on a CBPP to give it MH-like interfaces. I think that's what we've done with Namaste. The problem is it just moves the location of that negotiation internally and puts incredible stress on the internal contract signatories to reconcile these cultural tensions.

Good observation. I haven't cracked this problem, but talking about as we're doing here is a start.

[simontegg]

Scale => less uncertainty ?

Its not a radical insight. I mean to highlight how in a large-scale open source project (like ZeroMQ ) if any single developer or group of developers decide to check out for a while then it does not risk the viability of the project as whole. Therefore, developers on these projects can expect higher degrees of autonomy and users can expect higher degrees of certainty (that bugs will be fixed) than versus small-scale projects.

[mixmix]

@simontegg that makes sense. Interesting to note that some companies with MH try to balance this with planned autonomy time, as in Google/ Rabid with 20% time.

I think the knowledge / experience we might be lacking is knowing what a large scale open source project operates like. what does it feel like, who holds the culture, and where did that come from.

---

In terms of accessibility, is this conversation happening on Loomio as well as here in nerdville? I'm aware that this is an important conversation and that it's very unlikely for some people to join it here

[simontegg]

I think its ok to have conversations on nerdville in obscurity. I like how I'm not forced to make everything as accessible as possible for the non-technical audience (its tiring to do that all the time), and this content is partially about Holodex internal processes. I may migrate some learnings to Loomio.

[joshuavial]

Everything is getting fed through to the slack channel for others to listen into anyway.

[mixmix]

you mean the holodex channel? i'd be surprised if anyone is reading it.

no-one is forcing you to do anything @simontegg . I'm just putting my hand up to say "if we want this conversation to be effective, it's going to need to include the broader enspiral community". But yeah starting in one place then moving around could work well

[mixmix]

context : I'm reading this as the thread where we're talking about how various people are having trouble working with one another in enspiral, and there seems to be some ideological manoeuvring which could do with some discussing, and some constructive disagreement to engage in and build from

I really care about this conversation because these issues are hurting people and reducing our efficacy

[simontegg]

@mixmix I believe we agree. Its just putting it on loomio takes a lot energy and forethought that I don't have right now. Before I speak publicly in front of a lot of people I like to try stuff out with a small group to make sure I'm not off my rocker ;).

[rdbartlett]

I'm super stoked this conversation is happening on github. As one tiny data point, @mixmix I never see you on Loomio, so it is bloody great to hear your voice in here. You can share the link with anyone you think would value reading it.

Also I am a big fan of the 'leave things lying around in public' approach to transparency. It's obviously not ideal, but it is far superior to the 'claim to value transparency but never actually have the resources to do it properly' default that runs throughout Enspiral.

[joshuavial]

lol, it didn't click until Richard mentioned it but github would be one of the only digital places to reach @mixmix :)

On 3 June 2015 at 15:22, Richard D. Bartlett notifications@github.com wrote:

I'm super stoked this conversation is happening on github. As one tiny data point, @mixmix https://github.com/mixmix I never see you on Loomio, so it is bloody great to hear your voice in here. You can share the link with anyone you think would value reading it.

Also I am a big fan of the 'leave things lying around in public' approach to transparency. It's obviously not ideal, but it is far superior to the 'claim to value transparency but never actually have the resources to do it properly' default that runs throughout Enspiral.

— Reply to this email directly or view it on GitHub https://github.com/holodex/app/issues/87#issuecomment-108176856.

http://enspiral.com/ Joshua Vial Phone +64 21 684 495 Skype joshuavial Website www.enspiral.com Twitter \ @joshuavial http://twitter.com/joshuavial

[simontegg]

@mixmix

I think the knowledge / experience we might be lacking is knowing what a large scale open source project operates like. what does it feel like, who holds the culture, and where did that come from.

I'm going to open a can of worms here and suggest that successful, open-source, large-scale software development (thus far) is much less about 'holding the culture' and much more about enforcing protocols that work for the neuro-typically male.

Hintjens describes this here and here.

I could extrapolate and speculate that in tasks which require a common collective agency, the increasing presence of neuro-typically female enhances outcomes (cc @dominictarr). But loosely-coupled tasks with a competitive aspect (like open-source software development as-we-know-it) favour the neuro-typically male.

[dominictarr]

Hey who you calling neurotypical?

Since I got @'d into this conversation I'd just like to point out that there are many different open source cultures. Also, beware programmers who write essays. Programmers get very good at coming up with simple abstractions, and sometimes they are too simple... The way that hitjen's talks about "male" and "female" is a great example of that.

Zeromq is a project with a very clear objective (messaging within a data center), another example: implementing a fully compatible unix (i.e. linux) - other times you have projects where the goal is more exploratory or has vague goals... such as a consensus focused discussion platform or whatever holodex is.

My best opensource experiences have been in "high touch" projects where understanding each other and consensus decisions was the norm - generally the opposite of what hitjens advocates.

But, I continue to have collaborative experiences in open source that challenge me as a human. It is surprising to find your self collaborating on a project with someone who thinks in a different way to you...

I don't know what to do in this situation... try to understand them I guess?

[simontegg]

@dominictarr For clarity, I @'d you in because you recently shared the Wolley paper in a loomio discussion, and that's relevant to speculation that different communication styles that work well for one group won't work well for another. Not to label you one way or another :).

Hintjens has advocated C4, but also observes that its not universally appropriate:

in my open source communities, we see very few women, if any. I'm talking specifically about ZeroMQ-style projects which are entirely self-organizing, with little or no enterprise contributors, very few meetups, little forward planning.

The answer is, I'll claim, that we're a community of footballers, not swimmers. Only a certain amount of force can get footballers and swimmers to play in the same team, and the results are usually miserable.

[dominictarr]

Okay well I said my piece about that...

What is this issue really about?

[mixmix]

sigh. I don't like reading walls of junk, and haven't found a good way to triage the relevant from the non-relevant. These days I put my energy into direct chat, supporting people I'm near to, and supporting small projects and that brings people together more.

[simontegg]

In @mixmix's words this thread is about:

how various people are having trouble working with one another in enspiral...and some constructive disagreement to engage in and build from

Its also about having a random controversial discussion of things that I think are relevant to the above in a forum where I'll only piss of a maximum of 6 other people, rather than 100 others if I started it on loomio.

Its not clear what @mixmix means by 'walls of junk' (this thread? Hintjen's blog? loomio discussions? all of the above?) but if he wants to check out and not participate here, I'll happily catch up in person and direct chat.

[mixmix]

the junk comment was me feeling bad about people raising my lack of presence on loomio / other. i was feeling defensive about feeling overwhelmed by large amounts of content + notifications

[rdbartlett]

Sorry Mix, I misrepresented myself if I made you feel defensive. I think your disengagement from some platforms is symptomatic of a problem that is not yours.

On Thu, Jun 4, 2015 at 11:38 PM mix irving notifications@github.com wrote:

the junk comment was me feeling bad about people raising my lack of presence on loomio / other. i was feeling defensive about feeling overwhelmed by large amounts of content + notifications

— Reply to this email directly or view it on GitHub https://github.com/holodex/app/issues/87#issuecomment-108853421.