No Such Thing as a Free Lunch : Labor in Open Source Systems Implementations

This post is adapted from a presentation I gave at the Amigos Library Technology Roadmap conference earlier this month.

I supervise the library systems unit at a public R1 university library that is part of a small local consortium of colleges. This post is about labor in open source systems implementations. I’ll outline a common pitfall, explain why I think it happens, and then give you some ideas for mitigating it.

First, let’s check in. Have you done a systems migration or implementation recently? Which systems did you migrate to? Were any of them open source? Did your library hire any additional staff for that project? If so, what were their roles and duties? Were they temporary or permanent staff?

To answer all these questions myself, in my current role we’ve just finished migrating from Aleph to FOLIO, which is open source. There were other, smaller implementations that went along with our FOLIO migration, such as EBSCO’s FullTextFinder, which is not open source. In a previous position, I worked on migrating from DigiTool to Rosetta, which is a proprietary system owned by Ex Libris. In both instances, we hired a project manager to a permanent position, who then transitioned to a systems librarian, basically, for that system once the implementation was finished. We did not hire any temp or project staff. [n.b. Both of these systems migrations were for consortia, and I recently wrote about them in Project management in technical services : practical tips and case studies, ed. by Elizabeth German & John Ballestro.]

Since we’re specifically talking about open source software, let’s make sure we’re on the same page about what “open source” software is. “Open source” means that the software’s source code is freely licensed and available. The freely licensed part might be done under various models, such as copyleft, creative commons, public domain, etc,. The downstream effects of that license include:

Free as in pizza
Ability to modify
Ability to redistribute
Decentralization & collaboration
Security

It is impractical to charge for software that can be gotten for free. Users can modify, copy, and redistribute the code.
It also results in decentralized and collaborative software creation and maintenance efforts, since anyone can contribute.
High levels of security results from having many eyes on the code & the ability for users to examine the software & know what it’s doing — unlike proprietary software, which is often quite opaque.

Many of the most interesting and useful new library systems are now open source ones. These aren’t just ILSs; they include next gen ILSs or LSPs (that’s Library Services Platform, which is what we seem to be calling new ILSs these days), OPACs or discovery layers, ERM tools, and special collections front and back ends. Examples of all of these include:

Even just from this list, we can see open licensing in effect. Aspen is a modified and redistributed version of VuFind, and both are OPAC-like discovery layers. Because VuFind is open source, other developers were able to use its code to create something that is similar but not exactly the same, and to distribute that new software. This results in more libraries’ needs being better met, as some may prefer VuFind while others may prefer Aspen.

For all those reasons resulting from the software’s open or free licenses, we can easily see why libraries might choose open source systems. Free is an attractive price tag. You might be able to better meet local needs than with proprietary softwares, which limit what can be configured or customized. And open source software may align well with your institution’s mission & vision, especially in areas of transparency, privacy, and the public good.

Hosting & support options now make adopting open source software easier, compared to when local hosting was our only option. Sometimes you can get the same software from different hosting vendors, such as picking between EBSCO or Index Data for FOLIO hosting. Or, a library can pick only hosting services or only support services. Software as a service (SaaS) is the going model of enterprise software in many industries, including libraries & education, and using open source software no longer means you need to spin up your own servers.

Those are all really good reasons to choose open source software. Especially under austerity budgets, “free as in pizza” is a nice price. But opting for open source over traditional proprietary library software is not a simple 1-to-1 substitution, even though we often pretend it is. It’s actually an entirely different beast in lots of ways. From here on out, I’m going to talk particularly about labor.

Exchanging proprietary library systems for open source ones is not a 1-to-1 substitution in large part for reasons relating to labor. Open source softwares are often chosen because of — perceived or real — cost savings. Cost savings calculations need to account for the different & increased labor necessary to open source software projects. This doesn’t always happen. I suspect it almost never happens. And, if your library undertakes a large project, staff cannot work on that project while also performing their regular duties. Without reduced duties or additional staff, either regular or project work will be undone or done poorly; staff will be overworked; and the project will exceed projected timelines & resources. In combination, these produce a perfect storm of burnout.

The main factor, as I see it, in this overwork (the neoliberal capitalist garbagefire hellscape we exist in aside) is that open source systems and their implementations have different labor needs than proprietary ones. There are two reasons for this. First, open source systems implementations and maintenance require an expanded digital skillset. Here are some examples:

PHP
UX
Linux
JavaScript
GitHub
Ruby on Rails
Okapi
SQL
APIs
Python
Drupal
OAI-PMH
RegEx
CSS
JSON
XML
Java

You probably won’t need all of these, but you definitely will need some of them. These are skills that are not usually included in librarian training, but will need to be found somewhere in your organization. And you will need these even if your hosting & support is farmed out. Even though my library’s FOLIO instance is hosted by EBSCO, in our FOLIO implementation we’ve needed APIs, Python, JSON, SQL, and probably others. This is not even to mention the “soft skills,” like communication, documentation, project management, or change management, all of which are actual skills, and not just something we automatically know how to do well, simply because we work in a feminized helping profession.

