Seamlessness in software obfuscates inner-workings and is a myth: things are only seamless to those who fit an idealized standard. To complicate things, software vendors often use the term "transparency" when in fact still designing interfaces in which underlying processes remain hidden to the user. However, making a technology appear transparent or seamless to users, can become an obstacle to understanding how it works, to critical engagement, and to knowledge and skill sharing. Obfuscating inner-workings makes it harder to question and challenge a technology.

Exposing some of the inner-workings of infrastructure is essential to making it tangible and to help understand meaning, motivation and materiality: why has it been implemented this way? How much energy does it use? What processes are happening in the background? Showing the seams is important for decision making about computational processes: are they really needed? How often and how much resources should they be allowed to consume? Who needs access? Who can repair, stop or restart it?

Not everything needs exposing however. Although this principle doesn't concern personal information, it can be confused with the call for full transparency which is considerably dangerous to some and undesirable for most.

What can YOU do

With or without a computer

  • Try to identify the "idealised standard". We can politicise and make visible this exclusive choice as a problem.(still not clear?) Who is discriminated by the idealised standard implemented in the design of things?
  • Aim to create solidarities with those who suffer from not fitting the idealized standard and must to perform extra work to make crappy everyday tech infrastructure "work". Identify and question "seamlessness" wherever it prevails and raise awareness about this persistent myth.

When creating and maintaining software, digital tools or infrastructure

  • Share your projects' source code, blueprints, and design philosophy.
  • Show the inner-workings whenever possible (different technical and non-technical parts of a project).
  • Don't automate every aspect of a project to keep knowledge about how things work available to non-experts also.
  • Sonify or visualise "background" processes that take computational resources but aren't part of an interaction.

Principle in Action

  • Rosa server from the "A Traversal Network Of Feminist Servers" project. Rosa exposed seams, refused to automate everything, showed different parts of the server, and also sonified some processes.
  • 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.

Resources/Links