Indispensable, Interdependent, and Invisible: A Qualitative Inquiry into Library Systems Maintenance

Over thirty years after such systems were first developed, the Integrated Library System underlies most operations of an academic library. Yet in the literature, its day-to-day maintenance is often reduced to a list of tasks. Through interviews with sixteen system maintainers, this study attempts to develop an experiential understanding of its maintenance. Findings suggest that most maintainers find such work meaningful but face barriers when colleagues and administrators don’t understand what they do well enough to support it. This article proposes steps toward building a workplace where core maintenance tasks are recognized and supported.


In their 2019 “Information Maintenance as a Practice of Care,” the Information Maintainers expand Russell and Vinsel’s 2016 definition of maintenance as acts that “sustain and repair people and things” to include “[acts that sustain] the interfaces we design to function between and among information systems.”1 Perhaps no role in the library fulfills this latter aspect so clearly as that of the person or team charged with managing the Integrated Library System (ILS) and maintaining its many connections to library, institutional, and vendor systems. When listing the roles of library IT workers in 1994,2 Tim Lynch named “maintainer” first among the six he identified. Yet in the nearly thirty subsequent years, little research has been done on maintainers in the library.

This research project into library systems maintenance began with a presentation at the 2019 Maintainers III conference on the maintenance implications of replacing a decades-old “classic catalog” with a Blacklight or VuFind-based public catalog. The conversation it generated suggested the need for deeper inquiry into the experience of maintaining library systems at academic institutions.3 This article focuses on what has been traditionally known as the Integrated Library System or ILS,4 because it remains core to the operation of academic libraries.

The ILS is the site of acquisitions, catalog record and item maintenance, and circulation management. It provides data to the library’s public catalog or discovery system and can be queried for statistical analysis of item use and overviews of holdings. Despite its centrality to the work of the library, its maintenance is rarely discussed in the literature of the profession. Yet an incomplete understanding of ILS maintenance is an incomplete understanding of the very thing that keeps the library functioning.

In this article, maintenance is defined to include regular system upgrades, updating system settings, addressing bugs and issues, upkeep of integrations with other institutional systems, and minor tasks to improve user experience or support existing functions. The latter type of work spans maintenance and innovation,5 but when it consists of bringing existing systems into alignment with expectations and work already being performed, it aligns closely with other areas of maintenance included here. The term “library systems maintainer” is used here because not all maintainers are librarians, and to emphasize that those in this role also support interoperability between the ILS and some or all other technical systems used in the library.

Literature Review

The literature of library systems work consists primarily of retrospectives of system setup or migration, speculations on future innovation, and surveys gathering data to define job requirements for the educational needs of a systems librarian.6 Even Ojedokun, Olla, and Adigun’s highly concrete retrospective on seven years maintaining a Koha system returns in its analysis to the subject of implementation.7 Yet a literature of systems maintenance can be assembled by identifying recurring themes across retrospectives and survey-based research.

Emerging from this literature is the need for the library systems maintainer to understand the operation of the library and the university as a whole. In 1996, Eric Morgan described systems librarianship as “the art and science of combining the principles of librarianship with the abilities of computing technology.” Xu and Chen8 found that while library directors believed that systems librarians would benefit from library school courses on computer software and system or database design, systems librarians themselves overwhelmingly identified “Organizing information” and “Reference,” followed by studying the ILS itself, as necessary preparation for their work. Similarly, Guinea9 and Tyson10 describe the importance for systems librarians of knowing all major functions of the library, and how these functions interact with each other in order to make the best system-wide decisions.

Understanding library operations supports maintainers in the challenging work of managing interoperability between the ILS and many other systems. Its earliest mention comes in Epstein’s 1983 identification11 of fundamental interoperability needs between software vendor, terminal manufacturer, modem/multiplexor manufacturer, and telecommunications provider. By 1999, systems directors interviewed by Lavaginino12 describe interoperability concerns between multiple software packages in a networked environment and between database providers and ILSes. Breeding’s 2006 “Knitting Systems Together”13 reflects the desire to create a seamless user experience even as maintainers find themselves managing more systems and dependencies than ever before, many entirely under someone else’s control.

These shared maintenance environments increase the need for strong communication and collaboration skills.14 Tyson describes “networks and contacts” as “the new systems librarians’ tools of the trade.”15 These networks and contacts include others at the institution, peers in the field, and the vendors from whom one licenses systems. In comparing the technical support expectations and experiences of librarians maintaining both open source and proprietary ILSes, Singh learned that half of survey respondents contact technical support four or more times a month.16

