Sabina Pagotto

(This is not about AI. I mean, I think my bottom line does still apply to AI, although sideways from the examples discussed in this post. But we’re at a point where any time I talk about technology I feel like I need to clarify.)

So here’s a thing that feels obvious to me but seems to bear repeating: technical problems are rarely about the limitations of technology.

I mean, yes, there are some things we (as a society) simply do not have the technology to do, like teleport, or cure certain diseases. But most of the things we (as a profession) would like to do in libraries are not actually limited by technological possibility. (They may be limited by what technological products are available to us at a reasonable price point, but that’s not really the same thing.)

I say this because sometimes I think vendors try to gaslight us into thinking that their software doesn’t include features XYZ because they are impossible to develop under the circumstances, when in reality their software doesn’t include those features because the vendor, for whatever reason, can’t or doesn’t want to go to the effort to develop them. (And sometimes they are very good reasons, like that the development would be prohibitively expensive or would have some other consequence. But I would trust them more if they were a bit more honest about the trade-offs they’re making instead of saying things that make me want to weep into my annotated desk copy of the ISO 18626 standard.)

The example of this that has been percolating in my head lately, and one where we’re not dealing with vendor gaslighting but rather a genuine knowledge gap, is full ebook interlibrary loan. People have been thinking about full ebook ILL for a while, and for a long time the sense I had was that they thought it would be technologically difficult to accomplish. Not so! Full ebook ILL is not meaningfully harder to do than article ILL (document delivery) + some extra DRM stuff, both of which are things we’ve been able to do easily online for at least 20 years. So why are we not all ILLing ebooks left, right and centre?

The first roadblock is licensing. Ebooks are governed by licenses, and even having a perpetual access ebook purchase doesn’t entitle you to do whatever you want with that ebook the way having a print book purchase does, partly because a lot of stuff that you might do with an ebook would create a copy of the file, even an incidental one — very different from a print book that you’re unlikely to accidentally photocopy somehow. (Longer copyright digression cut for time.) So, before you can ILL a full ebook, you have to know that you have the license rights to do so. And if none of their customers are allowed to ILL a full ebook, why should vendors invest in the development required to support ebook ILL?

The second roadblock is investing in development. Unless you are operating under the zero-DRM, just-send-the-whole-PDF ebook lending model (which is very easy from a technological standpoint but a harder licensing concession to get), there is a good chance that any ILL access you provide to the ebook will have to be on the ebook vendor’s platform. In that case, you need the ebook vendor to support that functionality. You probably also need your ILL vendor and your ebook vendor to coordinate enough to pass the request and the ILL access link between their systems. These things are technologically doable, but require some investment in development on the part of the ebook vendor which they may not be incentivized to do. They also probably have little or no incentive to cooperate with your ILL vendor at all, unless you threaten to take your business elsewhere. Or, alternate possibility: your ILL vendor has to build in a hosting platform for temporary ILL access to ebook files you’re retrieved elsewhere.

(As a sidenote, this second roadblock is why Clarivate was able to pretty quickly develop ebook ILL functionality with ProQuest ebooks and Ex Libris ILL systems, because it’s a library megaconglomerate that happens to own the correct combination of library corporations that allows it to face only half the roadblocks in this scenario. Unlike, say, OCLC, who doesn’t own an ebook platform, and therefore has to go down the alternate possibility route.)

This is true of other things too, like, for example, Why Tipasa and Rapido Can’t Just Talk To Each Other (to stick with ILL examples). Making that happen would take a fairly significant investment in development on the Tipasa (OCLC) side, some investment on the Rapido (Clarivate/Ex Libris) side, and a whole lot of two direct competitors collaborating and working together and making compromises. (My understanding of the systems is that the Tipasa side would take quite a bit more investment and compromise than the Rapido side because of how the two systems were initially designed, which points to some underlying differences in history and philosophy between the two companies, but that would be a whole different post and/or drunken rant.)

When it comes down to it, most problems that look like tech problems at first glance usually come down to some combination of:

• lack of capacity or incentive to invest in development
• rights, policies, or laws that block a particular development
• organizations (including but not limited to vendors) not wanting to work together
• people disagreeing on the best path forward (sometimes because there are unintended consequences to doing the thing you want to do!)
• capitalism (usually in the mix there somewhere)

All of which, at the end of the day, basically boil down to people and money. Like Fred pulling off the ghost costume at the end of an episode of Scooby-Doo to reveal a crooked businessman underneath… Tech problems almost *always* have people or money problems behind them when you take a closer look.

Anyway. Happy Halloween!