Statement regarding Transformap for the SSEDAS partners present at the UniverSSE conference

(Jon Richter) #1

TransforMap is a collective of voluntary cartographers which aim at visualising the alternative economies. The group is building an ecosystem of Transformaps initiatives and Intermapping processes by commoning its in- and outputs to the Public Domain. The community can be reached at

SSEDAS is a european research project¹ which produces SUSY (SUstainability and Solidarity economY?). It has embarked a joint venture with Get Active e.V. (Austria) to build mapping components for the TransforMap ecosystem, which are generally usable to present the SUSY Map.

¹ citation needed

Ethical guidelines

Many activists from TransforMap share an academic background in emancipatory sciences, which includes experience in action research, critical social studies, political ecology and human geography. As such a high degree of abstraction is involved in shaping the collective imaginary. Opposed to the non-less abstract logics of engineering practices. Bringing the two together is the holy grail of software engineering, denoted in the duality between developers and users.

From the levels of personal interaction to the long-term impacts of reified relationships, the process of enliving a community is inherently social. This involves coping with personal tones that range from

  • quiet,
  • friendly,
  • unconditional,
  • patient and
  • kind


  • busy,
  • restless and
  • passive agressive

expressions to simply

  • rude

appropriation of shared moments. Unfortunately here we need to focus on the impact of business and restlessness the quality of contributions of maintainers and managers alike, talking of their ability to concentrate sufficiently on their subjects, to be able to answer the question how design and implementation procedures are mediated within the team, and to the outside.
Unintended side-effects can materialise as signs of

  • permanent emergency and
  • exhaustion

over an experienced overcomplexity of the case.
The psychosocial and cognitive relationsships emerging from these conditions range from

  • unconditional,
  • offering and
  • enabling

atmospheres to those of

  • restrictive,
  • abusive or even
  • addictive

quality. Abusive in the sense of consciously and uncritically using inherited power by Get Active, and addictive in the sense of complying with these conditions by Ecobytes, but more on the details below, as we also need to carefully distinguish the psychological effects from the processual design in working with money for a greater good.

This context is to be considered when following the later argumentation. In general the main argument of the Commons and associated Commoning procedure is the collective control of access and access rights to, but not only, shared resources. For this deliberation we see them in form of:

  • infrastructure,
  • money and
  • information.

Means of production

Primarily, when in the attention economy of the information age knowledge becomes the main source of power, its redistribution and control of access become predominant factors of political emancipation. Narratives on the world wide web, where we are working, are often presented as either series of conversations, or pages of documentation.

Where the first relies on subjective modes of narration and imposes identity to the discourse, the second reliese on collective modes of narration which revieal plurality of the discourse. In a meta perspective, the power relation to deconstruct here is the one between access to peers in a process, and access to knowledge produced by that process.

Secondly, we operate within the constantly evolving environment of computation, which has high demands in terms of investment needed for development, maintenance and communication of infrastructure. This happens mostly invisibly and is at the core of a working environment.

The uncertainties known from the practice of software development processes lead to the emergence of open source and agile methodologies. These have great influence on the development practice, but also on the estimation and evaluation of future developments. Rufus Pollock, president of Open Knowledge, put this nicely into words last summer:

Alter procurement methodologies to favour agile approaches over “spec and deliver”. Specifically, current methodologies follow a “spec and deliver” model in which government attempts to define a full spec up front and then seeks solutions that deliver against this.
The spec and deliver approach greatly diminishes the value of open source - which allows for rapid iteration in the open, and more rapid switching of provider - and implicitly builds lock-in to the selected provider whose solution is a black-box to the buyer.
In addition, whilst theoretically shifting risk to the supplier of the software, given the difficulty of specifying software up front, it really just inflates upfront costs (since the supplier has to price in risk) and sets the scene for complex and cumbersome later negotiations about under-specified elements.
Instead, create an agile procurement stream in which, rather than detailed requirements being set up front, you secure estimated budget for an initial phase and seeks bids on X number of sprints (with ability to end after any sprint). This model requires acceptance of some budget uncertainty: the total cost of delivery of software may not be fully known in advance. However, one can, alternatively, fix a budget and accept some uncertainty over features delivered. We emphasize that this limitation is not a limitation of open source but of software in general. As the maxim goes: in software development you can have any two of features, time and budget – but not all three. Traditional tendering with its fixed requirements, fixed timeframes – and implicitly fixed costs – exists in an illusory world where one can have all three and implicitly imagines that buying software is like buying traditional goods like chairs whose features, usage and cost are all well-known up front.

via Rufus Pollock: Why Open Source Software Matters for Government and Civic Tech - Agile Procurement
via Resources about Tendering and Open Source Procurement

The discoursive frame may be juxtapositioned by the terms cooperation and collaboration. Cooperation can be seen as the mode of interaction of paper institutions, such as joint ventures between corporations, where collaboration can be seen as the mode of interaction of web communities, such as digital commons which emerge by the voluntary contributions of strangers.

Both forms of process imply certain roles for participating individuals, which have great influence on the negotiation of normative questions, condensed in the dichotomy between setting rules and designing regulation, which produces rules.

This duality continues within the analysis of a process’ temporal regimes and its understanding and design of temporality:

  • Within a process-oriented regime, uncertainty is considered an inherent category, next to an understanding of the importance of documented training of peers and a work mode of trust, which makes up for the amount of voluntary engagement needed to reach the aim.
  • Within a product-oriented regime, that operates deterministically and claims full knowledge of all involved factors, planning procedures allocate resources ahead of time and fail in adapting to sudden changes, the social capital of its precarious workers is drained and used for the benefit of clients and surveillance mechanisms and rhetorics are in place to impose an external will to the workers.