The field has done an excellent job of documenting systems maintenance tasks. These quantitative approaches do not provide a clear picture of qualitative experience. When publications have focused on maintainer experience, they have been the reflections of individual maintainers. This study takes an approach that is both broader than the individual, seeking to identify shared experiences and patterns, yet also sensitive to the qualitative nature of the experiences it seeks to describe. As everyone in the library is affected in some way with the systems being maintained, this article has been written for a broad audience of academic library workers.



In seeking a different way of understanding the work, this project uses qualitative research methods, combining a deductive approach to grounded theory17 with a phenomenological inquiry.18 The research instrument (see appendix) used open questions developed from topics identified in the literature review. Grounded theory’s flexible inquiry, where themes and hypotheses emerge from the data through coding, review, and analysis, was then used to construct themes from the interviews representing shared elements in the performance of library systems maintenance work.19 These themes form the core of the article and identify research questions that could be investigated through larger-scale surveys.


Institutional Review Board (IRB) approval was obtained from Penn State University in June 2020, and interviews were conducted in June and July 2020 and January 2021. Participants were recruited directly to ensure at least two interviewees were included from different institutions currently or recently supporting20 each of the five main commercial ILSes in use at academic institutions in the US over the last decade: Aleph, Alma, Sierra, Symphony, and Voyager.21 Participants were identified through existing relationships, online library directories, and requests to department heads to provide contact information for the person or persons responsible for maintaining the ILS. Workers at twenty institutions were contacted, and representatives of thirteen institutions agreed to participate. In two cases, because of shared responsibilities and interest in the interviews, more than one person at an institution was interviewed for a total of sixteen interviewees.

The sixteen participants came from thirteen universities in the United States. Eleven of these universities are classified under Carnegie Classification of Institutions of Higher Education as R1: Doctoral Universities – Very High Level of Research Activity; the remaining two were classed Doctoral/Professional. Eight were public institutions and five Ivy+ institutions. Of the public institutions, three (all R1s) provide ILS support to one or more smaller institutions.

Participants supported the five main commercial ILSes being used in academic libraries.

Table 1

ILSes Used in Academic Libraries


Number of Participants




Ex Libris



Ex Libris



Innovative Interfaces (III)22






Ex Libris

* In two cases, participants had significant experience maintaining a legacy ILS23 (one Aleph and one Voyager) before migrating to Alma.

Participants had a wide range of experience, from recent graduates to longtime professionals.

As table 2 shows, while the number of years participants spent maintaining the ILS varied widely, they generally had additional years of experience working in other library roles. Notably, only one of the four participants who had spent three years or less maintaining an ILS worked with Alma. That person held a newly created position, while the other three were replacing longtime maintainers of legacy systems (and Sierra).

Table 2

Years of Experience

1–3 years

4–9 years

10–19 years

20+ years

Years as a systems maintainer





Years working in libraries





Table 3

Gender of Participants


Number of Participants







no response


While personal demographic information such as gender was not collected during the interviews, it became apparent when coding the data that women raised the subject of negative affective impact more than men. To confirm this hypothesis, participants were contacted during the writing of this article with a request for gender demographic information. All but one participant replied, and participants’ email responses are represented as “female,” “male,” and “nonbinary.”

Unless gender appears to have a specific bearing on an issue, the neutral “they” is used when referring to individual participants below.


Interviews were arranged with each participant through email and conducted over Zoom, using the research instrument that can be found in the appendix of this article. The primary set of interviews took place in June and July 2020. Several additional interviews were conducted in January 2021 when a gap in representation of experience level in Voyager ILS administrators was identified. Audio and VTT (transcript) files were downloaded from Zoom and stored in a private Box directory, and recordings were deleted from Zoom.

Coding and Analysis

Interviews were coded in NVivo using an open and iterative approach. While cleaning up the automated transcription, recurring topics and themes, such as “amount of time spent working” and “lack of control over vendor choices” were identified. These were recorded in a text file, which became the initial codebook. Interviews were then coded line by line, and new codes were added as needed to express a concept. Codes were organized hierarchically where appropriate. NVivo’s node export was used to generate Word documents with the quotes for each area of coding, which were analyzed further in conjunction with the literature and summarized in a new document, along with illustrative quotations representing each theme.


Five themes emerged from the coding: unpredictability, invisibility/time, collaboration, communication, and affective impact. Just as few jobs can be broken into truly discrete tasks, none of these themes stands by itself. The fifth theme, affective impact, emerged in discussions of the four other themes. The order in which themes are presented below attempts to demonstrate how themes flow into each other, weaving together to create a fuller picture of the subject.

Systems Maintenance is Unpredictable

