Chapter 8

TITLE TBC

Dear [whos' the reader of this?],

At the invitation of the ServPub project, we met in London in October 2025 as representatives of Hackers & Designers, Varia, Constant, TITiPI and Creative Crowds, at the occasion of the symposium "Collective infrastructures for Publishing".

At a rapid pace, we presented our various positions and situated explorations in realms such as FLOSS publishing, small-scale hosting, bug reporting, campaigning for cloud abolition, maintaining and developing of collective infrastructures. This quick meeting in London stimulated the desire to create further occasions to discuss about the tools-practices that are shared across groups, collectives, organizations.

We decided then to have a series of less intense and more reflexive gatherings to share perspectives, hopes and grudges of our collective paths, touching on some of the long-term questions that have accompanied our distributed involvements. This gave space to some of the more subtle, complex issues for which there is hardly ever enough time, but that are urgent in face of the increasing precarisation of work and dispossession of the technological landscape.

It is impossible to turn this into a single voice, what follows is a selection of few intersecting themes that came up in different conversations, told via some rough transcriptions and rephrasings of our chats. So, please take the "we" that you have read in this short introduction with a pinch of salt, actually take it as a few different pinches of salt. It's a very variable "we", that does not point to a shared identity, but more different combinations of perspectives that encountered each other and looked for points of contact and of friction.

These notes are thought as starters for further conversations that will be had in the future, reaching out to other friends and allies and others that have not had the occasion to join this "we", yet.

1. promises and traps: wikis, look-a-likes, non-alternatives

[...]

there is something interesting about what are the expectations and aesthetics we are choosing. some styles feel more appropriate to the modes in which we work. instead, in this case there was a layout process before starting the wiki, in which a promise was made of how approximately it will look, made with InDesign. that's because of the workflow in place, where publishers needed to see "something" to approve and go on with the project. and that set a certain direction.

that's the trap of the alternative. you pitch yourself against the industry standard, saying you can obtain something comparable with these other tools, but then you create a stress and expectation on what you need to achieve.

indeed we got stuck on some things like adding quotes in the margins, things that we could do but maybe we would prefer another way, had to be fulfilled. we entered a strange situation in which we had to prove that we knew how to make books.

yes, when you go by html and css, you can choose to work really hard and make it work in a way similar to what you would do with a wysiwyg tool.. but the process works much better when you give up the idea of total control over how something looks, and instead do something interesting by accepting html+css and their rigidity.

[...]

there was an invitation to make a lookalike of an academic journal with wiki-to-pdf. That lead to specific design decisions, like a single column layout because the journal would hardly ever be printed. This, in turn lead to the proposal of symmetrical margins of the layout, as there was no need to keep a spine into account, but asymmetrical margins were requested because the former journal had them. So in that case good design was thought of as being a "good lookalike" of the previous version, even though there were completely different conditions.

[...]

the wiki brings with itself many promises... for example, for the fact that everyone is allowed to read and write, one unsaid promise is that if you leave the wiki open, the interested people will come and write in it, the system will make the work happen!

instead you need a shared interest going on with other people... and even not just in the content but also in the mode of writing. The PrePostPrint wiki is a classic example, where the wiki stays empty, there could be lot of content but there is no collective excitement of writing in a wiki. Now there is a proposal to move it to "w", another small scale cms that some PPPers are already into, and that generated collective excitement.

another promise related with the fact that everyone can read and write, is the one that in the process of making a collective publication the hanging pieces will be dealt with by "someone". Sure, text corrections can be done at any moment by anyone, but who is committing to this work, and when? Editorial work requires an active engagement, it won't come by the platform alone. By working with wiki-to-print systems we have seen multiple examples of the invisibilized work to pick up all the loose parts of the project in view of printing.

Femke has an interesting hunch on how the wiki promises can be tracked back to the Agile Manifesto, published with others by Ward Cunningham, who also developed the first wiki system. The "lightweight" software development methods of Agile, that entangle the software's user into the making and expanding of the software itself, create multiple methods of offloading labour onto future interactions. While we want to oppose that, Cunningham's proposed blur of the reader and writer still resonates with our desire for blurred authorships. But not blurred responsibilities and workloads!

[...]

we are responsible for one promise, the one of wiki to be a to-print environment.

instead, now working with learning palestine, we choose to use octomode. we did not even propose wiki2print...

because the pad is more user friendly than the wiki?

yes, it is more immediate, you don't need logins.

even in the servpub book, for some sections, there is a link to an etherpad for working on the text. as the wiki is not great as a publishing platform, it is strange to use it only for that and not to write there.

as manetta said, when speaking about the XPUB master course in rotterdam, you need an already existent relationship to the system: at XPUB the first thing you do as a student is to get introduced to the wiki, make your student page. Or, at Hackers and Designers we are using a wiki for the website. For us it is not just a publishing tool, it's a way of working and to relate to one another and to the outside world. That grew on us, so it is less of a barrier to choose to use it.

So the wiki makes sense if already part of the ecosystem, and you do not really bring something new, you just add the print... Similarly, etherpad is also odd and not ideal to work on publishing, but if you use it everyday for organising in your group/organisation, it feels more natural to use it, as it is already part of the way you work. If you bring them up with a consortium of academics that are not used to work with them, you can't expect people will be excited about it straight-away.

So if it is not already a praxis inscribed in how you work together, it is a jump to bring it in as a publishing model, like skipping one of few steps. And to work on wikis that are only there to produce a "print", that's also awkward, as in, why are the wikis not really used as a website, too, then?

[...]

2. neighbouring communities, funding effects, who supports who

[...]

When we get money, we normally get it do to activities, not to do books. This mode of working on publications in a certain way also comes from certain funding structures, I think...

What are the sources of funding for h+d?

The main one was stimuleringsfonds, but they changed way they distribute money, organizing it by region, so in Amsterdam there is quite some competition and only one association gets the funding. They also changed from 1-year to 2- or 4-year funding, pushing towards institutionalization, which was something we don't really want. We still got positive advice in the last round but because of budget cuts and the point-system they use we did not get funding. now we are trying project fundings and other paths.

Fucking hell this austerity machine is horrible. And this situation is at odds with the impression you might have from outside of certain groups or collectives being very productive, making good work and having a good attitude, and that's not enough.

And apparently we don't have a rigid enough governing structure for multiple year funding.

We have organised in our own terms, less rigidly, doing the opposite for years and it used to be appreciated, but it isn't anymore.

The reach is always a topic, quantifying your public. And how you are different and better to the other neighbouring projects, having to convince you are the best one in the field.

It is also very tiring this mode of application writing, then you don't get funding three times and you start wondering is all this energy going into this applications worth it?

"Shadow organising" was considered, imagining parallel application proposals and budgets that would not always match each other, with some game in between, but that would mean such extra attention and stress that it can't really work.

In a way it has been a relief not to get big funding and feel freer with our activities, it made space for smaller projects with collectives we like, but of course there is then lot of things then we can't do without that money.

[...]

Many web-to-print workflows now include the javascript library paged.js, which recently lost its financial support from the Coko foundation. So the developers had to rethink how to continue, and how to fund the project. And that impacts many communities: if pagedjs went away, a lot of web-to-print publishing systems would have to re-invent themselves... There is a fragility here that is not about the code - it is about funding and who can maintain parts of infrastructure.

This is not the first time that such a situation happens: there is the risk of repeating the CSS regions drama, where a Chrome update all of a sudden removed a functionality that was extensively used by Open Source Publishing and others to layout using web-to-print, making it impossible to continue a certain practice of browser based layout that had been developed for years, reamining locked on an old unmaintained version of Chrome.

Paged.js is now teaming up with another web-to-pdf project, weasyprint, and with Julie Blanc, but with a financial plan for a year to work on code and standards. It is very clear it is a matter of survival for practies the need to engage "higher up", into where the code is developed (through Paged.js, first Julie Blanc, Julien Taquet, and now Julien + Fred + Gijs are taking the project further), but also into where css rules are defined, or finding ways to speak back to standard making.

And it should not feel an impossible struggle just because of the power unbalance. A super exciting example of how it is possible to speak back to standards and act from the ground up, is the QUNI (Queer Unicode Initiative) project of Bye Bye Binary, which "recouped" unused parts of the Unicode Table to make a queer standard-in-the-standard.

[...]

3. experiments, less-negotiables, pilots

[...]

in the end the book had to be completely reprinted, the fading shade did not come out as expected, and immediately the publisher assumed the experimental tool was responsible. That was super stressful, put a lot of pressure on hackers and designers, considering us irresponsible in our practice... and then in reality it was the printer's fault. we received an apology but that was definitely not enough."

it seems that if you bring an experimental tool, or anything that moves away from the 'industrial standard', really, you will always be the first suspect when something goes wrong. As if the proprietary tools never had quirks that workers had to work around. So the bar for the experimental tool is set even higher, absurdly."

[...]

that seem to relate to "things you don't fuck with". financial matters, infrastructure. there's some unspoken rules where institutions, but sometimes also smaller groups get rigid.

we want to keep a diy spirit, do we want everything to be experimental all the time? Like with the financial, there is many hesitations. It can be risky, so we choose the areas where we want to be professional.. and experiment in other areas.

and the same could go with including more people with sudo access to the server. But for infrastructure the strategy for us is taking care not to leave only one person responsible. As there was a bad case of fully lost backup from the server, where the person responsible felt very bad about it...

[...]

the experiment is in itself a "promise"

a promise of being able to develop and learn a process together at the same time, a promise to experiment with things unstable and open-ended, not having to deliver something, testing out without knowing fully where this is going.

this is opposed for example to a "pilot project". Like the pilot project is a pilot for something. So it already knows where it tries to go, what it tries to do, to demonstrate, the promise of opening a field, of changing one. Like for example, academic publishing, in the case of servpub. It is more difficult then to allow cross-disciplinary experimental collaboration ( a bit of a missed opportunity to try something more radical )

[...]

4. institutional tunneling and elastic solidarities

[...]

so the server went down because it was hosted on a pi at someone's house. Why a pi and why someone's house?

we have our infrastructure distributed on few different machines, but the dns points to a rapspberrypi at my house. from there the tinc vpn tunnel goes to the other machines.

why the tunneling?

we wanted to host our own things, but here at the NDSM we have no control over the infrastructure. we had to find a way to tunnel out, I have a static ip at home, so that was the way. It's in the utility closet with a lock. It has nice side effects, for example when working on a solar powered travelling server, we could use the same exit while being on a 4g network.

one machine is at the rijks academie.

is it a coincidence that it is there? like it has a connection to the infrastructure of the school?

it just uses the internet.

there is no deeper symbolism

cos I was thinking, instead, the titipilocal server in switzerland, poses the question: what does it do in the network? the local server praxis is part of the research, and it felt important to be recognized by IT and management. And then you are also inside the institutional firewall, with different resources, access, conditions. what does tunneling and different topologies do, can you fold different networks/conditions/ with each other?

[...]

one thing kept hanging from the conversation about the server. Thinking about Recurring technologies and imaginaries — the Trojan Horse, included in the belly of the enemy. Can we discuss differently the inside/outside of established localities? We cannot afford to repeat the Trojan Horse political thinking. The definition of the local is beyond the outside-inside binary. What political thinking we want to unfold that is not so rigid? We theoretically celebrate elastic solidarities, but how do they get computed?

What does elastic mean?

The tunnel, how does the gesture of tunneling be cultivated, practiced, sustained, not through a computational imagination, not through the metaphors of wall, etc, beyond what we have on our table now.

[...]

outroduction

The rephrased and loosely recollected notes above constitute the beginnings of conversations that we want to continue in the future. In the gatherings, other tracks and questions emerged that felt just as intuitions for now, but that started to take up collective attention. Here are a few.

Many of these shared collective infrastructures are there because of financial support, organisational and collective energies. How do we fund our collective work? Are there ways around/through/beyond funding bodies to make space for development of publishing infrastructure that can evolve slowly in relation to other ways of working?

It is becoming more and more difficult to love digital tools, amidst constant onlineness under the cloud regime. How to position ourselves in face of the recuperation of free-software practices, the emptying out of a lot of its political value, the extraction and dispossession of ways of doing and organizing, funneled into cloud platforms. How to move away from the "alternative" mode of understanding free software, into a "transformative" one?

Clearly, there is value in collective work, with all of its messy entanglements. There are certain frictions we are intentionally engaging with, around transdisciplinary collaboration, borrowed infrastructures, resistance to Big Tech and ecologies of shared practices. While this work is often situated "outside" of, or adjacent to academia in a "grassroots" position, we often encounter individuals from "inside" who are interested in collective work. What happens when the values of collective work meet academic research cultures that are still centered around individuals? How do frictions translate (or fail to translate) to larger-scale contexts, where organisational structures are more vertical? And how can we move past the binary of "outside" and "inside" academic structures?

These questions come up sometimes, when we run into each other, grabbing moments to discuss over bites to eat, between worksessions and meetings. These are usually chance encounters that we always hope could be more extended. We want to make these less accidental discussions in the future, and we also hope to bring more people into them. And dear reader, who has been closely following this text, we hope to also meet you in one of these conversations, perhaps in a quiet, relaxed setting, over a cup of tea? To think together, and further extend and blur this "we" that has accompanied this text.

- By various members of Hackers & Designers, Varia, Constant, TITiPI and Creative Crowds