Chapter 5 Critical Studies of Tech Stacks

Setting the Scene of the Case Study

While scientific laboratories have been analyzed through ethnographic methods (complemented more recently by STS approaches), DH labs have been less so; and the emerging scholarship on such labs has tended to foreground other aspects of their culture than those related to their technological stacks.4 To bring attention to the culture of DH lab tech stacks, we offer a case study of KDL.

Like other DH laboratories, KDL can be characterized generally as a site that enables “research through the provision of infrastructure, tools, and methods” (Smithies and Ciula, 157). But KDL is also one of the largest, most developed, and most professionalized DH lab environments, with an especially extensive tech stack that affords unique opportunities for closely examining the relation of technology and culture. KDL is rooted deeply in the history of DH from the 1970s on. At King’s College London, it emerged in a lineage that included the creation of the Research Unit in Humanities Computing in 1992 (which evolved into its own center in 1995), the Department of Digital Humanities in 2009–2010 (already de facto a department from 2002; Short et al.), and then the KDL itself in 2015. The KDL thus arose sufficiently far in the growth of DH for its founding director, James Smithies, and others to reflect on the lab’s legacy and scope (Smithies et al.) and respond to new concerns about the professional careers of RSEs as part of complex relations of technology, workflows, and labor in DH (Smithies and Ciula; Ciula and Smithies; Smithies, ffrench, and Ciula).5 Taking inspiration from established technology industry practices in project management and product development, the KDL RSE team collaboratively created and refined for the lab a Software Development Lifecycle (SDLC) for Research Software Engineering6 schema as a generalized, staged process for developing projects that can help manage those complex relations.7 In particular, the team adapted the Agile dynamic systems development method (DSDM) framework (Wikipedia) and released for public use related project templates and guidance.8 But while these SDLC documents summarize how the team develops and stages project life cycles, they are merely the scaffolding rather than the substance, which consists of the expertise of the team members in their day-to-day interactions with technologies, project partners, cross-functional teams in the faculty and university, and external stakeholders (including funders and vendors). The relationality of KDL’s research and development work thus stems not only from its processual nature (one iteration of product development informing others incrementally in a nonlinear, creative way) but from its socially negotiated nature: how the team’s work interconnects with the expectations of others (first of all, funders and project partners) in the adoption, adaptation, refinement, and limiting of technologies. This matrix of social relations fused with its tech stack is the scene of KDL’s lab culture.9

A Technology Network Perspective

To study KDL’s tech stack and the social relations that it mediates, we created an interactive network visualization in a data notebook on the Observable visualization platform (Pawlicka-Deger et al.).10 This visualization can be explored online, and it is also represented in selected views in Figures 5.1, 5.2, and 5.4. Based on ethnographic data gathered manually by Pawlicka-Deger during February to December 2021 from KDL’s internal documents and public resources (including GitHub repositories for projects and a StackShare page of tools, services, and packages), the visualization shows nodes for 220 software and hardware technologies at the time of our study.11 For example, ArcGIS, Gephi, JavaScript, XML, Zotero, and others are software tools and protocols familiar to digital humanists. Each technology is associated through edges with nodes representing the following attributes, which can be switched on or off to filter the visualization:

• developer (e.g., Adobe, Apache Software Foundation, King’s College London, University of Hamburg)
• function (e.g., databases, graphic editors, text annotation, storytelling platforms)
• permission (proprietary or open source)
• sector (communities, for-profit companies, universities, nonprofit organizations).12

To get a sense of how the KDL tech stack evolves, we also tracked which technologies have been considered for adoption, which are actively used, and which have become legacy tools.

Figure 5.1 shows a simplified view of the visualization, with just the nodes for sector type and permission type activated to allow an observer to focus on these attributes of KDL technologies. And Figure 5.2 shows additional attribute nodes that have been turned on to reveal the full complexity of the KDL tech stack, a crowded and tangled engine room of technologies associated with 136 developer nodes (with 113 distinct developers), 79 function nodes (with 45 distinct functions), 221 permission nodes (165 open-source and 56 proprietary), and 221 sector nodes (61 community, 88 for-profit company, 32 university, and 40 nonprofit organization) in various states of being considered, actively used, or deprecated to legacy status.