When describing their regular maintenance work, most participants emphasized its unpredictability. Because a maintainer’s primary job is to keep the system working, minor malfunctions take priority over the long-term projects that provide the most visible evidence of their productivity. Each integration, modification, or enhancement becomes another area that requires monitoring and periodic maintenance. Most begin their day by checking on the outputs of overnight processes or “reports.” If a report failed or contained errors, they will need to investigate the cause and either fix it themselves or file appropriate support tickets. Issues may arise at any time:

It’s not always predictable, both in terms of the basic workload [and] which […] things are going to take a ton of time and effort. We’ve all had this experience where, from the outside some things look easy but they’re really hard. Some things look hard, but in fact they’re really easy.

Systems maintainers receive tickets, emails, chats, and phone calls throughout their day ranging from “the system is down” to “please upgrade [person’s] privileges in __ module.” These might derail days of planned work or be simple fixes, but even the act of monitoring email cuts into one’s capacity for focused work. Such work is never complete, only done for now:

Maintenance work will never go away. Maintenance work increases with external dependencies. Maintenance work doesn’t make a machine better, it just moves the marker a little bit forward.

Another area of unpredictability which surfaced in the interviews was that of vendor-mandated system updates. While legacy systems tend to update in large releases that can be scheduled, the field’s consolidation has led to few newer options. These are only available as Software as a Service (SaaS),24 which means one must work on the vendor’s timeline. For example, Ex Libris pushes monthly updates to its Alma LMS and quarterly updates to the Primo front-end display. Maintainers must monitor product roadmaps, read release documentation, and understand the impact of changes on both technical integrations and tasks performed by other library workers. They must then determine how and to whom the change should be communicated, and whether they will need to update settings or write new code to ensure their colleagues are not negatively affected by the change:

You could have four months in a row with no updates that will really affect people. Then BAM, four months back-to-back of big features.

Even less predictable are the changes to external systems and how these will impact one’s work. Several participants noted that vendors who provide MARC records and other regularly ingested data periodically change their data formats without updating the mapping they provide to libraries. Another needed to drop everything when their university announced changes to its authentication system. Supporting these changes may require anything from a couple days of tinkering to an intense, ongoing project that preempts other work.

If unpredictability is not recognized and incorporated into expectations for the position alongside more visible work, a maintainer’s everyday work may not be perceived as productive. As one participant noted, when one’s email is the place one receives reports from monitoring systems, support tickets, and direct emails from colleagues, watching one’s inbox is a fundamental part of the job:

It might look like you’re not doing anything. But if you’re not paying attention to your email, then [something] could come in and it’s important, but nobody sees it.

Systems Maintenance is a(n Invisible) Full-Time Job

As they outlined the challenges of unpredictable work, participants expressed a sense of accomplishment that comes from their skillset and track records in solving problems for others. Because their work is most often visible when something breaks, however, they feel that coworkers, administrators, and even managers often have little idea of what they do with the rest of their time:

As long as everything’s running smoothly, no one thinks about us. …at some point, they forget that we’re doing a lot of work to keep everything running smoothly. Then you get your directors saying, “Okay, let’s start this new service and let’s start this and let’s do that.” It’s like, hang on, we are spending 60 percent of our time just maintaining and supporting what we already have.

When discussing issues of communication and capacity, three-quarters of participants noted that the frequent invisibility of their work leads to the perception that they have greater availability than they do.25 One participant, who works at a Midwestern Doctoral/Professional-class university, shared that when the one-person system librarian role became a two-person team:

… it seemed to surprise people that there was so much more being done. I think most people were under the impression that the systems person can just handle all the behind-the-scenes stuff and keep things humming along smoothly.

Participants split about fifty-fifty26 on whether they regularly worked more than a forty-hour week. Some occasionally work extra hours but are often able to take comp time in its place or keep the occurrences limited to a couple of times a year.27 Several who do not work overtime emphasized that they had enough possible work that they had to make the decision not to work overtime and that their institution would benefit from hiring another full-time person to do the work. A participant (quoted above) was hired into a newly created position and found their colleagues were surprised by the improvements in the system. Another had managed to cut back on overworking by prioritizing the critical work that they could accomplish in forty hours each week and recording all tasks that they were leaving undone. With the help of a supportive manager, this task list turned into a second position. When describing how their role had expanded over the past two decades, one longtime maintainer said:

…as the library world becomes more complicated and there’s so many new things you can do … EDS and Summon and ILLiad and SFX and CORAL and a million different new things and options. Part of system maintenance is making all these things work together and letting them talk to each other, sending data back and forth to each other.

