Chapter 4b: Public: FLOSS Design

wiki4print(ing)

2+to=4/for

to from Creative Crowds' wiki-to-print

2 from Hackers and Designers wiki2print

4 as it is what the wiki is for

for as it is the fourth iteration since TITiPI's wiki2pdf

Creative Crowds' wiki-to-print is a web-to-print collective publishing environment. Content written into the wiki is used to lay out and design a PDF directly in the browser using web technologies. It is based on MediaWiki software, Paged Media CSS techniques, and the JavaScript library Paged.js. Wiki-to-print, wiki-to-pdf, and wiki2print are not stand-alone tools, but elements of "a continuum of projects that see software as something to learn from, adapt, transform, and change." Creative Crowds' wiki-to-print software is installed on the Servpub Raspberry Pi, a "version" of wiki-to-print that we called wiki4print. We have been using wiki4print to write, edit and design this book. In this chapter, we trace some of these histories and how we came in to contact with them, being shaped by and shaping these practices.

"Using wiki-to-print allows us to work shoulder-to-shoulder as collaborative writers, editors, designers, developers, in a non-linear publishing workflow where design and content unfolds at the same time, allowing the one to shape the other." – CC

In-grid wiki-to-print(ing)

The design work for the book was carried out primarily by members of In-grid. When the ServPub project began in 2023, none of us were particularly familiar with the technical setup of wikis or computational publishing using Free Libre and Open Source Software (FLOSS). Although we are computational artists and web developers, as design practitioners our reliance on the Adobe suite – featuring a toolset tailored for print and digital publishing – had to be reconsidered. Thanks to Creative Crowds our first encounter with web-to-print practices was during the wiki4print collaboration for the Content/Form newspaper. In-grid has since been on a journey of working with the constraints of open-source design: learning how to bridge web development practices into the domain of design for print, and working within the ecologies of FLOSS.

As Creative Crowds said to us, it is quite radical to have wiki-to-print as our first step into the world of web-to-print and working with wikis. Johanna de Verdier, the ServPub book designer, mentioned frustrations while learning to use wiki-to-print – such as being "unable to streamline design the same way as you would have been able to with the Adobe suite" and the "lack of being able to mock things up visually" in the same way. Working within an ecosystem of design software dominated by Adobe, the designer becomes a user of a suite of tools that provide graphical user interfaces for visual design in prescriptive ways. It is from this context that the idea of design software as an isolated tool can begin to be questioned, where we begin to move beyond that determinate scope and its sedimented background.

"Calling wiki-to-print a practice indicates that it's more than a production tool" – CC

During a conversation with CC, they explained that it's difficult to talk about wiki-to-print in a general way, as it was unfolded from particular technical and social relations. They explained that calling wiki-to-print a "tool" flattens the socio-technical practices involved in its creation. From In-grid's own unfolding of wiki4print within the ServPub project it has offered us much space to reflect on the ongoing relations and practices that have emerged within the writing and design process of this book.

In this chapter we present an interview that In-grid conducted with CC. Through this conversation, we share how this web-to-print infrastructure, along with its social practices and the frictions within its processes, shapes and situates what wiki4print is and has been in action.

CC X In-grid In-terview

Conducted by George and Sunni, two In-grid members, on 31 October 2025 (using Signal for video call).

Could you introduce yourself a little bit?

Simon: My name is Simon Browne. I live in Rotterdam in the Netherlands, but I'm not from the Netherlands. I came here about eight years ago and studied at XPUB, the MA in Experimental Publishing at the Piet Zwart Institute. Since then, I've become really involved in a lot of collective publishing work. At the moment I'm part of Varia in Rotterdam and OSP (Open Source Publishing) in Brussels. Together with Manetta, we also do this thing that we call CC, Creative Crowds.

Manetta: My name is Manetta Berends. I have lived in Rotterdam for twelve years. I'm from the Netherlands and came to Rotterdam to study in the same MA course, which was called Media Design at the time and is now called Experimental Publishing. That's also the place where I'm currently involved as a tutor. I come from a background in more traditional graphic design. During my BA, I have grown into a practice that is very collective – that's about making tools, or the practice and tools themselves. We'll talk more about that during the interview. It meant that my practice shifted a lot: from being someone who would work on commissions to someone who also organises events, is involved in a community of practice, does some writing here and there, and makes things you could, I guess, call tools. Being involved in practice in different ways, with a specific focus on collective publishing environments.