Subsumingly, the question of access to available development resources, in form of allocation and redistribution, is detrimental for generating living ecosystems. The idea of implementing this in a solidarity economy, which inherits Care and Justice debates, provides a political framework to reference when reflecting the actual practice.

Critical evidence-based ontogenesis

In following on with an argument I had written for the ecobytes context in an essay about Ontogenesis & Procedure

While there is no single truth about how to run web services, nor how to develop them, we are aware of exemplary patterns. Further on, an understanding of technical processes as being inherintly social makes us focus on the techno-social architectures we are building: Not only do we create software for users, but, as maintainers, we are also human beings after all. Hence the practice itself turns into an object of learning and adaptation.

Unfortunately more than often it is time for a change, but no time to change: Existing habits within a team are deemed good enough for now. In the same time resource and knowledge constraints limit projections of the future to the already known and comforting. Where changing one’s own practice means to kill your darlings, resistance to the new and unknown is likely to be inevitable. How can we approach this paradox?

“making the problem the focus instead of the solution”

As humans our situational capacity to perceive, know and react is limited. Engaging in collective processes helps us to highlight and overcome these limitations. Yet over time we equip ourselves with tools and techniques applicable in varying contexts. Up to the point that only those techniques appear valid to solve a given problematic, which we already understand and presumably control. The solution becomes a first-class citizen, while the actual, problematic situation fades back.

The more we stick to and defend a habitual pattern, the more likely it is error-prone and self-validating. To get it out of this vicious circle, it can be advisable to take a step back and reevaluate the originating contextual forces next to known applications in the wild. What we will find is a fine-grained depiction of the reasons why a solution was favourable in a given situation. Therefore the formulation of the given situation determines a lot in which domains of knowledge we allow our minds to crawl for extended contextualisations and possible reactions.

we can choose if we want to remain in a dualistic opposition of a priori sabotage of each others plans, or if we can move to a more collective hermeneutics that acknowledges also for a necessary a posteriori repair of damage and harm. This involves a personal and collective perspective, too.

On the personal level, we need to agree on

  1. the ineffectiveness of ad hominem arguments to build a collective effort,
  2. the inutility of complaining about complaints without referring to their thematics, i.e.
    • questions of budgeting, allocation and distribution of resources
    • not in terms of quantitative proportions, but in terms of qualitative dimensions of regulatory, administrative schemes in shape of power relations and combining dispositives.
  3. the ostracism of holding back money and using not paying as pressure to impose an agenda

Collectively the main culprit is still the relation in which CHEST and SSEDAS started. Where the first intended to carefully explore needs and means of development, the second already pushed requirements into the process, which were not fully understood, yet. The avoidance of a public #16mmm process and substitution of participatory design elements with top-down reporting, and maintenance difficulties inferred from the stability of ecobytes as an association and infrastructure, are only two examples of the external entropic and negentropic forces which apply.

It is important to understand here, given the previous flow of words, that we still must collectively resolve what began as a continuation of previous paternalistic interventions during SOLIKON 2015. Namely, we must at least adhere to these conclusions:

  1. mediated negotiation is insufficient to represent actual needs
    • proxied communication with involved parties leads to a loss of detail and often even direction of represented arguments
  2. a taxonomy process which happens undocumented and behind closed curtains is of no use to the Public Domain
  3. we now have an improvised, instead of a crafted architecture, which imposes a high amount of technical debt as legacy technology, which in turn produces higher maintenance cost due to earlier process deficiencies.

Naming these deficiencies will be key to resolving the issue of exploitation of a Commons for private interest.

necessary adaptation to reinforce the commoning process
Concluding three years of prototyping
(Silke ) #2

Jon writes a very dense and highly analytical assessment about the “tensions” between the commoning approach of Transformap and the project-driven/service providing approach of SSEDAS.

I fully support his conclusion:

While Jon uses the metaphor of entropy (pointing to the irreversable forward process of gradual decline and dissipation), I’d put it that way:
When SSEDAS started a partnership with TransforMap, TransforMap began to die.

I could not yet figure out how to deal with this, as - in contrast to what Jon describes as a a “as digital commons which emerge by the voluntary contributions of strangers” in Summer/Autumn 2015 TransforMap has become a online-offline cooperation/collaboration of people some of them strangers to each other, others have become friends. This community got lost. What remained is a “digital one of strangers” which tends to insist on a certain communication culture which is not accessible to all. And this is another problem, but the minor one.

(Josef Kreitmayer) #3

@almereyda please correct the beginning of the satement, that it clarifies, it is based on your personal perspective, and not reviewed in any kind of consensual process.

I would acutally sit down to report more from the SUSY-Partners meeting, where I was just invited to have 2 hours of going through the map, and see, where it would / could go, also describing some of the challenges we have alltogether, but I am now for lunch with the fouder of Impact Hub Athens, a friend from his time as intern at Hub Vienna.

I will commence later.

(Jon Richter) #4

No need to manipulate the discourse further, it’s already attributed by me. For shared posts we are using the @transformap identity.

(Josef Kreitmayer) #5

thank you for calling me on the tender today. Really apprechiated hearing your voice, how everything you engage with unfolds, and how you get stuff moving. Respect.