Participants identified a lack of understanding of what it is that they do as a key contributor to the invisibility of their work. Communicating about technology can be time-consuming work and cut into one’s time to accomplish other things. Nor are such communications requested. The sense that only technology workers can or should be familiar with technology can be damaging at all levels of the library:

I think most library administrators are not going to have come from [systems positions] right? So, if anything, I wish other librarians were more familiar with the way that the systems work together. …if I were going to ask people to learn more, that’s what I would ask.

As the participant quoted above indicates, the lack of familiarity many library workers have with the systems they use every day means many administrators don’t understand a vital service that keeps the library running. Others noted that when a colleague understands elements of a system, they write more helpful tech support tickets and come up with more feasible ideas for improvements. These benefits underscore the collaborative nature of systems maintenance work.

Systems Maintenance is Collaborative

While those with titles like “systems librarian” or “systems programmer” are often perceived as the one person who maintains the ILS, the work of systems maintenance is collaborative. Solving everything from minor bugs to network outages often requires communicating with or requesting assistance from internal and external colleagues. Support work that does not require significant access to the system itself may be distributed throughout the library. A (designated or informal) point-person often troubleshoots their coworkers’ issues with the ILS before the system maintainer gets involved. They may even file tickets on behalf of the department. Such work requires developing an understanding of the ILS as it affects one’s area of work and other skills such as writing a good support ticket. ILS maintainers can improve this decentralized support system through regular communication with the point people.

To receive the support they need, systems maintainers develop a network of contacts across the institution and at vendors.28 In some cases, library IT provides primary support and acts as intermediary between the maintainer and the institutional IT. In others, the maintainer has built their own relationships with the campus technologists who manage everything from enrollment data to server allocation to user authentication. When seeking support outside the library, several participants described the importance of relationships with individuals. In a university IT context, this allowed the individual support contact to learn the specific functions of the library and the eccentricities of library systems. One participant described their institution’s shift from a dedicated person in university IT to a ticketing system as leading to very inconsistent levels of support received.

Vendor support, or the lack thereof, was a consistent pain point in the network. Participants felt they could not rely on the vendor to solve bugs in the ILS in a timely manner. Most expressed a level of dissatisfaction with the support they received. A particular theme was that of a ticket languishing for weeks in the tier-one support queue before escalation to someone who would fix it.29 One participant expressed frustration that only one vendor technician responds knowledgeably to their tickets:

So, when it’s [him] I’m very happy. When it’s anyone else, I feel like I know more than you do about your own systems. …I feel bad saying that but…

Several spoke about the importance of the relationships they developed with individual support workers. Some directly apprised this person of submitted tickets:

…it’s not just “who can I email?” it’s “I need to call up so-and-so and we’ll get to the heart of the matter.”

Two participants described what can happen when such relationships do not exist. Upon beginning their positions, each discovered a backlog of serious, though not catastrophic, tickets in their (different) vendor’s system. These tickets were not only unresolved but had no response or indication whether they had been resolved in subsequent releases.

Others paid for enhanced service levels from their vendor or for direct access to the code so that someone local could fix it instead, or used institutional power to schedule meetings with higher-ups at the vendor to discuss unaddressed tickets. A participant who also supports Ex Libris’s Summon discovery service referenced a frequent practice of emailing the Summon listserv when submitting a ticket as an attempt to enforce transparency about issues they were experiencing. However they noted that this was less productive for their ILS, despite it also being an Ex Libris product.

One assumption made in this interview’s design was that participants received and provided some support through listservs. However, only two participants said that this avenue was important to them. For both, it became important just after migrations to Alma. One noted that “there are always going to be things that another library is going to understand a lot better than a vendor will get, no matter how hard the vendor’s trying.” Two others described peer support networks that had developed with others using the same legacy ILS. The three reasons participants gave for not regularly engaging with listservs were the lack of helpful answers when they had a question, that the vendor could access their backend and fix the code (and should because they were paid to), or a team at their own institution could solve most issues. While collaboration is a core element of systems maintenance work, listservs and cross-institutional support play a smaller role in collaborative communication than anticipated.

Systems Maintenance is Communications Work

The amount of internal and external collaboration required by this role underscores the degree to which systems maintenance requires investing time in interpersonal relationships and communications work:

…people don’t necessarily think about the difficulty in communicating something … complicated and technical to an audience who needs to understand what is happening and the broad outlines of why it’s happening but who isn’t interested in and doesn’t have the background to really get the full technical details [and doesn’t need them].