We're really interested in how wiki-to-print has been used in different projects. Could you share a bit of history and practices of wiki-to-print?

Manetta: It's very hard to start talking about the history of that practice of working with wikis, publishing and making publishing environments out of them. I think there are multiple lines that can be traced. One that has been important for me has been the making of a book called Volumetric Regimes, published by the Data Browser series of Open Humanities Press. It was produced closely with the editors, Femke Snelting and Jara Rocha, who proposed to work with the wiki because they had the interest. They also published a wiki version of the book online. Femke had been very involved in working with OSP, with whom she had made another book in the context of Constant's project called Diversions, and another book before that, also in the context of Constant, called Mondothèque. Building upon that practice, seeing what has happened around these particular projects, has been very informative and inspiring for thinking about how an editorial process could be shaped in very practical ways.

Simon: I don't have much more to add. For me, the fear about giving a historical account of wiki-to-print is that somewhere in the world there's somebody who's working with a wiki and making PDFs, and we're going to leave their name out – we're not going to mention them. So I think there's definitely a culture of people using wikis to make PDFs within the network that we're part of, and we can talk to that a little bit. Manetta already mentioned the Mondothèque project and the Diversions project, which were both using a wiki to write. With Diversions, it really questions the ownership or authorship of material in a wiki, because when you're writing in a wiki, there is this notion that you're collaboratively editing things and there's a way that you can see lots of different versions of texts. But I think for me personally, I first came across wiki-to-print when working on a commission that came through Varia – a comission Manetta and I were both working on – for a Peer-Reviewed Newspaper About: Minor Tech. Manetta had been using it before and she introduced it to me, and I thought "Wow, okay, so you can use a wiki to make a whole bunch of different publications." What was exciting about it was really the idea of versions of publications that can come from the one wiki. But I have to say, in my own experience, I haven't really explored that so much. It's really just been about producing one version of one publication.

Manetta: Perhaps there's one more line to trace, because I think it may not be a very direct historical line – if we can call it that – but more like an indirect, very important one: we both have been involved in wiki writing quite a bit. In the Experimental Publishing MA, the wiki is very central to many things, it's very central to the course. It's used as a calendar, as a personal notebook, as a syllabus. It's the place to collect all the syllabi. It's an archive. It's many things. And I think that has been really important for both of us – to see and feel the excitement and sort of understand from within the dynamics that a wiki creates. At least for me, that was really the reason why I got interested in wiki publishing environments: because of searching for that combination of dynamics and sociality that a wiki can create, and trying to bridge that to a publishing production moment. Simon has also been working with wikis, he was interested in hypertext for his graduation project. So the interest in wikis as a mode of writing, I think, is super important for our interest in this way of working.

Simon: And also learning at XPub about very simple ways of taking the content of a wiki and then bringing it into the format of a website or a PDF or something like that. At XPub, I learned how to do these things in an improvisational way. I wouldn't necessarily say it's a structural part of what I was doing, but yeah, the publicness of the XPUB wiki at first was something I found a bit daunting – because everybody can see everything that you're doing. At the same time, you have a lot of control about how you want to organise your own user page and what you want to put there. And it's a great environment for being able to look at what other people are doing and have done over the years. I actually spent a whole year before I came to the Netherlands just lurking on the Piet Zwart Institute for Media Design wiki. Mostly because it was a big decision I had to make – an expensive one – so I wanted to make sure it was the right one. I didn't have a chance to come to the open day, but I could see going back to 2011 or so, all the work people had done, all the questions they'd had. To me it was this kind of radical openness that was really attractive. So when I first started writing on the wiki, I kind of understood already the publicness of it and who would be seeing it, and I felt okay about that. I think that definitely changes things. It's different from, say, having a conversation about Wikipedia, which is a space where I don't feel comfortable writing, and it's also a strongly contested space. So when we say "wiki", we may have to make a distinction between which wiki we're talking about. If it's the Piet Zwart one – yeah, great. The ones I've made myself – great. Wikipedia – maybe not so much, in terms of my comfort levels.

