Chapter 4b: Public: FLOSS Design

<unicode>⧝⬳≁</unicode>

FLOSS Design principles and processes:

Choice of fonts, and design values/ethics/considerations, licensing, questions of openness, and federation, other ways of organising.

Link to pad that is being shared between design and computational publishing chapters. A record of meetings to get familiar with designing with wiki4print.

FLOSS Design: Fricitious Ecologies?

In-grid wiki-to-print(ing)

The design work for the book was done primarily by members of In-grid. We started to participate in the servpub project in May 2023. At that time none of us were particularly familiar with the technical setup of wikis or computational publishing with Free and Open Source Software (FOSS). As design practitioners, our reliance on the Adobe suite that has a toolset tailored to print and digital publishing had to be reconsidered. Our encounter with web to print practices has been thanks to Creative Crowds and the use of wiki-to-print, which operates on Servpub as wiki4print. In-grid has been on a journey of working within the constraints of open-source design, both learning how to bridge the practices of web development into the domain of design for print, but also entering into the ecologies of FLOSS.

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

During a conversation with Creative Crowds, they expressed that it's difficult to talk about wiki-to-print in a general way, as it was made for particular situations, both technical and social. They explained that calling wiki-to-print a tool flattens the socio-technical practices of wiki-to-print. The social practice of wiki-to-print(ing) has thus become a way for In-grid to think about: the relational aspects that emerge within the Servpub project the productive frictions between FLOSS Design and out of the box design software (like Adobe) the potentials for computational design