When asked how much time they spent on communication, responses ranged between 10 percent and 25 percent of a person or team’s time, with some noting a significant increase if meetings and messages about project work were added to maintenance-specific communication. Several noted that documentation work should also be considered communication, as it is a site of effective communication about common tasks and issues. One participant found significant communication and time spent fostering trust was often required to “get others on board” with larger maintenance tasks such as automated data cleanup or batch removal of expired accounts. When describing how they spent their time, another explained:

There’s just so much customer service. I kind of hate that phrase but being a good colleague and doing that internal customer service is [a critical] part of maintenance work.

When a systems maintainer or team neglects interpersonal work and communication, it may damage the relationships that are necessary to successful maintenance work. One newer systems maintainer described the barriers that had formed between an in-group who had been maintaining the system for decades and everyone else. When replacing a retiree, they felt hostility from other members: “uncomfortable to be around, like I am clearly not wanted. Here, you two would rather just talk to each other, [that] kind of thing.” Another newer maintainer described part of their early work as coaxing colleagues back into engaging with the system and with them as its maintainer. Talking and listening was a first step to rebuilding trust:

[Even] if [my] answer was no, they were at least beginning to email. [I became] someone who cared about them enough to say “You’re right that is important. I’m going to work for you.”

From “customer service” to “caring,” communications work included an affective element that was intensified by unpredictability and the sudden visibility of often invisible work.

Systems Maintenance Has Strong Affective Elements

It sucks because I’m responsible for it, but I don’t have any control over it.

A thread that weaves throughout the previous four themes is the strong (and often negative) affective consequences of these experiences. This was the only area of the interviews in which an apparent gender gap emerged. Women were more likely to describe a negative affective burden of being the public face of things one could not control. Specifically, when talking about the inability to depend on timely support from vendors or the limitations of hosted software one cannot configure, half of female participants described negative impact on emotions, mood, or self-perception. One of the female participants reflected:

[a delay in vendor response] really impacts our unit’s reputation within the library but also our library’s reputation within the university.

Several women who support legacy systems mentioned the stress of an anticipated increase in such interactions post-migration, when they would still be learning how to use a new system and have less control because it was Software as a Service. Of the male and nonbinary participants, only one male participant described anything comparable. Another male participant noted that he’s found his colleagues generally understanding that the delay is being caused by the vendor, not him. Because of the small sample size in these interviews and because only half the female participants described this impact, the apparent gender difference is suggestive, but more research is needed. Are there other factors involved, such as an expectation that the women will do more communications work? Does the gender variance still emerge when someone else is responsible for library-wide communication?

Migration and anticipated migration had a mostly negative affective impact regardless of gender. When discussing the possibility of migration from their ILS to Alma or FOLIO, all but one legacy ILS maintainer brought up concerns about how this would impact the service they could provide. “[Coworkers] got really used to having a mature system for 12 years” said one, who worried that people outside the systems department were unprepared for the many complications of a migration. Even when colleagues are understanding, such changes demoralize workers. A participant who had migrated from a legacy ILS to Alma several years before described the stress and sadness of feeling they transformed overnight from a skilled worker who solved colleagues’ problems (a point of pride and part of a strongly positive affect toward their position) to a beginner.

Even when maintainers feel competent in their roles, the element of invisibility described above leads to incidents that harm their morale. Two participants mentioned that their institutions prioritized and praised highly visible developers, even when they had been an equal or primary contributor. As one said:

…nobody mentioned me, nobody mentioned the months that I spent working on this, and my direct supervisor still does not recognize that that work had to be done. Nobody ever knows that my work comes first and then the guy who worked on the website gets to do the cool thing that everyone can see.

Several participants described the difficulty of sharing experiences that generate positive affect, such as pride in a very technical success. Most colleagues could only understand the success in very general terms, and they can only meaningfully celebrate within a very small group of people who are also familiar with the technology. In such a context, a drop in complaints could feel as significant as a commendation:

It does feel like some of the biggest impact. I love that. The best thing I’ve ever heard is that you don’t hate me.


This research suggests that the greatest challenges faced by library systems maintainers are a general ignorance about the nature of this work and an unpredictable swing from invisibility to hypervisibility within the library. When the hypervisibility results from stress-inducing bugs that are outside their control, this hypervisibility leads to negative affective experiences, apparently at a higher-level among women. In some cases, the affective strain results from harsh communications from stressed coworkers. It can also be caused by the maintainer’s dissatisfaction with their inability to help others and questioning their own competence.

The interviews closed by asking participants what they wished colleagues or administrators knew about their work. Answers—which built on the themes of unpredictability, visibility/full-time work, and collaboration—all came back to ensuring that workers have sufficient capacity to maintain and enhance the systems on which the entire library relies. Drawing on these themes, this article suggests necessary steps for developing a culture in academic libraries that better supports all those performing maintenance work.