George: That's really nice. What Manetta was saying is that this printing practice – or tool, whatever we want to call it – emerged from this background, right? I mean the sociality and the community that went into it, instead of classic publication where you have a community separate from the printing, and then try and filter it through. That's really nice. And also, what you were talking about there, Simon, about accessibility – I think it's really amazing how it gave you, from a distance, such intimacy with what was going on and gave you comfort. What you were saying about which wiki – I think, again – shapes it as a practice. The wiki is the tool, but it's about how you do the practice with that tool.

Manetta: I can't see the sociality and the technical setup separately from each other any more from. If you want to talk about one particular wiki, one wiki is never like another. It's really shaped by the people who are editing it, the relations between those people, the material written, the way it is set up, who is running it, and all of those things – and how the software itself is structured. It's just really important not to detach it from its social context.

I’m wondering what’s the breakpoint of feeling uncomfortable at first but ending up enjoying the openness of the wiki?

Simon: Again I'd have to say with openness, it can be good if you know the people who you're being open to or who's there. At the same time, I remember a big question that people had when I was studying at XPUB and using the wiki: What happens to the wiki after I graduate? What happens to my pages? Do they stay there? Also, it's possible for anybody to edit anyone's pages – so somebody could easily come to my user page and just delete everything. Of course, there's a user history there, and I can revert those changes and go back. But I remember also there was a conversation around making a website for the Willem de Kooning Academy, which is the BA programme of the Piet Zwart Institute. In 2020, they wanted to make a website to compensate for the fact there wouldn't be a graduation show – so they would have a graduation website. And this discussion about wiki or WordPress was in the air. And it was a big concern to them – the openness of the wiki in that any student could go and edit any other student's page.

Manetta: This is interesting because that fear comes from the top. But then, if you're in the middle of it, maybe you also fear that somebody will edit your page. But in reality, because it is so embedded in a network of trust, I haven't heard of any occasion where things like this have happened. I find it quite telling that in a sort of top-down situation, there's a fear that is then so strong the degree of openness is not accepted. I mean, there's lots to say though – I'm not here to idealise that degree of openness, because it's quite something to run a wiki which is that open. In a sense, the responsibility that comes with it is something that can be talked about and should be talked about. Especially these days, where people are being more and more aware that having their content on the open internet also means that there are crawlers and scrapers and anyone can read it. In reality, not anyone is reading, and it's really a place that is embraced by people around XPUB, and in XPUB, and then potential people coming to XPUB. Although the question of openness gets more and more under pressure of those crawlers and things like that. Sorry, I'm trying to make two points. One about the crawlers, and the second one is that openness sounds like it's open to anyone – and in a technical sense it is – but in practical reality, you see the openness this wiki has means that it mostly attracts people who somehow relate to the course. And because it is that open, it allows people that are not yet related to the course to still engage with that particular wiki, which is a porosity which I think does something very special. But now can then be put in contrast with the issue of the crawlers and the bots. And yeah, so it's to be continued. It's really a complicated conversation.

George: Just a quick thought – maybe it's MIT or somewhere, but their course website is completely open as well. Anyone can edit it and – like you said – they never had any issues. This is similar to what Simon was touching on: there's a process for undoing things, you can see who's done it and cancel that account. There are these protocols in place that mean that if things do go wrong, we can deal with what goes wrong instead of trying to prevent things from going wrong – which also prevents certain things from going right.

We’re curious: why do you like using wikis? And before using wikis, what other tools were you using? What frustrations came from the process of changing your tools?

Manetta: Yeah, there are many frustrations.

