Producing digital commons with an Erlenmeyer flask

Tags: #<Tag:0x00007f9f0c13afa8> #<Tag:0x00007f9f0c13ad50>

(Gualter Barbas Baptista) #1

The figure presented below is a proposal for an institutional model for socio-technical commons production and management. It emerged from intense exchange with the @Scrumteam1 at Berlin, reflecting on the multiple institutional crisis of Transformap and the difficulties faced by the team.

The model is based on a communication/operations triangle between the community, administration and production teams. The cherry on the top, in this case specific to the digital commons (but probably finding parallel in other contexts), shapes it like an Erlenmayer flask:

                              Development & Operations  
                                      |      |          
                                      |      |          
                                    /  (teams) \        
                                   /            \       
                                  /   \      
                                 /                \     
                                /                  \    
                               /                    \   
                              / GoogleSS   Discourse \  
               Administration ----------------------- Community
              (organisations)                         (circles)

In short:

The community can be considered any person and organisations with a vested interest or stake in the Transformap commons. In terms of organisation, it has been structured as circles, following a sociocratic approach. The community is a discursive sphere, one of exchange of knowledge, sharing of ideas, outlining and alignment of visions, political construction. Currently, its central point of communication is discourse, with selected information being also shared on mailing lists.

Administration are the organisations acting as an interface to funds and basically doing the paperwork, currently Ecobytes and Get Active. The administrative sphere supports the provision and management of resources needed by the community and the production teams. If businesses are in play (which is an interesting discussion that can extend from the discussion on how to separate commons and commerce), they would also find their position on that corner. Currently, information from the administration, especially regarding budgets, are mostly concentrated on Google Spreadsheets (since a few months publicly accessible and linked to from discourse posts and community reports).

Production is represented by what we have often called the “scrum team”. The scrum process was proposed to provide a further layer over the circles structure, engaging a multi-skilled team in an intense process. Because production teams are paid, they have a more intensive pace, which leads to challenges on the establishment of sane communication, workflows and decision-making with the community. The production team organizes its work on taiga boards, following an agile approach.

On top of it, development & operations describes the diffuse ecosystem of people doing (tech) development and putting together different pieces of free software, to which the production team attaches to. While the production team consists mostly of contracted personnel working part to full time over a few months, additional developers will be subcontracted through the upcoming buckets system.

This is work in progress, comments appreciated.

Community meetings 2016
Leave it to the user: collectively shaping taxonomies to express plurality of narratives
Separate Commons and Commerce to make it work for the Commons
Community Report #2: 14 April 2016
(Jon Richter) #2

2 posts were merged into an existing topic: Using co-budget for allocating resources

(Jon Richter) #5

I like this scheme as it includes a nice triage which allows to approach our discourses from different perspectives.

What I don’t like about it is its naming, as the form appears to be randomly extended on the production side.
Let’s not consider this a closed small-world network, but just different analysis vectors of the processes which are going on anyway. Following this argumentation, there is no generalising need to abstract this process as a model for CBPP (which is, by the way, an abbreviation that is nowhere explained or referred to in the text).

Additionally, this way of scribing the TransforMap discourse completely negates the research vector and unwrites it from ongoing conversations, which I am heavily critical about.