chapter
Gijs de Heij
3 July 2024, 3:30 PM
Introductions
00:00 Welcome to this call. I’m Marta. I’m from Nero Editions, and at this table, maybe you recognize some people, but it’s the .expub team, which is a consortium between Nero Editions based in Rome, the Institute for Network Cultures in Amsterdam, Aksioma in Ljubljana and Echo Chamber in Brussels. We are doing a biennial of experiments on new publishing formats to bring light to knowledge and practices developed by members and our network in publishing. The idea is to create an operational model for this term Expanded Publishing. We will do a quick round of introductions.
00:52 I’m Lorenzo, part of Nero Editions with Marta. We are colleagues and Nero Editions is a publishing house and creative agency. We’re based in Italy and we’re mostly focused on art publishing, theory, and radical thinking in publishing. We have two different sectors: one is more devoted to contemporary art, it’s more experimental; the other one is traditional publishing based on printed books distributed in independent bookshops and sometimes in big chains.
01:54 Hi, my name is Janez and I talk on behalf of Aksioma. Marcela is here with me. I’m the artistic director of Aksioma, an institute for contemporary art based in Ljubljana. We produce and present artistic projects, mostly new media-related. Besides that, we do publications, discursive programs, conferences, talks, podcasts, and of course, sometimes streamings and stuff like that. Marcela is curating the program together with me, but also takes care of all the financial aspects of our non-profit organization.
03:00 Hi, my name is Ilan. I’m a researcher at the University of Liege in Belgium. I represent a small non-profit organization based in Brussels that is interested in conceptual comics, synthetic comics, and other forms of digital archiving in the medium.
03:35 Hi, I’m behind the scenes. I’m Tommaso and we know each other already.
03:54 We invited you for part of a series of 10 interviews with experts, artists, editors, or people working in the publishing industry to understand the whys, hows, and whats of expanded publishing. Despite the serious setup, it’s a very informal space for discussing ideas. So we would like you to be as free as you’d like to be with speculations, silences, and mistakes. We’ve also been talking to Clusterduck, Silvio Lorusso, Thomas Spies, Irene de Craen, Geoff Cox, Yancey Strickler, Kenneth Goldsmith, Dušan Barok, and Caroline Busta. We’re recording this with the plan of creating a hybrid report and eventually, a toolkit or publication. I will now pass the microphone to Carolina, who will handle the moderation of this meeting.
Why: Politics of Publishing
[00:05:14]- Thank you, it’s nice to see you — feel free to answer the questions in your own way. First, we wanted to focus on the “why” and although you are representing Open Source Publishing, feel free to come in with your personal experiences too. But starting on the “why” of publishing and in the politics of publishing, could you first introduce quickly OSP, particularly focusing on the mission and goals that guide your collective?
05:58 Open Source Publishing is a collective based in Brussels, we’re a collective with different backgrounds, but mostly graphic designers, and we make graphic design using only open source tools. We started with the question of whether it was possible to do graphic design using only open source tools, but for me, the question has sort of shifted over time towards: what’s the influence of using alternative tools on your design or the web, or on the work that you make? This, for me, is best explained through the sentence coined, I believe, originally by Femke Snelting: “Practice shapes tools shapes practice”. This speaks about the relationship between the tools that you use and the work that you make, but in a way, it also speaks about the relationship between the makers of tools and the users of tools. Open Source Publishing only uses Free/Libre, open source software. This is software that explicitly permits using software but also adapting it and then publishing it in an alternate form. It can be software, but it can also be publications or fonts that you make, because of those explicit permissions, it creates or opens up the possibility for different responsibilities or for taking on a different position as a user or a creator of the tools. So if you use these tools, you do not necessarily buy them, in the sense that if you use a closed, proprietary software, you have a sort of very singular license, and the responsibilities are quite clearly defined. I think with FLOSS software there is an invitation for more responsibility but also for more freedom. The practice of OSP is exploring this process of us being users of the tools, but also making the tools as designers and questioning what is possible, or harder to do, is also part of that position.
How: Infrastructures of Publishing
09:16 I think you’re already going into a lot of useful discussions and threads that we want to touch on, particularly within this idea of the balance between more freedom and more responsibility with FLOSS software. I think that’s a really interesting idea, together with you working with a collective of people, not in a traditional graphic design practice, and thinking of these workflows and distribution of labour or roles. Could you maybe elaborate a little bit on what this workflow, what a typical workflow would look like for OSP, for the projects that you’re handling and working on?
10:09 An example I can give is the work that we did on the Fair Kin Arts Almanac with the State of the Arts, which is a group of artists in Belgium and mostly Brussels that tries to discuss more fair art practices. Three years ago, we started the process of making a second version of an Almanac gathering contributions from members of SOTA, the organization initiating this publication. We were invited quite early on in the process, and we proposed a tool called Ethertoff that would facilitate a series of events that ran over a year where SOTA invited different groups of people to discuss questions around arts practices. What the tool specifically allowed for was to take notes in a collective editor called Etherpad and these notes were later used as material for the Almanac. So in that sense, the workflow is one of providing, thinking with the organization of the infrastructure that they are using, suggesting an alternative — an open source one — and using the tool from gathering material towards design and publishing it both in printed and online form.
12:25 I was going to say that we are using Etherport to make notes and to generate possible expanded reports on this. I forgot to mention it in the beginning, sorry, I wanted to say that! So that’s also really nice because Etherport is a sort of version or expansion on a tool that OSP had already developed before called Ethertoff. It’s interesting to think about the design process from the start and not in a traditional way where you would perhaps get everything delivered, the content decided, done, and written, and then you shape something around it, but starting from the start. Just to make it more clear and perhaps for others who might not know so much about the tools that you make, what are the main tools that you’re now using or are important for your practice at OSP?
13:44 So, at the moment, we mostly have, I think, a browser-based practice in the sense that we use HTML and CSS as layout tools. Then the output can be both online as a website, and can also be printed as a PDF. We also have tools that generate this HTML, so the more server-side tools can be Python, it’s mostly Python at the moment. When we go towards print, what we do is, essentially, print a website, so it generates a PDF, and then often this PDF needs to be transformed. So it’s a toolkit of PDF tools. So you have PDF2K, which allows you to take out pages, to combine PDFs. We use GoScript to manipulate the colour space, we also sometimes have new tools to manipulate, like crow boxes, but that’s very technical.
15:04 Expanding a bit on something you mentioned at the beginning of your introduction, these tools shape the design in a very unique way. You’re not dependent on interfaces that someone else has defined can make a design. So what do you think these FLOSS tools do that proprietary software doesn’t? And what are the challenges with working in such a way?
15:56 In the case of Etherport and Almanac, what these tools allow is to be reconfigured. They are often made with the assumption that people will use them together with other tools so you can export towards a file format that can be transformed further by other tools, that’s a possibility, or they may have an API that allows you to call the programs from other programs. These tools are native when it comes to publishing on the web. A lot of work has been done in weeding out all the problems there, a lot of money or funds available for developers to work on it, in the sense that the development of Firefox or Chrome is of course not free, but it’s financed in other ways. Ironically, also in the case of Firefox, often through Google. When you go towards print, this part is very well developed actually, what it can do is quite astonishing. At the same time, you also always run into problems, especially if you go towards complex print objects, for example, using Pantone colours. The tools to deal with those issues are simply not available. And within proprietary software, with tools that were designed for this type of work, a lot of funds and time have been spent on dealing with those issues. And if you work with a more experimental setup like we do, you run into those issues and limited abilities, you have to try to find a way to work around them or to fix them.
18:43 I guess the book as an object hasn’t made this connection, we’re still in an experimental space, while working on browser-based tools, like you said, for printing.
19:04 I realized I forgot to mention one tool, which is quite important actually, called paged.js, which uses JavaScript to extend the functionality of the browser and to emulate support for the paged media standard of the W3C. So the W3C is the governing body for the standards that drive the web, and there is a standard that describes how browsers should deal with output towards paged media. Paged media is not used as much for browsers, so for browser vendors, for the makers of browsers, it’s not interesting to work on this functionality. What the paged.js project does is emulate this functionality and make it possible to use browsers for these complex printed objects. Through this possibility, it shows that there is a need for this functionality within existing software.
20:34 I really enjoy learning more about this and with you, for instance in making the Screentime Facetime Airtime book. We have covered the tools and how you work with other organizations in terms of production and operations. We don’t have to call it a business model because it’s a non-profit, but what is the model of sustaining OSP? How do you maintain sustainable work for the collective and how is that balance between working on projects and creating your tools? I can imagine that, usually, commissioned projects are more interested in a final project than a tool.
21:36 That’s quite a challenge, to be honest, and completely transparent. I’m not sure that OSP currently is or has a sustainable business model for its members. What we try to do is to make the development of the tools part of the work, we do not separate the making of the tool and the making of the design, but we try to further the tool during the making of the design. We also have a document that we call the Collaboration Agreement. Through this, we try to explain our practice towards future collaborators. So the function of it is to, from the start, make clear that the work on the tool is part of the work on the design. So to come back through this “practice shapes tool shapes practice”, the idea is to extend the functionality, making something new possible, which in the case of the Almanac, means to go towards a printed object from multiple paths. This is as much part of designing the object as it is to think about the font or the layout of the book.
Who: Community of Publishing
23:40 I think that’s when your work becomes different and special, thank you for that, and for talking about OSP as a group and the challenges that come with it, so thanks for your transparency on that. Thinking of networks and collaborators, we often think of tools that are proprietary, like social media, when it comes to maintaining community or reaching out. How do FLOSS play a role in this, or is it something that you don’t think about at all in maintaining collaborations and a network and the role of community within this practice?
24:49 So, there is an interesting community that’s called “Pre-Pros Print” that tries to bring together practitioners of experimental publishing and experimental graphic design. They organise events where people with similar practices can exchange, that’s an important community meeting. There’s also the community behind the software and these tools, but at the same time, I don’t engage that much with the community of Ghostscript or Inkscape or GIMP even though I’m aware that they exist.
26:05 I think the tool itself becomes the space in which the community acts, even if you don’t have personal contact with them, the tools are being improved and reworked and expanded on. So, that’s an interesting thought, something we haven’t thought of. Okay, maybe I stop with my pre-written questions here and open up the discussion to our table.
Discussion
26:53 Thank you so much. I think I have a set of questions, but I’m going to start with one and then maybe do a round. I’m going to take a step back and go to the beginning of all of this. The idea of this consortium is to try to combine different approaches to publishing, we are a consortium from different countries and different contexts, and the whole idea of these three days is to bring together practitioners, distributors, and writers, to share knowledge and to try to build something upon it, maybe at a certain point also to come up with some sort of definition or understanding of what we mean by expanded publishing. I think what we are doing now here is very valuable, and it’s something that we have to work a lot in trying to translate knowledge from the very technical to the very theoretical. What are the challenges in translating this knowledge in a way that can be understood from a very broad spectrum? I follow your work, and we work together, and I understand many of the things, not everything, but then I’m sure that someone else at the table may have less understanding of this, and I think it is something that happens often. Have you ever thought about the means to share knowledge in a way that it has the complexity?
29:23 When you say sharing knowledge and thinking about how to share it and how to communicate about concerns, there’s always the ideal, and then there’s the realised. There is an assumption that you have an open-source tool, you allow others to use it, and a README comes with it that also explains what the tool is, and with which questions it was developed. The tool in itself can be used and expanded but in reality, this documentation work takes a lot of time, and this time is not always available. And there’s also something about the quality of your code, to what extent can it be reused by others, and to what extent is it flexible? For example, Etherport is actually about making code that was developed within other projects accessible or available to others and allowing others to expand and extend upon it. So, within our practice, we have moments where we can share our concerns, write about our questions and hear the questions of others, and there are moments where, in a way, the process is experimental. The challenge is making time to document it and to make things accessible, both in documentation and in code. That’s a challenge when you’re working with any practice and a downside of making the tool development part of the design process. Towards the end, you’re so busy with finishing the object that the documentation of that work becomes less of a priority.
37:32 I completely understand, I relate with the idea that when you finish a project, especially a big project, the idea of documenting and explaining every step is a project in itself. My second question is about the idea of sustainability connected to this. Thinking of multiplicity of tools — I think we already had a conversation about this topic —, we were talking yesterday with Nero, they have a new online magazine and they were thinking about producing zines or a printed copy of the magazine. So a web-to-print tool would be the best. They were asking whether we knew any tools that could do that and how could they implement that. I thought about Etherport and realised that INC developed a tool two years ago with another project that was exactly about web-to-print for online magazines, the code for which still exists. However, the server management put it down because they kept telling us that the code was not safe, they didn’t feel safe to keep it there. How do you sustain tools in the long term? And also, how do you deal with this multiplicity of tools? Some tools use Paged.js, but most of them are tailored to the specific project. A term that came up a lot in the conversation before is federation. How to federate a set of tools? Is it something that you’re thinking about?
40:28 I think there’s federation in two ways. I guess the first form of federation is not exactly federation, but it’s about a tool being used by other people or institutes; and its usage creates a demand but also creates the energy for this tool to be supported and maintained, to make sure that it keeps on working over time. Then I feel like open source is an answer to this tool — the code being distributed and allowing other people to download the new version of the code and use it. The idea of federation, where servers exchange or copy over material from each other, is a little bit out of reach for me. Software is extremely fragile, especially if you run server-side software because it means that somewhere there needs to be a computer that is continuously executing this code, it’s being maintained and it’s being kept safe. What I think is interesting about a tool like Paged.js is that it’s client-side, it’s written in JavaScript and is an extremely stable platform, with a lot of care of backwards compatibility, which in this case would mean that old JavaScript still work on contemporary browsers. The combination of HTML and JavaScript is quite stable, but also to us, sustainability, or maintainability, is important, and I think that there is a third element there which I would say is archivability. Archivability means, from the start of the project, thinking about in which states the project will be and what would this object look like in archived form, in the sense that it can mean that a certain part of it disappears. This means having a hybrid publication, or a publication that can have multiple forms, both a website and maybe a printed output. You could decide that you only keep the printed output and keep the PDF and keep that as a sort of file. That is sustainable. It can also be that you freeze your website in the sense that it doesn’t depend on server-side software anymore, but that it’s only HTML files that are rendered, and they’re only static files, then your website is much easier to archive in the sense that you can copy the HTML files. It includes the images, the scripts and the media files, and you can essentially put them on a zip drive or make a copy on a cloud somewhere or an existing backup service. So I think that’s the answer for me. Currently, the answer is to make it sustainable by accepting that the object in its software form is unstable, and you need to sort of think about how you can make archivable, relatively stable objects out of it.
44:34 We started this project on expanded publishing because obviously, when there’s a need to expand something, it comes out from frustration or a crisis or some sort of need. With expanded film by the expanded field of art, this happened because the new productions of the artist could not be contained through what was understood, either sculpture or installation, so they needed to find other ways. So my question is whether we saw expansion needs to be done because of a crisis: ethical, commercial, or financial. Is this a technical question? Do we need to develop new tools? I’m here obviously playing a bit of the devil’s advocate — do we need new tools to address this problem? Is this a technical question or is it that the role of publishing needs to be articulated more in a political sense? What are your feelings about this?
46:04 I think there is a certain duality there. If you look at the practice of Open Source Publishing, there’s also a certain joy and interest in these technical questions. So that’s also driving the motivation to do this. For me, our work and its experimentations are interesting and it’s more interesting than working with existing proprietary tools. There’s also a political layer where making graphic design using proprietary software limits your choices very strongly. In the case of publishing on the web, that’s ironic because, from the onset, it has been open-source, and developed with the idea of people expressing themselves, but also maintaining their own infrastructure and its ever-continuing centralisation. So for me, it is extremely relevant to maintain and develop your own infrastructure and to use tools which support or even invite you to do this. I mean, there is a challenge there, because it needs to be maintained and it crumbles by itself. Existing platforms have developed a business model where that kind of work that’s sometimes also boring can be financed and can be supported. But I’m not sure I fully answered your question, I notice I get stuck a little bit because there’s always an ambivalence of being both optimistic about open-source and being a pessimist in that there are open questions that capitalistic models have found ways to answer, but we also see that those answers are often exploitative. I have a very strong desire to find paths around, but these are always fragile and complex and also situated, I think, in the sense of how they’re linked to specific people in specific situations.
49:34 I totally follow you on the joyful part because as an artist myself, I find joy in building systems to produce content, to generate stories and images. I think this is a question of choices. Do we need more tools to have more choices? I don’t think we lack choices in general, I think we have a lot of choices about getting a story out there or a message. Again, as a devil’s advocate, I am trying to think together with you right now and I don’t have any answers. I use a lot of Adobe, it’s cracked, I consider it free software. I don’t know if I’m limited by my software, I’m limited because, to be honest, nobody cares about what I do. I think this is the main barrier, it’s not so much about the tools I’m using, but it’s about relevance. Do people care about what I’m doing? If I change the tools I’m using, would it be more relevant? These are open questions and I don’t expect you to answer them. I just put them on the table as my own doubts. I’m also coming from Brussels, where everything is extremely well funded, we are products of a more generous cultural policy than other places have, where we are allowed to think speculatively, but the question is always there. What is interesting about what we are doing is how sustainable is it, not financially, necessarily, but in terms of ethics, interaction with people, responses, and community.
51:52 That’s why, if you speak about the tools that we use, we speak about Free/ Libre, open-source software, meaning that it’s not necessarily free as in freedom. So that’s why the Libre is there, and if you use the cracked version of the Creative Cloud, you don’t have to pay for it. So in that sense, it’s free, but otherwise, you are reaffirming an existing ecosystem that sets the Creative Cloud as the standard, synonymous with being a professional designer or being a professional publisher — that’s where our practice tries to install an alternative. Using that alternative doesn’t make our work all of a sudden more relevant, but I think that, in our practice, it generates new possibilities for collaboration. More importantly, it creates the potential for you as a publisher, or for us as designers to shape more elements of your whole publishing pipeline. With the Almanac, both the research and editing parts are done within the same tool, but it’s also done horizontally and collaboratively. Web-to-print allows last-minute text changes quite horizontally, so you can create a platform where editors or contributors can come in, and make text changes without having to ask the designer to do it within their existing tool. Finally, if a certain functionality is not there, users can create that functionality within the tool and of course, this is not easy, it takes energy. What’s important here — and this is not entirely true because it’s a little bit romantic — is the idea that the tool is never finished, but there’s a certain assumption within proprietary software that “this is it, this is what you can do with it”. Is this thought of? Well, it’s possible that it doesn’t work for you and then you can change it, so we might not know everything from the outset.
54:52 This conversation is sort of reminding me of something that came up today. To link different conversations, we were talking to Irene de Craen and she mentioned just stopping publishing, and then we talked to Geoff Cox, who was more along the lines of thinking about poor publishing and creating shorter connections between the elements of publishing that sometimes come with more mistakes. So I’m wondering if you feel like this type of work is also doing that; I don’t know if poor is the right term, because there is (at least in my head) the vision of these kinds of tools as quite functional and less messy, at least in the user side of things. How do you see this fitting into this idea of reducing the connections between publishing elements? Geoff mentioned several projects in which the work of the writer, the editor, and the designer are a bit more mixed and closed and they happen almost simultaneously and with less time or room for things being missed. So I don’t know, do you see your work being able to synthesise those processes more directly?
57:11 In our work, we create the structures that allow for those strategies but at the same time, the publishing that we do ourselves is limited and we respond to the practice of others. When we talk about printed objects as in offset-printed, then you still want to be very precise about what you publish. But if it’s online or if it’s something that is printed at home, then there are more opportunities to make multiple versions of the same objects. In my practice, I think more about the structure than about the outcome.
58:37 That makes sense. It’s also important that someone is thinking about structure, we can’t all be thinking about outcomes.
58:46 This reminds me also of the famous Mark Zuckerberg quote, “Move fast and break things”, which I don’t appreciate and I think it’s quite dangerous. So for me, it’s also about the fact that you’re still putting things out in the world, but I imagine that Geoff has a much stronger discourse.
1:01:29 I don’t know if I am lucid enough to formulate this question. Listening to you and also now when Lorenzo asked the last question, I always had in mind this question of accessibility concerning our research on expanding publishing. So I was wondering, for example, if we would want to expand the concept of publishing by using several tools, including open-source, sooner or later we will encounter a compatibility problem. I see the way you can operate and investigate. Maybe I’m wrong, but because you do it in a closed network of geeks and specialists who can operate the code and design their own tools. I’m fascinated by this empowering attitude, but if I have to think about myself, I see this accessibility threshold being too high for me. This is exactly what you are saying now, you were asking yourself whether you want to democratise the access or keep an entry-level that is high for specialists and so on. I’m not working alone as well, I would need, perhaps, to convince or force a set of people around me to adopt the same tools if they are not compatible with the one that I’m using. You know what I mean? But it also works the other way around; if you are an open-source convinced believer, and you want to convince other people that it’s good to be able to own your tools and design, probably you would be able to convince more people if the tool that you are producing can interface with tools that generic people are using, to facilitate the interoperability of the systems, in a way. I stop here because it might be confusing, but the whole open-source culture is fascinating and I have followed it for years, although I was never really able to join it because I never had a Commodore 64 when I was a kid, and I was always looking at other people to play.
1:06:20 You used the word democratise and so I think I want to push back a little bit on saying that we do not want to democratise our tools. Well, I guess I want to push back because it sounds very elitist… Essentially what a piece of software does is encode a process or allow for certain things to be possible through a computer, and this is made easier by reducing the possibilities. So this means that you reduce the amount of different outcomes and make more assumptions about the kind of work that’s being done in the tools. I think we are not interested in this reduction within our practice, but there’s also an issue in understanding what the users of a tool want and then shaping the tool to fit the needs of the user. This is a lot of work because there is the development, but there’s also the testing, and asking whether our assumptions actually work. We measure our assumptions, implement and test the tools, and then do a feedback loop and our practice is too small to facilitate such a process. You also mentioned interoperability and the word ownership. Open-source has an interesting answer, which is perhaps not strictly within the realm of open-source software, but it’s open formats, which are formats that can be read by multiple tools. So you can take your information from one piece of software and bring it to the next, which can be information or data that you export in XML or JSON format, but can also be an SVG image from a browser to be modified in Inkscape, and be opened in a browser again. To reply to what you said about ownership: the longer I do this kind of work, the more I have to accept that it’s impossible to have full control. Software is often described as the stack, it’s layers of different pieces of software that are interacting, but they’re also all currents layered on top of each other, taking different directions. As an individual, you can neither control nor understand all of them.
1:10:16 I was thinking about what Janez and you just said, and reflecting on the idea of democratisation. Sometimes I also get annoyed when I don’t understand a tool and say, “This should be easier. This should be way more user-friendly” — because we’ve been trained to have everything as user-friendly as possible. But at the same time, there are so many things that are not user-friendly and we don’t take for granted. If you think about graphic design, you will always ask a designer to design a poster. If you think about writing a text, you’re going to ask an author to write a text, but then when it comes to using tools, we have been used to thinking of them as becoming easier and easier to use, like browsing the web. It’s something that everybody needs to know. I think what you are contributing as OSP is to take a step back and reflect on the infrastructure behind tools. So, should we be more user-friendly? Should we be less user-friendly? I probably know your answer in that sense, but if we refuse the idea that everything has to be user-friendly, how should we implement this workflow into an already existing workflow? Otherwise, you can very easily go into a conflict instead of like a conversation.
1:13:03 I guess it depends on what you mean by user-friendly. I think it’s important for a tool to be user-friendly, but this does not necessarily have to mean that a tool is easy. Some things are complex and those complexities cannot be abstracted away or removed by software. If they are removed by software, it means that a lot of assumptions and choices have been made in designing the tool. We ask ourselves, “What would be possible if we try things differently?” — and we find different forms of collaboration that become possible because the content is not written by individual authors on their own computer and then sent to an editor, but it’s from the start edited on a platform. Then we take the output or the content from the platform and make it directly available on the web and allow it to be printed. If there is a content change, there’s no authority structure where the editor has to ask the designer to do it, but the contributor can do it directly on the platform. This is not necessarily easy to install or maintain, but tools need time and energy to be understood, to be able to be used or maintained. At the same time, these tools mustn’t be hostile, in the way that they are made, but also in the community that’s behind them or the documentation that they come with. In that sense, our tools are not always welcoming, and to come back to Ethertoff, this tool can be quite hostile to a new user. At the moment, it still needs an interpreter with it, but that’s also a situation we’re trying to change.
1:16:13 Just to clarify, I didn’t mean that the tool itself has to be user-friendly in the interface, for the end user. I think what I meant by user-friendly is what you just said, in installing and supporting. Sometimes we take for granted that you can just download a plugin or download a software, install it, and it’s running. We should probably collaborate more with coders, create more collaboration and not take the coder or the designer for granted.
1:16:59 To come back to this “toolship” practice: if you say that practice is the designer and the tool is the programmer, you have those two distinct roles of being a designer and a programmer. In reality, those roles exist. What I think we try to do in our practice is to make those roles more blurry and to say, you can be both a programmer and a designer at the same time and the license sort of explicitly creates the legal infrastructure to do it, but at the same time, as a participant, you still have to put in the work. To come back to what Janez said, you need a certain type of skill. I want to be both positive about it and say there is a relevancy to it and also be realistic. It requires a certain skill that takes work to learn, it’s called a programming language and it is a language with all that comes with it — learning the language, vocabulary, learning new grammar. It’s also about learning a different culture, which can expand your thinking in interesting, surprising ways.
What: Future of Publishing
1:19:15 Thank you, Gijs, I think you’re already leading us to a conclusion. We’ve been thinking about what expanded publishing is and what it can mean for us here in this group, but also in a general sense, and what are we working towards. We are using new media tools and digital tools everywhere, and yet I think literacy has to improve a lot in the role of the designer, speaking from my own experience. What are your wishes for these urgencies that should be addressed when we think about expanded publishing? You mentioned a lot of things about sustainability and responsibility…
1:20:56 That’s a difficult question. One thing I’m thinking about is, once again, ambivalence, and it’s a conversation that I had with Sepp Eckenhaussen from INC. Looking at initiatives like OSP, Hackers & Designers, and Pre-Post Print, I recognise they are communities of designers and programmers who experiment with tools but don’t necessarily have the desire to create singular tools. There’s a certain desire to develop individual experiments that do not go towards a single solution, but foster these universes or fediverses of tools more than seeing one solution for everything. What’s tricky is that there are different desires — those experimental practices also answer to a desire for experimentation. This is not always applicable or relevant, but it would be very interesting to think about how the two needs can be combined, supporting both the individual experiment, yet being able to communicate in a way that supports something larger, a more stable tool or development, or that it creates a knowledge and a network of both users and creators of the tools for publishing, and one that is more engaged with the materiality of the technology that we’re dealing with. For me, both Pre-Post Print and paged.js are very interesting examples. Paged.js is a plug-in used by many in experimental workflows, but this tool is also nourished by those individual experiments, specifically through plugins or by maturing this tool that tries to generate and facilitate needs for generating or creating complex printed or page objects from a browser, while not necessarily wanting to fix the full pipeline, meaning that paged.js can be used in combination with WordPress as well as with a handwritten HTML file.
1:25:15 Interesting that you’re saying is that this type of experiment in publishing creates publics that are much more participatory in the process of publishing itself and in that way, is a mode of publishing that engages everyone in the process in a different way, beyond the passive reader, which I find a good take. I would like to also say thank you very much for your generosity and for sharing your thoughts and reflections on these processes, we will continue working on Etherport, which is going very well, we have new labels for everything. We’ll keep in touch with you about how this develops.
1:26:25 Thank you for the invitation, for taking the time and for the thoughtful questions.