Simon: Maybe we should also disambiguate the different types of wiki software that we've used, because they're different from each other. When I talk about "wiki", most of the time I'm talking about using MediaWiki software, because that's the one I am most familiar with. What I like about it is that there's a huge amount of people that are contributing to it and making extensions for it. It's relatively easy to install. Because it's part of my practice and the people around me, it's often the first choice. But there are other wikis we've worked with. We worked with and installed ikiwiki, which is another system based on Git version control history. It's also being used for, say, permacomputing.net. They use ikiwiki, and I think for them, it's because they can edit the wiki locally as a file and then push the commits. So it's very lightweight in terms of network dependencies. Whereas I found it very frustrating for the project we were using it for. It was very difficult to understand how to show a gallery of images or things like that. So yeah, when I say I like using wikis, I'm mostly saying I like using MediaWiki.

Manetta: There are so many ways to answer this question, but maybe to zoom out a little bit: for both of us this way of working with wiki publishing environments is part of a larger practice around making publications with free software – trying to move, or moving away from, well, first of all, Adobe, which was our shared tool that we both learned to make publications with. That's how we got into the practice of graphic design. Then, from an interest in learning about ways to generate publications, instead of making them through graphic user interfaces and visual tools, is what really grew my interest in workflows – in thinking about how a publication can be made collectively and how you can actually use all sorts of tools, and combine them in all sorts of ways, to make custom ways of working, custom workflows that really fit a particular situation. So within that interest, there is another subsection that is really focused on using HTML and CSS to style and make the layout of those publications – but it can also be done differently.

Once I moved away from working with these graphic user interfaces, I really entered into a way of working – a practice that feels super open-ended and is totally based on modularity, on combining all of these different tools. And so within that world, what I really like about working with wikis to make publications is that they also become an archive of the material that you work with. Through the making of the printed publication, you actually also make a digital version that can be read online – that's a practical website – but it also invites writing in a different way. You can write in shorter snippets and recombine them for a printed publication in different ways. You can even make different versions out of the same material. You can write collaboratively, you can recombine those different elements over time differently. It really feels like it has the potential to write the body of text and then create publications out of that body of text in different ways. This is what I really like about the wiki – that it has this potential to grow into an archive of practices. By adding this PDF-making functionality to a wiki, it feels like you add the ability to make a snapshot: to make one particular sort of cut from an archive of materials. Perhaps this is not how wiki publishing has always been used. For instance, in the ServPub project and also in the Volumetric Regimes project, the wiki was really there to produce a book. That creates a very different starting point for writing, because that comes with a particular idea of writing chapters, of order, of having a section with a biography – all these sorts of typical things that a book, or those particular books, will contain. But still, within those more traditional editorial processes, the wiki still allows for a very different way of working together. It's much less linear than more traditional workflows. You first need to finish the text, then have rounds of copy-editing, proof-editing, and all that, and only then do you send it to the designer, who would then do a back-and-forth with the editor to finish the layout. Here you can start making the layouts, in theory, from the beginning – but I think you've found that challenging in the context of the ServPub project – but it does create a very different dynamic in which everyone can see the final result. It also requires more involvement from editors, I believe, to think along the grain of this particular workflow. It is an experimental practice to make these particular books in this way, and it is not comparable with working in more traditional ways.

George: No, it's really good. I like your point about the difference: the more classic wiki-for-print you're talking about is building up a body of writing and then forming a book from that in multiple structures and taking snapshots. Whereas Volumetric Regimes and this project (ServPub) are more on the opposite end – but I still find that it's all about orientation. And even those books, even though they're more on the editorial process, they're trying to move towards. And it's like we said – we're still learning or feeling it out, the editing and the design process – but at least there's a space to do that as well and start to try and do that anyway, which I thought was really nice. Your second point was about moving away from Adobe towards wiki-to-print processes and about how it can build up. This makes me think about how Adobe – a for-profit company – captures or tries to hold people in place with their products, or maintain specific dynamics. And it's a very closed ecology where when you move out – even though it's harder – you're adding to the psychology as you write in it, as you design in it, and as you like bring together these different add-ons.

Manetta: Thanks for emphasising this, it's a super important. This is the main motivation to work in this way – to indeed not contribute, not be stuck in those global ecologies, but to see what happens when you start to become part of more open-ended ecologies.

Simon: Yeah, what happens and who you meet as well.

Manetta: What you learn from it, who you can work with.

