The DH RSE Workshop White Paper by DHTech

This white paper aims to draw attention to some of the issues we observe, and invite anyone who is interested to join us.

At the DH 2019 conference, a group of people that identify themselves broadly as Digital Humanities Research Software Engineers came together for a workshop. This white paper is the outcome of this workshop. It aims to draw attention to some of the issues we observe and experience and invite anyone who is interested to join us.

Who are we?

An important and large part of the broad and diverse Digital Humanities (DH) community can be defined as the ones who conceptualize, develop, and maintain algorithms, develop tools and websites, model data, and implement and maintain research software in order to solve Humanities research questions. This group, the Digital Humanities Research Software Engineers (DH RSEs), is crucial for the success of any DH project. There is a wide range of DH RSEs from programmers with a strong humanities background who acquired programming skills later in their careers, to software developers who acquired their DH knowledge over time through working with humanities scholars. However, what is lacking is the awareness of the importance of DH RSEs, a clear career path, and academic recognition, for example due to inadequate publication systems for software and data. We argue that without DH RSEs there would be no DH as almost no DH project can be realized without someone who understands the approaches and methods of the research domain and is able to conceptualize and implement the digital or computational part of a humanities research project.


An important skill of DH RSEs is the ability to mediate between the technological world and humanities scholars. This requires an understanding of the approaches and thought processes used by both the humanities discipline and the computational technique. One of the keys to successful communication is understanding the assumptions of the discipline, those things that are so obvious to researchers in the field that they would not explicitly state them unless asked about them directly. RSEs who are experienced in humanities disciplines either understand the assumptions of the field already or know enough to be able to predict what they might be and ask about them. A continuous dialogue between RSEs and humanities scholars is needed to make this ad-hoc knowledge transferable and available for RSEs new to the field.

Career Paths

DH RSEs have various different roles in an academic context. Some work on software development, data analysis, or are designing representations of results; others manage software development projects and infrastructure in a wider context. DH RSEs are sometimes directly embedded into a specific research field, or work in more service oriented facilities.

While there are some institutions offering career paths for more “service-oriented” DH RSEs, this is not the standard yet. Additionally, there is no clear career path for “embedded” DH RSEs and their role as part of the research community is not always clear. Many DH RSEs start out as PhD students and might move on to postdoctoral positions. Since a big part of their work focuses on software development, however, this turns out to be a dead-end career as the development of software tools is not recognized as valuable contribution in terms of career progression (publications are in most places still required to move on to an assistant professorship). In addition, the “traditional” career path (PhD, Postdoc, professorship) is not the desired career path for many DH RSEs, but alternatives are lacking. Since DH RSEs are such an essential part of DH research, we argue that a clear career path is strongly needed to keep experienced and attract new DH RSEs.


Recognition is a problem for many people working in RSE roles. There is no formally agreed way to credit work done towards research outputs other than the traditional author/co-author roles. In many fields, including DH this model is not reflective of how research is conducted. There are many varied roles taken in DH projects, in a very small scale project these may be filled by one or two co-authors but in larger projects there will be many people involved in data creation, data management, software development, statistics and visualisation and probably many others on top of the standard role of interpreting the research in a written form for publication.

The kind of recognition required in DH strongly depends on the chosen career path. Postdocs in RSE roles and embedded RSEs might have different needs from persons working in RSE service units. These different backgrounds and futures need to be taken into account by institutions and funding agencies. For DH RSEs pursuing a more traditional academic career, the development of software tools, creation and cleaning of datasets should be taken into account when applying for positions. Similarly, it should be common practice to cite and refer to the software and their creators in publications if the software played a crucial part in the research process. If a project would not have been possible without the help of an RSE, this RSE should be named and potentially even be co-author on publications. Some journals, for example, “PLOS One” (, explicitly state the contributions of each author allowing RSEs to be acknowledged for their work. While this practice is not universal, there are efforts underway to increase the visibility of this issue and to standardize non-traditional publication roles (see, for example, Holcombe 2019 for a discussion of this issue).


Many (if not most) DH projects depend on the work of RSEs to accomplish their goals. Often, grant proposals promise a piece of software, an interactive website or the development of a new algorithm as one of the project deliverables. However, it is not the norm yet that RSEs are involved in the planning and writing phases of the grant application process. This leads to inadequate time and funding allocated for the technical aspects of the project. It is also important that funding agencies have appropriate processes for reviewing the technical aspects of a project and ask the right questions of applicants to ensure that these technical questions are addressed from the inception of the project. RSEs are the people who can work with applicants to answer these questions and should be involved in this from the very beginning of a project.


DH RSEs are not only part of the DH community but also of the wider research software engineering community (RSE 2019). All RSEs face common issues, but DH RSEs are currently not very well represented or vocal within either community. We have already made a start on establishing a group within the Digital Humanities, called DHTech, as a place where ideas can be discussed and where we can learn from each other and our experiences. By coming together and working as a group, we hope to increase the visibility and amplify the voice of DH RSEs in both communities. DHTech offers regular webinars, has a mailing list and a Slack channel. It can be joined here.


Robert Casties, Alexander Czmiel, Julia Damerow, Max Ionov, Albert Meroño Peñuela, Steve Ranford, Catherine Smith, Malte Vogl


AG Research Software Engineering in den Digital Humanities (im DHd-Verband). Home (2019). URL

DHTech. About (2019). URL

Holcombe, Alex. Farewell authors, hello contributors. Nature 571, 147 (2019). URL

Mateusz Kuzak, Maria Cruz, Carsten Thiel, Shoaib Sufi, and Nasir Eisty. Making Software a First-Class Citizen in Research. SSI Blog (2018). URL

RSE. International RSE Groups. Research Software Engineers Association (2019). URL

James Smithies. Research Software (RS) Careers: Generic Learnings from King's Digital Lab, King's College London (Version 6.0) Zenodo (2019). URL

Software Sustainability Institute. About Software Sustainability Institute (2019). URL

Society of Research Software Engineering. Society of Research Software Engineering (2019). URL