This is a list of things that could sprout slowly toward the next year. For the bachelor I struggled a lot to choose a specific topic: deciding on something is really difficult when everything is so entangled. To approach next year in a different way maybe could be helpful to keep track of some ideas and try to understand why they trigger me.
BTW at the moment it's just a list of things that come to mind while playing basketball.
- The three SI as case studies. Try to formulate them in terms of critical tooling - community software - site specific software
- [Eventual Consistency](https://diversions.constantvzw.org/wiki/index.php?title=Eventual_Consistency), the case of [Y.js and Joseph Gentle](https://www.youtube.com/watch?v=0l5XgnQ6rB4)
- "The crisis can be solved only if we learn to invert the present deep structure of tools; if we give people tools that guarantee their right to work with high, independent efficiency, thus simultaneously eliminating the need for either slaves or masters and enhancing each person’s range of freedom. _People need new tool to work with rather than tools that “work" for them._"
- The Piet ? What's the difference between sharing the tools developed in the context of xpub (si16, si17, xbranch, soup aggregator, karaoke, aggregator, wiki api etc) & propose a collab tailored on the need of the piet ? (both things can cohexist)
- Knowledge system vs screening of dataset - [Ron Morrison - Decoding space: Liquid infrastructures](https://vimeo.com/showcase/5551892/video/306993793)
-`El rumiante apuesta por un ejercicio de **invención política** que es colectivo, siempre. Procura darse, para sí y su comunidad, herramientas, y entiende que estas herramientas no son algo a lo que se llega, sino que están en constante construcción.`
- [Epistemologia Rumiante](https://hysteria.mx/epistemologia-rumiante/), from Camilo & Maria 's workshop
- [Nicolas Malevé, “The cat sits on the bed”, Pedagogies of vision in human and machine learning.](https://unthinking.photography/articles/the-cat-sits-on-the-bed-pedagogies-of-vision-in-human-and-machine-learning)
- bell hooks, Theory as a liberatory practice (in: Teaching to transgress)
There is something different in how we do create tool for ourselves, and how we do create tool for others.
See [GRS](../grs) for an intro about this.
### Coding contingencies
> Code is always addressed to someone. [...] We do not write code for our computers, but rather we write it for humans to read and use. [Jesse Li (2020)](https://blog.jse.li/posts/software/)
Coding is not just production of software, but also production of knowledge. A dialogue between human and more-than-human actors. The guestlist of this conference of the bits is often compiled by chance: the choice of a particular programming language, the coding style, the development environment and ecosystem, the infrastructure that runs the code, and so on, are the result of specific contingencies.
These contingencies are situated in precise contexts, and these contexts are different one from another. Programming is not just sharing code, but sharing context. It's to provide a point of view and a perspective to look at the world, before attempting to get some grip onto it with a script. That's the reason why even if source code, even when obscure and obfuscated, speaks for itself, it cannot always cast light around its surroundings. To make place for the code turns to be a necessary act of care in the process of sharing knowledge.
<!-- next paragraph has potential but like this is a no -->
Code ages fast. Because it moves at lightspeed into fiber optic cables, its tempo flows at a total different pace compared to the velocity of our cultural daily life.
What kind of resources, experiences and approaches constitute this practice?
Research how writing software changes depending on the context and actors involved. Bring the specificities of different case studies: coding for oneself, coding for others, coding together with others. How can different nuances of these three settings inform and resonate one with the others?
Elaborate on the idea of care. Care for who and in which way? Care for what and from which perspective? Lay out these different subjects and annotate the ways they interact, reinforce, or dampen each other. Where and how to orientate software development in this chart?
Try to make a public for this practice in subtle ways: how to offer entry points for (or escape routes from) the stereotypical western white male macho programmer? Is it possible to infiltrate the ultra efficient and violent industry of software development, seasoning its own tools? How to intercept some established practices and branch from them? How to publish outside our safe XPUB bubble?
---
There are three main nodes in the graph of this project. Writing software, taking care, and staying low.
Writing software and taking care are meant to be moments of research and curation of contents in the form of resources, experiences and approaches. Starting from the assumption that there is no universal solution for writing software, and that coding is always site specific, this research could set some coordinates by looking back at the works made last year and analyze them through the lenses of code and care.
Along with this initial reflection on the first year, the plan is to focus on three case-studies of different nature. One in which I develop for myself, one in which I develop for someone else, and one in which I develop together with some others. These projects will not start from scratch, I
Developing for myself could happen in the context of [Object Oriented Choreography](../ooc-summer-session/), a long-term contemporary dance research with VR and networked media. The team I'm working with for this project is small, and I'm the one in charge of the art direction and interaction design.
Developing for someone else refers to commisioned and freelance work. It could be a way to bring not only the advantages, but also the perspective and cultural dynamics of F/LOSS into commercial practices. My freelance work usually consists in developing websites or interactive application to be used in performative context. It could be a way to orientate specific commision to the development of tools of general use.
Developing togheter with others it's a way to renegotiate priorities when developing software. How do we value and balance between accessibility, flexibility and sustenaibility? This could happen either collaborating with someone from XPUB (think for example to the [workbook](../workbook/) with supi, the ilizarov projects with gr, etc ) or intercepting some external realities' need to craft together some piece of site-specific software.
And viceversa. Undocumented software is invisible, but for the eyes of their own developers. And eventually, it begins to fade as soon as the developer looks away.