Simon: What you learn from it is a big one. Adobe has a lot of different products and so a lot of people using them. There's a lot of information about how to use them. But I'd have to say, since I've started working with free and open source software, I've met people who are developing tools. I've met people who are using them. I've met people that are involved in trying to raise funds to support them – and there's a lot more complexity behind it than making a beautiful book. I think those things are more intriguing for me – the transformative things that happen on a social level through publishing – rather than just making a nice book. To me, that seems to be a kind of limited outcome for publishing if it's just about aesthetics, about how things look and if it's aligned to a grid or not.

Sunni: In my experience, it was really difficult for to switch from using Adobe tools to using wiki-to-print. But it really opens a door for me – seeking more creative ways of working and thinking about the possibility of not using corporate tools for efficiency.

Manetta: I think if wiki-to-print is your first step into that world, that's quite radical – because even writing a small web page with some nice CSS styling and preparing that for print is super radical in my understanding of it. And it feels like here you got that, plus the layer of a wiki, plus the layer of what that does in terms of collaboration with a lot of other people. And then we didn't even talk about all the pre-press stuff that will come up when you start printing. Because these PDFs that roll out of browsers are not comparable at all with the PDFs that come out of Adobe InDesign. So it is quite rough. It really is a practice. It really is something that it is not comparable and is really a different world to work in.

Sunni: When I was chatting with Johanna, she was basically saying: "This project feels like doing web development and design at the same time."

Manetta It's really nice that you're saying that, because that's my intention: to not make those cuts between developers and designers. It's especially about finding the interaction between the two. And to come back to what was said about learning from these other people that you suddenly work with – learning from developers and people involved on the network or server side of things. All these things suddenly are coming together. It really matters how you configure the server. It really matters where that server is running. It matters how the development of the tool is done and how the layout is constructed aesthetically. All these things are relating to each other. It's very hard to separate into even different roles that would be done by different people.

Speaking of the learning curve of wiki-to-print, I'm curious: how do you find sharing this practice with people who have never used a wiki?

Manetta: It's a really good question. We have struggled with this, for instance, in the context of research workshops. The moment you're invited to bring something like wiki-to-print into a workshop that involves, let's say, a group of thirty researchers coming from an academic background, if that workshop is designed without the thinking about what type of writing can be done from a wiki point of view – and the ideas of writing collaboratively are thought of separately from the software, the setup, and the practice of wiki publishing – it becomes really difficult to make that into something meaningful. We really struggled with this.

Simon: It's also a cultural thing. Perhaps we can compare it to using slang and certain types of language that you're comfortable with in a group of people – then, when you meet a different set of people and you use those words, it's confusing. And it can happen both ways. It's very difficult to convey cultures because they're not so explicitly there when we meet each other. We don't think, "Oh well, I need to translate every single bit of slang that I use to somebody else." At the same time, it shouldn't necessarily be: "Okay, we're going to use wiki-to-print instead of an Adobe workflow, and therefore you must use it in the way that I've always used it." There has to be some sort of common ground that you meet on – and it's difficult to do that in a short-term process.

Manetta: You need to take the time to find that common ground, and to find that space in between to make it interesting for all sides. I think it still worked out in those particular settings. A wiki can definitely also be used for more traditional ways of editing a book, or maybe not as a writing environment, but more as an uploading environment. Let's say the writing may have happened somewhere else, and then you upload. And still, there is something that creates something interesting. But I think we came from being excited about wiki writing – that could be seen as an invitation to also really think about what modes of writing we could explore together with these thirty people that we didn't know. Maybe we could write small wiki pages and then combine them, and something could grow from it. Something could just emerge instead of starting from a structure and applying that to a wiki – which I think did work out. I'm still very happy with those newspapers that came out of those two particular workshops. Still, I think if we would have taken more time to find that common ground, it would have really changed the point that we departed from. And we're still interested in finding a context to do that.

George: It reminds me of what you said about moving from Adobe to open source, where you kind of have to give up, or the practices aren't translatable as such. Within software, there are strict limits, right? You're in Adobe, you have to do it this way. You're in CSS, you have to do it this way. Whereas the wiki is more blurred – you can upload something, but it's still there, I think. I definitely feel that it's about having a common ground, or a background, or – in case of XPUB – having a sociality or an energy that gets published or that maybe you can bring something lacking here. It's very important to this kind of work as well.