That tangle of these technologies is not just a puzzle for running a DH lab’s organizational and operational workflow. It is also about how technological practice is shaped by, and in turn modifies, the social ethos of the people who work with those technologies. Our network visualization allows us to observe the constantly adjusting balance—one involving both alignments and tensions—between technological and social domains, which creates the culture of a DH lab.

Interconnections Between Tech Stacks and Lab Culture

By observing the combination of everyday technological and human practices at KDL and analyzing the lab’s tech stack with the aid of our network visualization, we can gain insights into what we call KDL’s open-source pragmatism culture. On the one hand, this is a culture characterized by an ethos of transparency, sustainability, and experimentation consistent with an open-source model and good research software engineering methods, including Agile DSDM for project management (Wikipedia). Much like companies that operate in a manner influenced by open-source models (Labourey), the lab embodies the idea of open-source values at a cultural level. But on the other hand, as the mention of “companies” hints, the lab’s culture is also shaped by its need to work in conjunction with management and development models native to other sectors of society and other units of the lab’s own university. For-profit, nonprofit, and university organizational cultures thus pragmatically conjoin with KDL’s lab culture—a complex process of alignment and tension mediated, as mentioned previously (and as we will return to in this discussion), by the fact that open-source values now to some degree move among all these sectors. KDL is a DH lab that is distinctive in part because its team not only uses but reflectively considers technologies in this larger cultural picture.

Deferring for the moment the open-source side of KDL’s open-source pragmatism, we can begin first on the most pragmatic side of the lab’s culture by observing that the greatest share of technologies at the lab—88 in number, representing 40 percent of the total—comes from the for-profit sector (e.g., companies like Adobe, Google, and Microsoft).13 (See Figure 5.3.) The dominance of the business sector in the software market from which KDL draws tools raises important issues regarding licenses, dependencies, and design biases. As an example, consider Figshare, a platform from the Digital Science company for storing, sharing, and managing data. Moving a university’s repositories to Figshare, as King’s College London did in 2021, is often justified as a solution for “re-integrating a presently splintered scholarly infrastructure” (Plantin, Lagoze, and Edwards). However, such a move risks overcentralizing research data flow if it is not complemented by robust expertise and policies for research data management, data life-cycle support, and assessment of the implications of technical architectures. (As a cautionary tale, when YouTube temporarily terminated Cornell University Library’s entire account due to “sensitive content” in videos of lectures [Bright; Butler], many on social media criticized the university’s reliance on outsourced technology infrastructure and advocated for hosting resources in institutional repositories.) In general, the platformization of university resources can be a form of “technological dystopia” (Farnell) because “the reorganisation of cultural practices and imaginations around these platforms” (Poell, Nieborg, and van Dijck) poses risks related to security, surveillance, privacy, and datafication.

Why does KDL rely on so many technologies from the for-profit sector? One pragmatic answer, of course, is that the lab is not a stand-alone facility but rather part of its university, where institution-level policies negotiate and integrate technologies to meet multiple needs across King’s College London as a whole. Technologies from the for-profit sector enter strongly into the mix because, though not a perfect fit, their design as enterprise-level technologies are often suited to the whole-organization integration that universities need and cannot fully develop or support themselves. Thus during the Covid epidemic, for example, the need for technology integration led King’s College London to opt for Microsoft Teams as its main remote communication platform instead of the Zoom product chosen by most other universities. The decision was driven by the integration that Teams provides with other Microsoft services like SharePoint, which the university uses for data storage and sharing, and also by considerations of security and compliance with regulations.14 Large institutions such as major universities adopt technical solutions based on a mix of criteria (e.g., security, cost efficiency, unification of platforms) that are assessed, steered, and funded at an enterprise level and are rarely determined through shared governance with local units. Such institutional decisions then have a cascading effect on the choice of systems at such local units as KDL. For instance, in 2020, KDL transferred project management data from Google Drive to SharePoint to align with its university’s information technology (IT) professional service department’s recommendations and with universitywide security policies. Whatever the reservations of the KDL team about either Google or Microsoft data management products, institutional compliance was the decisive factor for change in the lab’s tech stack.

