expose_the_seams.mdwn (3494B)
1 Seamlessness in software obfuscates inner-workings and is a myth: things are 2 only seamless to those who fit an idealized standard. To complicate things, 3 software vendors often use the term "transparency" when in fact still designing 4 interfaces in which underlying processes remain hidden to the user. However, 5 making a technology appear transparent or seamless to users, can become an 6 obstacle to understanding how it works, to critical engagement, and to 7 knowledge and skill sharing. Obfuscating inner-workings makes it harder to 8 question and challenge a technology. 9 10 Exposing some of the inner-workings of infrastructure is essential to making it 11 tangible and to help understand meaning, motivation and materiality: **why has 12 it been implemented this way? How much energy does it use? What processes are 13 happening in the background?** Showing the seams is important for decision 14 making about computational processes: are they really needed? How often and how 15 much resources should they be allowed to consume? Who needs access? Who can 16 repair, stop or restart it? 17 18 Not everything needs exposing however. Although this principle doesn't concern 19 personal information, it can be confused with the call for full transparency 20 which is considerably dangerous to some and undesirable for most. 21 22 23 What can YOU do 24 --------------- 25 26 **With or without a computer** 27 28 * Try to spot and critically reflect the "idealised standard". We can politicise and make visible choices that impose rigid frameworks designed to force us to fit certain standards and choices as a problem. **Ask yourself: who is discriminated against by the idealised standard implemented in the design of things, and how can I mitigate this issue?** 29 * Aim to create solidarities with those who suffer from not fitting the preimposed standards and must to perform extra effort to make [[crappy everyday tech]] infrastructure "work". Identify and question "seamlessness" wherever it prevails and raise awareness about this persistent myth. 30 31 32 **When creating and maintaining software, digital tools or infrastructure** 33 34 * Share your projects' source code, blueprints, and design philosophy. Keep in mind that openness alone is not enough, and can even work against the interests of your community. See [[FLOSS]] to learn more about the position of permacomputing in relation to the digital commons. 35 * Show the inner-workings whenever possible (different technical and non-technical parts of a project). 36 * Don't automate every aspect of a project to keep knowledge about how things work available to non-experts also. 37 * Sonify or visualise "background" processes that take computational resources but aren't part of an interaction. 38 39 40 Principle in Action 41 ------------------- 42 43 * Rosa server from the ["A Traversal Network Of Feminist Servers"](https://systerserver.net/ATNOFS/) project. Rosa exposed seams, refused to automate everything, showed different parts of the server, and also sonified some processes. 44 * Run a traceroute with someone curious about how Internet works to show the many hops and countries a data packet traverses, the Internet Exchange points in between, the materiality of digital data. Also discuss why some organisations purposefuly refuse to reveal their internal networts by configuring their routers to not respond to traceroutes. 45 46 47 Resources/Links 48 --------------- 49 50 * [The writing of the Cell for Digital Discomfort](https://archive2.bakonline.org/prospections/cell-for-digital-discomfort-annotated-bibliography/)