kamo-soupbato

kamo

kamo-soupbato

You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

9.0 KiB

Raw Blame History

Draft Project Proposal

What do you want to make?

Writing software as a form of care instead of a form of control.

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?

How do you plan to make it?

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, 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 with supi, the ilizarov projects with gr, etc ) or intercepting some external realities' need to craft together some piece of site-specific software.

What is your timetable?

October Define practically a method for the methodology: think about protocols and possible formats for graduation project outcome. Define the premises in which to ground the three projects by revisiting first year projects. Draw a political compass of software as care. Get in touch with different communities for case study 2 and 3.

November Work on OOC, preparing for December performance at NaO Festival, Milan. Develop context and prep-works for case study 2 and 3: plan timetable. Get in touch with key figures to interview for research.

December OOC performance and follow-up about findings for the methodology.

January Start working on case study 2. Start working on case study 3.

February Work on one case study. Update protocols and possible formats for graduation project outcome.

March Work on the other case study. Update protocols and possible formats for graduation project outcome.

April Follow-up about findings for the methodology. Production for methodology outcome.

May Production for methodology outcome. Production for graduation exhibition.

June Graduation exhibition. Party

July Siesta

Why do you want to make it?

This is a list of current trends that the software industry enforces and naturalize.

Software comes from a really specific occidental cultural tradition. Software tends to priviledge masculine, binary, exploitative and extractive practices. Software is shrouded in technical obscurity. Software comes invisible, transparent, neutral. Software models the world in order to control it.

To make software means not only to write code, but also to take a stance regarding this trends. With this project the intention is to situate my practice within ethical yet sustainable boundaries.

Who can help you and how?

I would like to interview some artists with programming-related practices to get some glimpse of their workflows. I'm thinking for example to Nathan Sinigalia, Ian Cheng, Nicolas Maigret. I want to ask to Ariella Vidach A.i.E.P. how working with technology changed in the past 30 years. I'm interested in the workflow of radical studios such as Open Source Publishing but also more commercial ones like Forensic Architecture and Studio Moniker. For sure it would be interesting to get in touch with someone mantaining open source projects such as Paged.js, P5Js, vvvv, or more unconventional ones. Some interesting things could emerge from field research directly in git repositories, issues and wikis.

The practical aspect depends on the second and third case studies. There are some communities I would like to work with: Pietre Parlanti is a non-profit association that works with the recovery of old routes and cultural heritage in Liguria, Italy. I'm already in touch with them for Frana Futura, the documentary I'm working on with Sofia, Elena and Micalis.

Relation to previous practice

Relation to a larger context

References/bibliography

software studies - ed. matthew fuller
close to the machine - ellen ulman
ways of being - james bridle
new dark age - james bridle
cuttling code - software and society - adrian mackenzie
gay robot noises - comfy software
kent beck - wiki.c2.com
extreme software & SCRUM
simon yuill
The Social Structure of Open Source Software Development TeamsTeams(2003)
Nelly Oudshoorn, Trevor Pinch, eds. How Users Matter
Ron Eglash, Jennifer L. Croissant, Giovanna Di Chiro, and Rayvon Fouche, eds., Appropriating Technology: Vernacular Science and Social Power.
Towards the Sixth Level in Interface Design: Understanding Culture
The Social Shaping of Technology Paperback, Donald MacKenzie (Editor), Judy Wajcman (Editor) (1999)
Visualisation and Cognition: Drawing Things Together - B. Latour
www.literateprogramming.com - Donald Knuth
Donald Knuth, The Art of Computer Programming
Lucy Suchman. Plans and Situated Actions: The problems of Human-Machine communication
Soenhke Zehle, 'FLOSS Redux: Notes on African Software Politics'
Verran, Science and an african Logic
Balibar, Universality, Ambiguous Universality
John Law and Annemarie Mol, Complexities: Social Studies of Knowledge Practices
Cecile Crutzen, Giving Room to Femininity in Informatics Education
Cecile Crutzen and Jack F Gerrissen, Doubting the OBJECT World
P. Béguin and P. Rabardel, Designing for Instrument Mediated Activity
Wendy Hui Kyong Chun, On Software, or the Persistence of Visual Knowledge
Matthew Fuller, Behind the Blip, essays on the culture of Software
N. Katherine Haykesm, My Mother was a Computer
David Toop, Growth and Complexity, Haunted Weather
Leo Brodie, Thinking Forth
Brian Cantwell Smith, On the Origin of Objects
Bruce Sterling, Shaping Things
Timothy C. Lethbridge, Susan Elliott Sim, Janice Singer - Software Anthropology: Performing Field Studies in Software Companies

9.0 KiB Raw Blame History