Unless workers have sufficient capacity for both innovation and maintenance, projects that carry prestige among peer libraries will siphon time needed to support library operations, harming both patrons and workers. Strategic plans, job descriptions, and performance evaluations should consider that maintenance and incremental improvement are at least as important as innovation. Expectations should be set accordingly.

Nor should such commitments be limited to technical maintenance. Support for maintenance must encourage language that re-envisions maintenance in the library as a shared task, on par with other work. Here, the responsibility for culture-building shifts from those with administrative power to library workers broadly. Not everyone can be a leader all the time, yet many workers throughout the library provide underlying support for both critical operations and cutting-edge experiments. Systems maintainers benefit from learning the functions of the areas they support throughout the library,30 but their colleagues may need administrative and cultural encouragement to develop reciprocal approaches, particularly for tasks far removed from their regular work.

Such a shift could have transformative effects in planning and completing work but will also have its challenges. Communicating effectively about technology is a time-consuming process. Those proactively sharing about their work may face an underlying presumption from non-technologists that it will be too complex for them to understand. System maintainers might support this by dedicating some time to coming up with high-level explanations of core work that gradually improve others’ comprehension of the systems. Such communication could be supported by the practice of naming how workers inside and outside the library contribute to the success of its operations. Individuals should be encouraged to identify their own roles as a maintainer, whether of LibGuides, budgets, patron records, or a subject collection.

Learning more about the systems one uses and how they interact with each other gives one grounding to identify improvements one hadn’t previously known were possible. It may also contribute to a better understanding of the collaborative nature of such work and to setting more realistic expectations of what the maintainer can and can’t control. For new initiatives to be successful, one must take into account that every new system, integration, or project added brings with it more maintenance tasks and possible points of failure in addition to the ones already in place. Recognizing the time needed to maintain existing systems and integrations is key to setting achievable goals for projects throughout the library. Nothing is no-maintenance or set-and-forget.


Because these research interviews were carried out during the summer of 2020 and in January 2021, both the participants and researcher were working under the strains of the COVID-19 pandemic. This likely lowered the number of invitees who felt they had the capacity to participate.

In some cases, more than one person from an institution was interested in participating. An attempt to balance these factors was made by ensuring that all major commercial systems currently in use were represented by at least two maintainers at two separate institutions. Any analysis of such rich interviews is also limited by the format in which it must be communicated. Although the five themes identified above capture the core of these conversations, many insights had to be left out of this analysis.

Additionally, participants came primarily from R1 institutions and are thus not representative of maintainers at all colleges and universities. Subsequent research should involve a survey developed from the themes in this work to explore their resonance with the experiences of system maintainers broadly.


Maintenance work can be rewarding. Handling an unpredictable challenge, whether by learning a new skill or drawing on years of experience, can lead to a deep sense of accomplishment. It is often done behind-the-scenes but also deeply collaborative. At the best times, this leads to strong bonds with team members and creates a network of peers who recognize and appreciate one’s successes. It can lead to strong affective responses, which may be positive, such as when one is the face of a success or an improvement that has made colleagues’ lives easier.

The concerns participants expressed—having sufficient time to handle all their work and others not understanding that their varied tasks combine to make a full-time job—arose not from the work itself but from colleagues not understanding the nature of their work. This has consequences from not being recognized for one’s contributions, to feeling judged as “lazy” by coworkers,31 to being overloaded with projects by higher-ups who did not recognize the time commitments required to maintain current systems.

Maintenance work is not prestigious, yet it keeps the library going. It is the author’s hope that this research will lead others to inquire into types of maintenance that support their workplaces. Only together can we build a culture in which maintainers are duly recognized alongside innovators.


The author would like to thank the interview participants for generously giving their time and stories. Thanks to Jennie Levine Knies, Amy Wickner, Vicky Rampin, Hillel Arnold, and the C&RL reviewers for their thoughtful comments on drafts of this paper.


Research Instrument

My research project, “Labor, Maintenance, and Library Systems” (study ID STUDY00015392) has been determined to be Exempt research by the Penn State IRB. Your participation is voluntary, and you may decide to stop at any time. You do not have to answer any questions that you do not want to answer. You can also ask me to turn off Zoom recording for an answer.

I’ll reference this email and confirm your verbal consent during our call. The call will be recorded and transcribed using Zoom software, and then I will complete the transcription and delete the Zoom recording. I will retain the transcription in my institutional OneDrive folder for coding and possible quotations. If you have any concerns about that, we can talk about alternatives. I am including a list of the questions I plan to ask, along with possible follow-ups.