Within this chapter we bring together some conversations In-grid had with both CC (some of the maintainers of the wiki-to-print software) and Johanna De Verdier (the designer of this book (+ In-grid member). Through these interviews, we aim to share how this printing infrastructure, social practice and its frictious process shapes and situates what wiki4print is in action.

Could you introduce yourself a little bit? (Doesn’t need to be purely academic. Just think it’d be cute to know you with a bit more background.)

Simon

My name is Simon Browne. I live in Rotterdam in the Netherlands, but I'm not from the Netherlands. I came here probably about eight years ago, and I studied at XPub, which is the Experimental Publishing Master of the Piet Zwart Institute. Since then, I've gone on to become really involved in a lot of collective publishing work. So at the moment I'm part of Varia in Rotterdam and OSP or Open Source Publishing in Brussels. Then also with Manetta, we both do this thing that we call CC, Creative Crowds.

Manetta

My name is Manetta, Manetta Berends. I live in Rotterdam as well, for 12 years already. I'm from the Netherlands and came to Rotterdam to study in this same master course that was called Media Design at the time, now called Experimental Publishing, which is also the place that I currently am involved at as a tutor. I’m from a background in more traditional graphic design during my Bachelor studies, I have grown into a practice that is very collective, that is about making tools or practicing with making tools, or practice and tools. We will talk about that more throughout the interview. That meant that my practice shifted a lot from being maybe someone who would work in commissions towards someone who is also organizing events, being involved in a community of practice, doing some writing here and there, making some things that 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 and publishing and making publishing environments out of them.

I think there are multiple lines that can be traced. One that has been important for myself has been the making of a book called Volumetric Regimes, published by the Data Browser series of the Open Humanities Press. That was a work closely made with the editors of the book, Femke Snelting and Jara Rocha, who proposed to work with the wiki because they had the interest, and also published a wiki version of the book online. Femke had been very, 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, that has been very informative and inspiring to think about how very practically an editorial process could be shaped.

Simon

I don't have much more to add. I mean, I think the fear for me about giving a historical account to 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 about, so 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, that Manetta and I were both working on, for a Peer-Reviewed Newspaper About: Minor Tech. So Manneta has been using it before and she introduced it to me and I was like, 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

Maybe one more line to trace, because I think it is may not be a very direct sort of historical line, if we can call it that, but more like an indirect, very important one is that we both have been involved in wiki writing quite a bit. In the experimental publishing master’s course, the wiki is very, 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, really important for both of us to see and feel the excitement and sort of understand from within the dynamics that a wiki creates. And at least for myself 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 to try to bridge that to a publishing production moment. And also Simon has been working with wikis, like being interested in hypertext for your graduation project. And so the interest in wikis as a wiki as a mode of writing, I think is super important for us to be interested 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 like a structural part of what I was doing, but yeah, the publicness of the XPub Wiki at first is kind of something which I found a bit daunting because everybody can see everything that you're doing. But at the same time, you also have a lot of control about how you want to organize 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 wiki for Piet Zwart Institute for Media Design. 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 something, all of the work that people had done, all the questions they'd had, and 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. So I think that definitely changes things and it's different to say, if we were having a conversation about Wikipedia, which is a space that I don't feel comfortable writing within and also a very heavily contested space. So I think, you know, when we say Wiki, we also may have to make a distinction between which Wiki are we talking about. If 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 it's like this printing, practice or tool, whatever we want to call it, emerged from this background, right? Like the sociality and the community that went into printing instead of classic publication, which is you have a community separate to printing, and try and filter it through, that's really nice. And also, what you were talking about there as well, about accessibility, Simon, I think it's really amazing where you're like chatting about how it gave you from a distance such like intimacy with what was going on and gave you comfort. But what you were talking about with which wiki, and I think that's again, shapes it as a practice. It's like the wiki is the tool but it's like how do they practice with that tool.

Manetta

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

I find it interesting that Simon you mentioned about feeling daunting at first about the openness of wiki. I’m wondering what’s the breakpoint of feeling uncomfortable at first but ended up enjoying the openness of it?

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 was, 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 I can go back. But I remember also, yeah, there was a conversation around making a website for the Willem de Kooning Academy, which is the bachelor program 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, they wouldn't 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 Wiki in that any student could go and edit any other student's page.

Manetta

Which is interesting because that fear comes from top down. But then if you're in the middle of it, maybe you also have the fear that somebody will edit your page. But in reality, because it is so much embedded in a network of trust, I haven't heard of any occasion of things like this happening. 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 of the responsibility that comes with it is something that can be talked about and should be talked about. Though I think, and especially in 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. 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 technical sense it is, but in practical reality you see the openness that this wiki has means that it mostly attracts people that 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

Quickly just thinking about, it might be MIT or somewhere, their course website is completely open as well, like anyone can edit it and they've never had it. Like you said, thy never had any issues. I think it's like what Simon was touching on, there's a process for undoing things, you can see who's done it and cancel that account. There's 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 Wiki? And before using Wiki, what other tools are you using? What are the frustration 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 the MediaWiki software. Because that's the one that's most familiar to me.

What I like about it is that there's a huge amount of people that are contributing to it and also making extensions for it. It's relatively easy to install. And because it's part of my practice and the people around me, it's often the first choice. But there are other wikis that we've worked with. We worked with and installed an iki Wiki, which is another system that's based on the Git version control history. And it's also being used for, say, the permacomputing.net . They use ikiwiki, and I think for them, they're using it because they can edit the wiki locally as a file and then push the commits. So it's very lightweight in terms of the network dependencies. Whereas I found it very frustrating for the project that we were using it for. It was very difficult to do things like understand how to show a gallery of images or things like that.

So yeah, for me, when I say I like using Wiki, I'm mostly saying I like using MediaWiki.

Manetta

There's 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 to 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 can also be done differently again.

So it's like once I moved away from working with these graphic user interfaces, I really entered into a way of working like 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 like a practical website, but it also invites for writing in a different way. Like 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 write, 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. And that's what I really like about the wiki, that it has this potential to grow into an archive of practices. And 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. And that's maybe 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. So then 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 sort 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 very different way of working together. It's much less linear as you would have in more traditional workflows. Where you first need to finish the text, then have rounds of proof editing, copy editing and all that, and only then do you send it to the designer that 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 been experiencing that this is hard 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 grains 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. And I like on that last point where you're talking about the difference of the more classic Wiki for print you're talking about where it's like building up a body of like writing and then forming a book from that in multiple structures and taking snapshots. Whereas like volumetric regimes and this project more like the opposite end, but I still find that, you know, it's all about like 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 in this one, the design and the editing have maybe been, we're still learning or feeling it out, but it's 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.

And then the second point, if I'm not jumping too much, was also how you're chatting about moving from Adobe into like Wiki to print processes and chatting about how it like can build, it feels like it can build up.

It's just making me think a lot about like how Adobe being like a for-profit company is like captures or tries to hold people in place or like with their products or like maintain specific dynamics. And it's a very closed ecology where it's like when you move out, it's even though it's harder, it's like you're adding to the psychology as you rise in it and as you design in it and as you like bring together these different add-ons.

Manetta

Thanks for emphasizing that because that's a super important motivation to work in this way. That is the main motivation to work in this way to indeed not contribute, not be stuck in those world 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, like 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 as an outcome for publishing if it's just about aesthetics of how things look and if it's aligned to a grid or what not.

Sunni

For my personal experience, it was really difficult for me to switch from using Adobe tools for years 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 already just 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's really a practice. It's really 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 like this project feels like doing web development and design at the same time.

Manetta

That's actually 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 sort of finding the interaction between the two. Also to come back to what was said about learning from these other people that you suddenly work with, like learning from developers and learning from people maybe involved on the more network or server level 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 is done of the tool and it matters how the layout is being constructed aesthetically and all these things are relating to each other. It's very hard to cut them apart into even different roles that would be done by different people.

Speaking of the learning curve of wiki to print, I'm curious about how do you find sharing this practice to people who never use Wiki?

Manetta

It's a really good question. Because we have struggled with this, for instance, in the context of the research workshops. Because then the moment you're invited to bring something like Wiki2Print into a workshop that will involve, let's say, a group of 30 researchers coming from an academic background. If that workshop is then designed without the involvement of thinking what type of writing can be done from a wiki point of view, and so the ideas of writing collaboratively are just thought of separately from thinking, it's not done in conversation with the software and the setup and the practice of wiki publishing. And it becomes really hard to make that into something. And we struggled. Yeah, we really struggled.

Simon

And it's also a cultural thing. I mean, maybe I compare it to, say, using slang and

certain types of language that you're comfortable with using with a group of people and then when you meet a different set of people and you use those words, then it's confusing and it can happen both ways. And it's very difficult to convey cultures because they're so, how would I say, like we don't, you know, they're not so explicitly there and when we meet each other, we don't think about, Oh, well, I need to translate every single bit of slang that I use to somebody else. At the same time, like, It shouldn't necessarily be that you say, Okay, we're going to use Wiki to print instead of an Adobe workflow, and therefore you must use it in this way that I've always used it.

It has to be some sort of common ground that you meet on. And it's difficult to do that, I think, 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 get interesting for all sides. I think it's still worked out in those particular settings, I think a wiki can definitely… also be used for more traditional ways of editing a book or more sort of maybe not as a writing environment. But as more as an uploading environment. Let's say that the writing maybe happened somewhere else and then you upload. And still there is something it still does create something interesting I find. But I think we came from being excited about wiki writing that that could be seen as an invitation to also really think about what modes of writing. We could explore together with these 30 people that we didn't know and maybe that we could write small wiki pages and then combine them together, and then 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.

And I'm still very happy with those newspapers that came out of those two particular workshops. But 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 kind of reminds me of how you were also talking about moving from Adobe to open source, or like this, where it's like you kind of have to give up, or it's like the practices aren't translatable as such, you know what I mean?

It's like within software, there's like strict limits, right? Where it's like, 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, it's more blurred, but you can upload something, but it's still there, I think. I definitely feel that there's also,like you said, having a common ground or like, a background or how we're kind of talking about the X-Pub where it's like having a sociality or a energy that gets published or that you bring, maybe somewhat lacking or like.

It's like 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 to, once you enter into these, like on another level, when you enter into these community-based ways of working around publishing. It's also very important to find the joy of maybe coming together in an event or joining these summer schools that are organized, I mean, have been organized by, for instance, hackers and designers is one that I'd never joined myself, but I've seen people around me enjoying going there, meeting people.

I think...Simon and I organized the publishing party line in 2022, which was really an important moment to feel the energy of that, quite 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.

And you need to go through all these bugs and weird looking pages that you, and not 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.

Sunni

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

Simon

Do you mean like the way that Wiki to Print has been used, how that might influence a technical development, like adding a feature or something like that.

Sunni

That's the perfect way to put my question.

Manetta

Maybe that's a moment to talk about the different versions.

Simon

Yeah.

Manetta

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 and is maybe more a practice than software in the end. This version that is running, I think we all together started to call it Wiki-4-Print, 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 [Creative Crowds] use. Which is versioned from Wiki 2 Print with the number two, which Hackers and Designers is working with. And possibly also has multiple versions of because they made multiple publications with their version. But Wiki-2-print with the two is then yet also versioned from Martino's Wiki-to-PDF that he made for TITiPI, which TITiPI is using quite intensively in their wiki, in their media wiki. And Martino's version was based on the volumetric regimes version that I wrote that didn't have that collaborative element built-in. That part that is built into the MediaWiki itself, it 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, like Ethertoff, which is part of OSP's toolbox. And that also has a super long history.

I mean, that's using Etherpads, but with the same logic of like you can gather together a whole bunch of different pads to compile a publication.

And then that also has its own version trajectory into Etherport, which is being used by the Institute of Network Cultures and a group of other organizations at the moment. So there's the way of working, then there's the software, it gets very complex. And we can kind of chart a little bit of this in a way, but yeah, I mean also there may be somebody out there who's just like 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, I mean the version of Wiki to print that we use, what is particularly different about

the previous version of Wiki2 print….

Manetta

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

And I think in the versions of Hackers and Designers and Martino, 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 then add more buttons. I think, now I'm not 100% sure, but this is potentially one of the changes between the wiki to print 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.

Conclusions / design colophon?

bits below with comment could be good for design colophon.

Social practice

We had our first workshop at CCI UAL that aimed as a knowledge sharing session from Systerserver and Varia, which we began set up the first Raspberry Pi that now hosts servpub.net. From there, we then had another two other public workshops that walkthrough the technical setup of the Raspberry Pi, network protocals, self-hosted platforms, and facilitating working session discussion.

What we used and why

Excalidraw for moodboard/ brainstorming, opensource font website for font choice (BADASS LIBRE FONTS BY WOMXN, openfoundry, velvetyne, The League Of Moveable Type etc...), riseup pad for communication and documentation, and jitsi for videocalls... All fonts used in this book are under the SIL Open Font License: https://scripts.sil.org/OFL.

(A section for talking about online x to y converters, like jpg to ASCII and the image dithering tool. As it's great part of internet history)

When we started working on this project, we had to challenge ourselves to take stock of the mainstream tools we instinctively used (Figma board for moodboard, photoshop for mockup, google fonts for font choice...etc). Although we are computational practioners who code creative software, we found that we made a division between design tools and software development tools. It sounds like an inconvenience to give up on using those designed for professional outcome softwares. We believe that using FOSS promotes collaboration and innovation within the community.

Difficulties / Observations

index.php?title=Category:ServPub