Another pragmatic reason for reliance on technologies from the for-profit sector that is internal to the KDL lab itself is integration at a different level: workflow management. For example, the lab coordinates its day-to-day operational workflow and communications through Slack, a for-profit chat platform popular in industry and in many project teams in the RSE and DH communities. But Slack is not supported by the King’s College London IT service department, which provides Teams (and the Microsoft social networking services named Yammer) for similar functions. KDL and the Department of Digital Humanities at King’s had adopted Slack before the university offered these Microsoft products. That fact, combined with Slack’s wide usage elsewhere along its efficiency and reliability, made Slack KDL’s continued choice for internal workflow integration contra universitywide integration. Slack is one instance of the for-profit technologies that (along with ClickUp and Microsoft project management software, for example) the lab uses for operational management, storage, and communication.

Pragmatic needs thus account for much of the preponderance of technologies from the for-profit sector seen in our network visualization of the KDL tech stack. But having said that, KDL indeed has a culture not just of pragmatism but what we term open-source pragmatism. This is a culture in which a critical stance toward proprietary commercial tools motivates exploring alternatives that align with the lab’s baseline open-source ethos. For instance, when in 2022 the European Data Protection Supervisor called for banning Google Analytics in European countries (see noyb), the KDL team sought more ethical open-source options, such as AWStats, Cloudflare Web Analytics, and GoAccess. The challenge was to find solutions that enhance workflow efficiency, provide relevant traffic statistics for assessment and reporting, and adhere to sustainable and open-source principles. Ultimately, KDL chose GoAccess, an open-source web analytics tool respectful of user privacy that comes from the sector labeled “community” in our network visualization. This is an example of how KDL explores a vast range of tools from the community, nonprofit, and university sectors, whose solutions—many of them open source—collectively make up 60 percent of the lab’s tech stack. Solutions developed by the community, usually shared through GitHub, are typically open source and free. Examples in addition to GoAccess that KDL uses include LeafletJS for mapping, TextBlob for natural language processing, and Debian as a Linux-based operating system. The university sector also plays a significant role in the development of open-source and free tools created by DH centers or labs, as well as other campus units staffed by RSEs, alternative-academic (alt-ac) staff researchers, and other research technical professionals. Examples of university-created open-source software include tools for annotation (e.g., Archetype, produced by King’s College London), timeline visualization (e.g., TimelineJS, produced by researchers at Northwestern University), and machine learning (e.g., GloVe, produced by researchers at Stanford University). Altogether, as revealed by our network visualization, open-source technologies for design, development, testing, and production of digital projects make up 75 percent of the KDL tech stack.

The bias toward open-source where possible reflects the lab’s philosophy of transparency at its foundation (King’s Digital Lab),15 which accords not just with universitywide policies and the requirements of funding organizations for open publication of data, code, and software, but also with general calls to reject “Big Edu-Tech” systems in favor of standardized, “Libre open-source” software or software developed within institutions (Farnell). Transparency is crucial to the lab’s practices, characterizing its approach to providing access to its code, web application programming interfaces (APIs), project templates, and more.16 Transparency involves exposing practices, tasks, and costs to stakeholders to foster intellectual rigor and to create more credible funding applications. Transparency is also a lived value in KDL’s research software engineering operations, which are steered collectively through documented regular meetings (held via platform-supported gatherings such as Project Pipeline and Timebox) and daily updates on progress and obstacles shared through the lab’s “Standup” Slack channel. Access by all lab members and project partners to communication and management channels, as well as opportunities for everyone to join in collaborative critiques and reviews, provide better traction on what happens in otherwise obscure digital processes.