If you have questions regarding your rights as a research subject or concerns regarding your privacy, you may contact Penn State’s Office for Research Protections at 814-865-1775.

Q1. How long have you supported library systems?

Q2. What system do you currently support?

Q2a. How long have you supported that system?

Q2b. Did you support any systems before it? If so, were you involved in the migration process?

Q3. What do you consider core maintenance activities of your position?

Q4. What do those core maintenance activities look like throughout an average month? Do you find yourself working overtime to keep up with them?

Q4a. What do they look like over the course of a year?

Q4b. What do you think core maintenance activities would look like if your department had your ideal staffing level?

Q5. What does maintaining interoperability between library systems look like for you? (e.g., ILS and OPAC, ILS and KnowledgeBase, etc.)

Q5a. How much time do you estimate that you spend on interoperability concerns?

Q6. What does getting external support look like for you (e.g., putting in tickets with vendors, posting to listservs, reaching out directly to peers)?

Q6a. How does availability (or lack thereof) of external support impact your ability to maintain library systems?

Q7. Do you provide external support to others in similar roles, such as answering listserv questions and assisting peers?

Q7a. How much time would you estimate you spend on providing such support?

Q8. How often do you communicate with those outside your department about issues of systems maintenance (responding to tickets, warning of upgrades, planning minor improvements, etc.)?

Q8a. Do you find yourself communicating with the same people over and over or with a wide sampling of the people who work in the library?

Q8b. Do you rely on or communicate with people outside the library (e.g., campus IT)?

Q9. What do you wish that more administrators or strategic planners knew about library systems maintenance work?

Q10. Is there any aspect of library system maintenance that you expected this survey to cover but was not discussed?


1. Devon Olson et. al (The Information Maintainers), “Information Maintenance as a Practice of Care,” Zenodo (June 2019), 11, https://doi.org/10.5281/zenodo.3251131

2. Tim Lynch, “The Many Roles of an Information Technology Section,” Library Hi Tech 12 no. 3 (1994): 38–43.

3. The context of ILS maintenance in public libraries differs too much from the academic context for them to be studied in the same survey. This would be a rich area for future study.

4. This article uses “ILS” as a catchall term to refer to both the ILS and the “Library Management System”/”Library Services Platform” (LMS/LSP). For more on distinctions between the ILS and LMS/LSP, see Marshall Breeding, “Smart Libraries Q&A,” Smart Libraries Newsletter (October 2020), https://librarytechnology.org/document/25609.

5. See Gridium’s interview with Lee Vinsel for an exploration of the complementary and dichotomous relationships between maintenance and innovation at https://gridium.com/lee-vinsel-maintenance/.

6. This section uses the article’s term for the systems maintainer, most often “systems librarian.”

7. Ayoku A. Ojedokun, Grace O. O. Olla, and Samuel A. Adigun, “Integrated Library System Implementation: The Bowen University Library Experience with Koha Software,” African Journal of Library, Archives & Information Science 26, no. 1 (2016): 31–42. The authors seek to remedy the lack of literature on day-to-day systems work. They draw on nine years of quarterly and annual reports to identify recurring issues and specific incidents.

8. Hong Xu and Chen Hsin-liang, “Can We Meet the Challenge? The Educating Systems Librarian Research Project Report 3,” The Electronic Library 19, no. 5 (2001): 315–26, https://doi.org/10.1108/02640470110408896.

9. Janet Guinea, “Building Bridges: The Role of the Systems Librarian in a University Library,” Library Hi Tech 21, no. 3 (2003): 325–32, https://doi.org/10.1108/07378830310494508/

10. Lisa Tyson, “Library systems teams—more than just peripherals,” Library Hi Tech 21 no.3 (2003): 317–24, https://doi.org/10.1108/07378830310494490.

11. Susan Baerg Epstein, “Maintenance of Automated Library Systems,” Library Journal (December 15, 1983): 2,312–13.

12. Merri Beth Lavagnino, “Authentication, Bandwidth, and Collaboration: The Library Systems Directors’ ABCs,” Library Hi Tech 17, no. 4 (1999): 396–402, https://doi.org/10.1108/07378839910303054.

13. Marshall Breeding, “Knitting Systems Together,” Computers in Libraries, 29 no. 9 (October 2006): 32–4.

14. David Ratledge and Claudene Sproles, “An Analysis of the Changing Role of Systems Librarians,” Library Hi Tech 35, no. 2 (2017): 303–11. Youngok Choi and Edie Rasmussen, “What qualifications and skills are important for digital librarian positions in academic libraries? A job advertisement analysis,” The Journal of Academic Librarianship, 35, no. 5 (2009): 457–67.