Manetta: Energy and having space to come together and enjoy being together, to work on that thing that you're working on together. It's also very important – once you enter into these community-based ways of working around publishing – to find the joy of coming together in an event or joining these summer schools that are organised. For instance, Hackers and Designers is one that I've never joined myself, but I've seen people around me enjoying going there, meeting people. I think Simon and I organised the Publishing Partyline in 2022, which was really an important moment to feel the energy of quite a big group of people coming together that all work in this particular way. And so these moments of exchange are just really important for me – and needed – to not feel like you're the only one stuck in a terminal and CSS style sheets to make this printed publication, going through all these bugs and weird looking pages and non-aligning grids and all those things.That's something that happens.

Simon: You need documentation and you don't know who to ask a question to and all these things.

With all these past projects, how does the structure of each project influence the technical structure of the coding architecture?

Simon: Do you mean the way that wiki-to-print has been used, how that might influence a technical development – for example, adding a feature or something like that?

Sunni: That's the perfect way to put my question.

Manetta: Perhaps this is a moment to talk about the different versions. This particular software that the ServPub book is being created with is software that has been written by many, many hands and exists in many versions – perhaps, in the end, it is more a practice than software. This version that is running, I think we all together started to call it wiki4print, just to give it yet another name – but I don't think there are many changes to a version that is called wiki-to-print (with the letters "T-O"), which is the version we (CC) use. This is versioned from Wiki2Print with the number two, which Hackers and Designers is working with and possibly has multiple versions of because they made multiple publications with their version. But Wiki2Print (with number two) is also versioned from Martino's Wiki-to-PDF that he made for TITiPI – which TITiPI is using quite intensively in their wiki, in their MediaWiki. And Martino's version was based on the Volumetric Regimes version that I wrote – that didn't have that collaborative element built-in. The part that is built into MediaWiki wasn't there yet, but Martino... I don't know. So just to acknowledge that this is really entangled with many other versions of practice.

Simon: There are also other projects which aren't wiki but have a wiki logic – such as Ethertoff, which is part of OSP's toolbox. And that also has a super long history. That's using Etherpads, but with the same logic – gathering a whole bunch of different pads to compile a publication. That also has its own version trajectory into Etherport, which is being used by the Institute of Network Cultures and a group of other organisations at the moment. So there's the way of working, then there's the software – it gets very complex. We can chart a small part of this in a way, but there may be somebody out there who's just using something to pull text from a wiki and putting it into a PDF that we don't know about.

But in terms of the version and changing things along the way – the version of wiki-to-print that we use – what is particularly different about the previous version of Wiki2print….

Manetta: Of the version from… Well, Hackers and Designers did a lot of work also on their version on... Well, I remember what I changed to this particular wiki-to-print that we use at CC is that you can click on update text and update media inside the MediaWiki itself.

And I think in Hackers and Designers and Martino's versions you had to go to another interface outside of the wiki to do those actions. I think Hackers and Designers added the style sheets to the talk page of a wiki so that you have them side by side. And that then inspired me to add more buttons. I think – I'm not 100% sure – but this is potentially one of the changes between the Wiki2Print for magazine design and the wiki-to-print that we're running at CC. And then it's also running on ServPub.

George: But it really adds to the comments before of adding to the ecology and building some stuff, isn't it?

Manetta: And it's open-ended. Maybe there are more versions of these versions that we're not aware of. And that is really cool.

2+to=4/for

Writing, editing and designing with wiki4print is only one part of the wider socio-technical complexities of the Servpub project itself. In-grid have come to learn and understand that the versioning of wiki-to-print, using the name wiki4print ( 2+to=4 ), becomes a way to name socio-technical practice, to move away from talking about installing a software tool on a server. Tracing one historical line of these wiki printing practices is not possible and immediately becomes a process of getting to know a network of people. wiki4print(ing) as practice has thus been a process of embracing frictions, (un)learning next to others, getting to know people, of asking more questions than doing or making.

Link to pad