The second problem is time. Above is a pie chart showing the time members of my technical services department was devoting to our FOLIO implementation in late 2019. It averages out to everyone involved in the project spending just over twelve and a half hours a week, every week, on tasks related to the implementation. You probably already have more work than you can do in your workweek. Do you have time for 12 more hours of work every week? Are you going to be able to give up any current tasks to fit 12 hours of systems migration work into your week? Who will do those things instead?

You have a time problem with proprietary software as well, but I want to highlight from this figure what some of the specific work for an open source software implementation might look like. You’ll recall that I mentioned decentralization and collaboration above. The blue pie slice, which is about a quarter of the time, was for “special interest group meetings.” This is the time that we spent working directly with the rest of the FOLIO community — developers and other libraries that were implementing the system. This is not something you have to do for proprietary software. This work is also ongoing; for example, right now, several months after our FOLIO go-live, I’m participating in a task group that is coming up with suggestions for development that will make FOLIO talk to discovery layers better.

This is just math. Can you really do that much more work? Can you do it possibly for a couple years? Because that’s how long some of these projects take. As an early adopter of FOLIO, the implementation & migration at my library took four years.

And this is exacerbated by the already dire state of labor in libraries. Between retirements and pandemic attrition and budget cuts, a lot of us already have franken-jobs that used to be done by multiple people. A lot of us are already overworked and burnt out by doing those jobs, especially as we close in on the end of pandemic year three. (As a humorous example, unless you work there, the worst franken-job I’ve seen lately was a Korean Studies & Dentistry subject liaison position. I promise you that’s real job, I read the ad myself, and you know that used to be two positions.)

So, think about it. Can you do 12 more hours of work a week, every week? Possibly with skillsets you don’t yet have? For several years?

Given all those things, there are only a few solutions, and your C-suite probably won’t like any of them. You could…

Hire new or project staff to who have the required skillsets.
Hire new or project staff to cover regular duties if existing staff have the required skillsets.
(Be sure that either existing or new/project staff have appropriate skill sets for the project!)
Accept that the project cannot happen at this time, at current staffing levels.

And that’s it! There is no solution that doesn’t involve more staff & appropriate skillset; gets both regular & project work done; and avoids overwork & burnout. Which leaves us with…

How?

How do we do enact any of these solutions? I have a couple ideas.

Intervention #1: Evaluation of systems & the RFP process.

This is prevention, and an ounce of prevention is worth a pound of cure. Labor questions need to be included in RFP processes & project proposals.

Include questions to vendors about staffing & skillsets needed.
Talk to other institutions to find out the real story, not just the vendor!
Look for institutions that have staffing & funding similar to yours.
Ask about how long projects take — at different levels of staffing.

Plan these questions into your RFP process. Get this information in a formal manner, and base the decision about which system to adopt on the answers. The questions should get you information about the skillsets and time needed to implement the software.

And remember that the vendor’s job is to sell you their product, so take their answers with a grain of salt. Sales reps may even tell you things that aren’t true. Not necessarily out of malice, but in my experience sales reps do not know the answers to technical questions — and, again, their job is to make you want to buy their product. Ask the technical questions to the technical people at the vendor, not to sales reps. Definitely talk to other libraries who have already adopted the software, and be sure you talk to libraries that are like yours. Is your library withering under austerity or does it have money to throw around on developers? Is your staff big or small, and do you already have developers and IT staff? Public or private? Don’t ask an Ivy about how hard a project was if you’re a cash-strapped public institution. What worked for them may not be possible for you.

Intervention #2: Labor.

If prevention doesn’t work, we’ve got intervention number two. We can’t reasonably be expected to take on project work. A lot of our bosses will try to make us do it anyway.

Do you have a union & collective bargaining agreement? Use it.
Don’t? Consider unionizing — this is a great moment for it.
“Which of these tasks are we hiring new/project staff for?”
“Since I already have a full plate, which of my current responsibilities are we going to pause for the duration of the project?”
- Don’t ask a yes/no question.
- Ask as if you assume it will happen.
- We language.

“Library nice” gets leaned on to exploit us as workers, and your best response to that informal power that is to flex formal power. If you have power from a union and a contract, use it, even if it’s scary. Build it if you don’t. Right now is the best moment we’ve had in years to build labor power in libraries, and you will find a lot of support for an organizing effort.

And also flex your own soft power. I’ve given you a couple script examples of things you could say to a manager. Asking what tasks you will be pausing for the duration of the project, as if you were certain that’s what would happen, can work. Be better at communication than your C-suite. Don’t ask a question that readily allows for “no” as an answer. Use “we” language to make them feel like you are figuring it out together. And use that guilelessness to keep yourself safe if you feel like conflict won’t be productive.

Lastly, if neither of these work, there is a secret third thing. Remember that there is no such thing as a bibliographic emergency. Let that open source software implementations take as long as it needs, to get done in everyone’s 40 hour work weeks. Grow a spine, quit and get a new job, or tell your boss — honestly & kindly — why the project is failing. All of these will take bravery, but the payback for bravery, especially when paired with the open source softwares that have the potential to open up the library software marketplace beyond the same three companies we all buy software from now, is a better profession and better libraries.