The open peer review process took place in May 2024. The review consisted of in-line annotation and commentary on the manuscript’s text, as well as exchanging two rounds of emails with more general comments and observations between reviewer and author.

The in-line commentary focused on clarifying the meaning of specific terms and references from external sources. It considered the importance of having a clear understanding of terms and concepts introduced in the text, as the text pursues an interdisciplinary line of thought and thus has the potential to attract a multi-disciplinary audience. When speaking (or writing) across disciplinary boundaries, there is always a degree of ‘translation’ that has to happen in order for common practices or discourses to be actualised and articulated – as in the case of Hackers & Designers ¬– across communities of designers, artists, tool builders (be it computer scientists, hackers, or other types of computing enthusiasts), science and technology studies scholars, among others. For instance, there was frequent use of terms such as collective practice / collective design / designing together: a clear indication whether these are all intended to be used interchangeably or whether there are significant distinctions, would make the ‘translation’ across communities of practice clearer.

The email correspondence focused on the significance of clarifying the extent to which open source practices may also be of concern to designers and expanding upon specific points or components of practice workflows that rely on tacit knowledge.

Below we include some shortened excerpts from the correspondence:

The level of detail regarding the practice of H&D that was presented in the text is much needed to promote doing design with tools, practices and values other than the [commercial] status quo. Bringing in the spirit of open source culture more into design via such concrete case studies is a much-needed contribution to the field. But open source software [OSS] and culture is an area typically over relying on tacit knowledge that could be better introduced in the opening of the manuscript to make it more accessible to a broader design audience. Some further discussion on the different modes of operation of OSS (also tied to the communities of practice around it) vs commercial software would also be beneficial. Maintenance being one of these. Commercial software, for example, pushes new updates all the time that have ties to specific economic conditions (you always need more and more powerful hardware too). OSS on the other hand requires a lot of manual maintenance to fix not only bugs but generally maintain security, up-to-dateness to coding languages and libraries that is a level of work separate to maintaining the servers that run the instance of the software. Even running a server – it may not be very clear to external audiences what steps or expertise are needed for this operation to continue taking place. Giving a hint at the network of relations around OSS via footnotes and/or references would be helpful.- LR

I agree, this is something I look forward to working on more and critically reflect on. I was for instance thinking to discuss a bit more the ways that H&D contributes to OSS, how the tools we use/make are building upon the efforts of others and are also continued elsewhere and afford the building of community through their mobility but also through their alleged imperfections. But perhaps it’s also important to elude more to the ways H&D’s practice of open source publishing is not to be mistaken as entirely independent from proprietary software/hardware practices. In fact, one of the aspects that I want to get across in this article is that this practice of “designing sideways’ although it might be an exercise in alternative publishing practices, is not a practice that evolves in a vacuum. There are significant relations to other-than-open-source economies and technologies… so that should not be brushed away and perhaps need to become that more legible. – AG

Another point came up that I should make the different roles / people involved in the different layers more apparent as well, to give credit and also to problematise a general ‘we.’

For instance, I am reflecting on this publishing practice through the lens of design, as a person who has been educated as graphic designer, whereas other people involved in a project like ChattyPub perhaps do not think of this process as a graphic design process but see it through another lens. The priorities and focus points shift depending on who you ask… For instance, the workshop Experimental Chatroom, which was the starting point for ChattyPub, intended to rethink and experiment with online conversational tools and conventions. So ChattyPub could be also reflected upon through the lens of the sociality of the web and real-time communication platforms online. I chose to reflect from the perspective of creating page layouts. My goal is that it becomes clear what I offer is only one of many perspectives. Accounting for other approximations of the same thing, is important, as to decenter and problematize ‘design as a conscious process to create meaningful order’ – AG

This is indeed a very important point that is often overlooked in more typical OSS-related texts. There is a fair number of designers who get into OSS and the “tooling” world so-to-say, but there is relatively little published about the distinctly designer experience of inhabiting this world that tends to be populated with actors coming (primarily) from computer and information science and who have less understanding for the background and techno-economic entanglements of design and commerce (and by extension commercial software). So clearly positioning the author-perspective as a designerly one and not something in a vacuum is crucial. This is also a very good way to problematize the general ‘we’ and introduce some specificity to the different possible perspectives and how they are all legitimately so, and perhaps also symbiotically so? As in, de-centering design allows design practice to enter more enriching/symbiotic conversations with others that can produce not only unexpected, but also/therefore better outcomes. – LR

Another question came to mind: I was wondering about your thoughts on the section that specifically discusses Wiki-to-print, Wiki2print, or Wiki-to-pdf workflows and practices. As you have been active in the larger Wikimedia movement, do you think there are relevant relations to reflect upon between the practices of communities using Mediawiki as a publishing / web-to-print tool and the community of Wikimedia contributors? – AG

I think this is an excellent question. There are a wide range of communities within the larger Wikimedia ecosystem, and I don’t claim to be fully aware of all of them, but the ones I’ve had contact with (mostly focused around GLAM, research or data (Wikidata)-related topics) don’t seem to really engage with the web-to-print ideas that have come out of more designerly or hacker communities. I think partly the issue is that for many Wikimedia contributors, adding something to the Wikimedia platforms is already a form of publishing, many GLAM projects are focused on “opening up” museum collections into a shared, commons platform. Often, they may start form print materials and for them the act of uploading them to Wikidata and/or Wikimedia Commons is a form of digitization and archiving aiming at making the materials more broadly accessible. Many of these contributors don’t have a lot of (paid) time to do this work and so just getting the materials uploaded is already an achievement. I do think it’s an interesting phenomenon. Because most outputs of research, and to some degree also museums and other institutional publications, are print / PDF documents, but they haven’t closed the loop yet from e.g. print archive, to digital archive on Wikimedia platforms, to then web-to-print document that can act as a catalogue raisonné (computationally constructed). Projects like COPIM certainly think about this and we are working on computational publishing pipelines in the Open Science Lab – for materials in Wikidata / Wikibase to be published in PDF and other formats, but such projects are not (yet) so well integrated into Wikimedia core contributor communities, so there is a divide. Perhaps worth exploring further, but possibly also in another article, or hinted in a footnote.’ – LR

Lastly, the final section of the manuscript was discussed in more detail, as it introduced a relevant, and well contextualised problematization around the practices shared in previous sections, but lacked a more synthesis-driven approach to tying in earlier theoretical concerns introduced in the beginning of the text with the problematisation introduced in the end. Both author and reviewer agreed, the manuscript does not necessarily need a summary or conclusion as seen in traditional academic articles that simply repeats earlier content. Still, the need to synthesise the arguments and reminding readers what ‘designing sideways’ is – based on the description of H&D practices in earlier sections – besides outlining what it is not, which is already well articulated in the Problematisation section, was agreed as a necessary revision.