KDL’s preference for open-source technologies also reflects the need for tools that can be adapted for project requirements by allowing flexible and creative customization. RSEs such as those making up the KDL team are a group that is increasingly professionalized, advanced, and creative in the DH community in adapting or further developing tools. At KDL, RSE positions are defined in such a way that the research staff can use 10 percent of their time for independent experimental work, including hacking, tinkering with, and iterating open-source technologies to tailor them to individual projects and infrastructures. Examples include working with rapidly evolving technologies such as augmented reality, artificial intelligence (AI; Hall), and machine learning methods (Noël; Bode et al.) to push them beyond the constraints of proprietary tools. RSEs in KDL are thus like developers generally in the open-source community, who play a crucial role in adapting and professionalizing open-source products (Volpi). Such developers act as the main customers, but also coproducers, of open-source products—discovering, downloading, reengineering, and integrating them into their projects.

But, of course, open-source technologies are also challenged by problems of reliability and security. Thus, the lab complements its open-source ethos with another ethos that is equally important: sustainability. Sustainability is a crucial aspect of digital research production that the lab takes seriously to keep projects accessible and retrievable for several years (even decades, in some cases). Sustaining open-source software in working form can be challenging and labor-intensive when software is considered as what Marisa Leavitt Cohn calls “lived temporalities of code”—that is, “an object subject to continuous change and lived with over time as it evolves” (Cohn, 423). This is why the lab sometimes favors some kinds of open-source software over others. Analysis of the data behind our network visualization thus shows that while KDL considers many open-source software tools developed in the university sector, ultimately it tends not to adopt those solutions, for reasons that come down to problems with sustainability. For instance, in 2017, KDL assessed adopting Omeka, an open-source digital asset management system originating from the university sector that is well known in DH for curating and publishing online collections and exhibits. At that time, the lab’s assessment indicated limitations in Omeka’s ability to support complex metadata schemas, manage version control, and handle risks associated with dependencies on other tools and software components. The lab thought that for its specific purposes, its ability to customize the system and make projects based on it more sustainable was too limited.17 As an alternative, the lab opted for another open-source solution for content management and modular-component web publishing that was developed outside the university sector in the nonprofit organization sector: the Django Python web framework. Since that time, KDL developers have tailored Django for greater, sustainable control over lab projects. Currently, the lab is undergoing a further consolidation stage, where an archival and static-first approach leading to static sites development from the outset is preferred and implemented.18 In short, KDL prioritizes solutions that are tested, flexible, and integrated enough with the lab’s tech stack and workflow to dovetail the two ideals of open source and sustainability. Rather than pursuing an idealistic notion of permanent sustainability, the lab prioritizes pragmatic solutions that create a best-fit alignment between research software engineering best practices and the lab’s ethos, all aimed at ensuring the sustainability of relevant components of digital projects.19

Indeed, in the antithetical spirit of open-source pragmatism, such an alignment is epitomized by the open-source software developed by commercial companies that KDL uses in its tech stack. After all, there is no longer a necessary division between open-source products, associated with free and collaborative solutions, and software from the for-profit sector. The open-source market has undergone significant changes due to the monetization of open software and the fact that big tech companies offer proprietary cloud-service platforms, such as Amazon Web Services, on which others build open-source products. In KDL’s tech stack, 27 percent of open-source tools are developed or owned by companies like Google, Facebook, and Microsoft. (See Figure 5.4 for a view of the network visualization showing open-source technologies in the KDL stack developed by various sectors.)

