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 https://discourse.transformap.co/.
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
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
- patient and
- restless and
- passive agressive
expressions to simply
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
over an experienced overcomplexity of the case.
The psychosocial and cognitive relationsships emerging from these conditions range from
- offering and
atmospheres to those of
- abusive or even
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:
- money and
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.
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
- the ineffectiveness of ad hominem arguments to build a collective effort,
- 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.
- 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:
- 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
- a taxonomy process which happens undocumented and behind closed curtains is of no use to the Public Domain
- 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.