15. Tyson, “Library Systems Teams,” 321.

16. Vandana Singh, “Expectations versus experiences: librarians using open-source integrated library system,” The Electronic Library 32 no. 5 (2014): 695, https://doi.org/10.1108/EL-10-2012-0129. These requests may not all be to the same vendor/for the same system.

17. Kathy Charmaz, “Grounded Theory,” in The SAGE Encyclopedia of Social Science Research Methods, eds. Michael S. Lewis-Beck, Alan Bryman, and Tim F. Liao, (Thousand Oaks, CA: SAGE Publications, Inc., 2004): 441–44. https://doi.org/10.4135/9781412950589.n381.

18. J.W. Creswell, Qualitative Inquiry and Research Design: Choosing among the Five Approaches. (Thousand Oaks, CA: SAGE Publications, Inc., 2013): 76–83.

19. The phenomenological elements were inspired by Kaetrina Davis Kendrick’s phenomenological approach to the study of low morale. “The low-morale experience of academic librarians: A phenomenological study.” Journal of Library Administration, 57 no 8 (2017): 846–78, https://doi.org/10.1080/01930826.2017.1368325. Kaetrina Davis Kendrick and Ione T. Damasco, “Low morale in ethnic and racial minority academic librarians: An experiential study,” Library Trends, 68, no2 (2019): 174–212, https://doi.org/10.1353/lib.2019.0036. “The public librarian low-morale experience: A qualitative study,” Partnership: The Canadian Journal of Library and Information Practice and Research, 15 no. 2 (2021): 1–32, https://doi.org/10.21083/partnership.v15i2.5932. The author was also influenced by her spouse, Micah Tillman, whose PhD work on phenomenology has brought its concepts and terms into her everyday life.

20. As Ratledge and Sproles found in their analysis of job postings from 2014 (published 2017), the actual tasks of a systems librarian (or equivalent) vary widely. Qualification for inclusion in this study was a position that included responsibility for managing at least some parts of the ILS.

21. For numbers of active installations, see Marshall Breeding’s annual report in American Libraries https://americanlibrariesmagazine.org/tag/library-systems-report/.

22. While this survey took place shortly after III was acquired by Ex Libris, this had not yet impacted participants’ day-to-day work.

23. A legacy ILS is one which is still used by many libraries but is no longer the focus of the vendor’s active development work. In this study, that includes Aleph, Symphony, and Voyager and, with Ex Libris’s purchase of III, may soon include Sierra.

24. Joseph Koivisto, “The narrowing field: The interrelationship of systems librarian training & ILS marketplace consolidation,” Journal of New Librarianship, 3, no. 2 (2018): 202–5. https://doi.org/10.21173/newlibs/5/6

25. Respondents who did not discuss perceptions of their availability came from well-staffed departments. One added that they did not think the institution understood how much work would stop being done if they lost staffing levels.

26. Several participants who normally worked forty hours/week added that periods of the COVID-19 pandemic pushed them well in to fifty- and sixty-hour weeks. I did not mark them regularly as working overtime but consider this worthy of a note.

27. Despite a major shift in the kind of work being performed (c.f. Ratledge and Sproles, 2017), this is similar to Muirhead’s 1991 survey of 416 UK systems librarians, which found that 62.8 percent regularly worked overtime and 32.3 percent occasionally did so. Graeme A Muirhead, “The Role of the Systems Librarian in Libraries in the United Kingdom,” Journal of Librarianship and Information Science 25, no. 3 (September 1993), 129. https://doi.org/10.1177/096100069302500303. Special thanks to the Penn State Libraries and UW-Madison library ILL teams for a color scan of figure 5, which contains this data. The publisher scan was of unusable quality.

28. Tyson, “Library Systems Teams,” 321.

29. This experience is also reflected in Singh’s responses from non-open-source ILS maintainers, “Expectations versus experiences,” 697–8.

30. Guinea (2003) and Tyson (2003).

31. While multiple participants expressed variations on this concern, none recounted instances where a coworker stated or implied that they weren’t doing enough work.

* Ruth Kitchin Tillman is the Sally W. Kalin Early Career Librarian for Technological Innovations at Penn State University Libraries and the product owner for Discovery; email: rkt6@psu.edu. ©2023 Ruth Kitchin Tillman, Attribution-NonCommercial (https://creativecommons.org/licenses/by-nc/4.0/) CC BY-NC.

Copyright Ruth Kitchin Tillman

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

Article Views (Last 12 Months)

No data available

Contact ACRL for article usage statistics from 2010-April 2017.

Article Views (By Year/Month)

January: 1200
February: 238
March: 421