While not exhaustive, our network visualization of the KDL tech stack has allowed us to observe and offer critical reflections on the relations between a DH lab and the for-profit, nonprofit, community, and university sectors of digital technology. The visualization adds nuance beyond any simplistic open- versus closed-systems analysis, showcasing how the freedom of a DH lab to define its technical strategy is inevitably counterbalanced by organizational policies and management practices. The emergence of a culture of RSE teams in DH with a self-aware ethos of openness, creativity, transparency, and sustainability has the potential to tune that balance so that the values of RSE, alt-ac, and other researchers—values shared by the DH community at large—factor meaningfully into what would otherwise be overly centralized enterprise cultures. However, critical scrutiny will be needed to maintain that balancing act enacted through tech stacks and their management. The approach that we call critical studies of tech stacks contributes to such scrutiny of how DH labs are embedded in institutional, technical, operational, and sociocultural contexts.

Notes

1. 1. Urszula Pawlicka-Deger conducted an ethnographic study of KDL from February to December 2021 while she was a Marie Curie Research Fellow at the lab during 2020–2023; Arianna Ciula was cosupervisor of the fellowship and is currently director and senior research software analyst of the lab; and Miguel Vieira is the principal research software engineer at the lab. Pawlicka-Deger conducted twenty-five interviews with KDL members and others involved in the lab’s work. Some of the interviews have been transcribed and published in the Zenodo repository (Pawlicka-Deger, “DH Lab: Interview Transcripts”).

2. 2. On RSEs in the arts and humanities, see Sichani et al.; Smithies, “Research Software (RS) Careers.” See also DHTech, the movement recently recognized as an ADHO Special Interest Group around the development and use of software in DH and its activities (https://dh-tech.github.io/.) Except in the sciences, the term and concept of RSEs is less well known in North America DH, where attention has focused instead on the only partly similar notion of alternative-academic (alt-ac) researchers in staff positions and where the early “hack versus yack” and “Do you have to know how to code?” controversies in DH discouraged notions of DH that could seem to be exclusionary of participants who are not programmers. On alt-ac, see Nowviskie, “The #alt-Ac Track.” On “hack versus yack,” see Nowviskie, “On the Origin of ‘Hack’ and ‘Yack.’” On the “Do you have to know how to code?” controversy, see Stephen Ramsay’s reflections in the aftermath of this question that he asked at the MLA conference in 2011 (Ramsay). It is noteworthy that The RSE Turn in DH was featured as a topic of an international panel at the Digital Research Infrastructure for the Arts and Humanities (DARIAH) annual conference in June 2024: https://www.conftool.net/dariah2024/index.php?page=browseSessions&form_session=67.

3. 3. For examples of such research, see Berry and Fagerjord; Smithies, Digital Humanities and the Digital Modern; Plantin, Lagoze, and Edwards; van Geenen.

4. 4. For examples of studies of DH labs, see Ciula and Smithies; Foka et al.; Kemman; Lang; Oiva and Pawlicka-Deger; Pawlicka-Deger, “The Laboratory Turn”; Pawlicka-Deger, “Feasibility Documents as Critical Structuring Objects”; Pawlicka-Deger and Thomson; Smithies and Ciula; and Wershler, Emerson, and Parikka.

5. 5. The situation of RSEs and their relations to technology, workflows, and labor mentioned here refer specifically to the higher-education institutional context and other structures developed in the United Kingdom. While these tend to resonate with comparable developments in the wider European context, they might not be applicable or even relevant across different nations. (See also n. iii in this chapter on differences with the North American context, where the term “RSE” has not been as broadly adopted in fields outside the sciences.)

6. 6. https://kdl.kcl.ac.uk/blog/sdlc-for-rse/.

7. 7. https://kdl.kcl.ac.uk/blog/sdlc-for-rse/.

8. 8. https://github.com/kingsdigitallab/sdlc-for-rse/wiki.

9. 9. Of course, the KDL technology stack evolves dynamically both on a project-by-project basis and over the long term. Seen in overview, KDL’s technology has undergone several major stages of change spanning from the lab’s origin in 2015, when it hosted over 100 projects inherited from the King’s Department of Digital Humanities, to the present, when it is currently migrating much of its software from on-premise infrastructure to the OpenStack infrastructure of King’s College London’s centralized e-Research service unit. At the start-up in 2015, KDL’s tech stack (based on that of the preexisting Department of Digital Humanities) was already significant by DH standards. It included rack servers supporting 400 gigabytes of RAM, over 180 virtual machines, and 27 terabytes of data. The back end and front end of the lab’s projects used application frameworks comprising a mix of technologies: Java (with custom-based frameworks such as rdb2java and DJFacet), Python (particularly the web framework Django), the bespoke XML-based publishing solutions XMod and Kiln, and PHP-based frameworks such as WordPress, Omeka, and Typo3 (Ciula and Smithies). By 2018, KDL’s infrastructure included over 200 virtual machines running Linux and was hosted in physical cabinets located at the University of London Computing Centre. KDL systems managers then completed a complex process of remediation and upgrading in December 2021 to improve the sustainability of infrastructure and ensure its alignment with the university’s e-Research and IT service units. In combination with KDL’s archiving and sustainability program (which requires regularly assessing hosted environments and communicating with faculty, partners, and project owners about maintenance options), this process reduced the number of virtual machines to 110, which KDL standardized by limiting each one to specific principal components (e.g., Django/Python, JavaScript, and Docker). In addition, KDL dedicates eleven servers to centralized services such as image and other data storage, email, and user authentication. The lab uses a range of network, security, and website analytics tools for monitoring and upgrade processes. As described elsewhere (Smithies and Ciula; Ciula and Smithies; and De Roure, Moore, Page et al.), KDL’s infrastructure is managed through distributed accountability and regular cycles of upgrades, assessment, and remediation. Going forward, KDL will maintain a smaller on-premises footprint for projects with specialized needs, such as software for testing machine learning methods and digital creativity applications (e.g., for the production of immersive experiences enhanced by AI and Internet of Things applications such as Room Is Sad). Integration with the university’s e-Research services unit will provide KDL with a flexible long-term infrastructure road map that is aligned to its systems in terms of architecture and security and supported by centralized university research infrastructure expertise—a step that will make possible a major change in systems management, as well as environmental sustainability. In the last leg of migration, KDL will host all its servers on the university’s CREATE OpenStack system, with two dedicated hypervisor platforms for virtual machines. Upgrading KDL’s core production infrastructure from on-premises infrastructure to the e-Research unit’s infrastructure will contribute to the university’s net zero carbon institutional target by 2025.

10. 10. https://observablehq.com/@jmiguelv/dhlab-kdl-technology-network.

11. 11. For the dataset (in .csv format) underlying the visualization, see Pawlick-Deger, “King’s Digital Lab Technology Network” (dataset).

12. 12. For technologies developed by individuals, we assigned the “community” sector.

13. 13. Note that the percentages mentioned in this chapter should be interpreted as approximate because technologies included in the data collection could not always be completely and separately enumerated. Open-source libraries, for example, proliferate in the KDL software development life cycle, but they were excluded from the data collection process as it would have been impractical to compile an exhaustive list.

14. 14. This information was requested to central ITS and obtained via email in April 2021.

15. 15. https://2015.kdl.kcl.ac.uk/how-we-work/philosophy/.

16. 16. See, for example, the way that KDL makes its project templates available in its GitHub repository for “Document Templates,” https://github.com/kingsdigitallab/sdlc-for-rse/wiki/Document-templates.

17. 17. Omeka, of course, has since further evolved. KDL’s technology assessments are constrained by deadlines and the requirements of specific projects; they are thus necessarily not comprehensive or general in their conclusions.

18. 18. https://kdl.kcl.ac.uk/slides/2024-london-static-first/.

19. 19. KDL has implemented an archiving approach and framework that include comprehensive sustainability assessment overseen by a dedicated committee. The framework offers maintenance and archiving options such as converting web resources to static sites or packaging them for migration.

Bibliography