7 January 2010
So my husband (a software engineer) and I talk a lot about this library stuff, duh, and it’s useful for exposing underlying assumptions that differ between these two fields of information geekery…
One of the things I’ve been thinking about is the structure of open source development communities. I’ve run Linux (albeit no more) and a lot of my friends are the kinds of codemonkeys who will merrily write a script when the world doesn’t do something they want it to do. I’m used to thinking of open-source development as people encountering things that are personally bothersome and fixing those themselves, when the software in question is something computer geeks use — Linux, Apache, funky lightweight apps to do whatever, et cetera.
But the assumptions in my head about how Koha and Evergreen and OPALS are developed are, I realize, different. I think of integrated library system development and I think of a small number of coders — from library consortia, academe, and ILS support companies — contributing to the codebase; I think of the vast majority of (potential) users as simply not having the ability to do that. In other words, I think of there being some latency and information loss in the communication between user and developer in a way there’s not with, say, Linux (where user and developer are the same person). In fact I imagine it must go both ways — that developers are not necessarily embedded in a library context (e.g. if they work for support companies) and therefore may not be heavy users of the system, and may not be developing that sort of intuition for the workflow imposed by the system.
Am I right? Am I wrong? Because I really have no idea, and it’s fun to use the blog as a way to learn things. (Thank you to all my lovely commenters who have pitched in on this. 🙂
It seems to me the nature of an open source development community, and the possibilities for the software, must be interestingly different depending on how greatly the user and developer communities overlap, but I do not really know how (aside from the suddenly crucially central role of support companies in the low-overlap case). Certainly, though, the idea that if software is broken or stupid you cannot just write something to fix it is a paradigm shift for software engineers, but not for librarians, which does complicate some of these conversations.
16 December 2009
So apparently LibLime (a support vendor for Koha, a major open-source ILS) has done a bait and switch — people who signed up for Koha support are in fact getting a vendor-specific, only-sorta-open version of the software.
I’ve been having unkind words about LibLime percolating in my head for a week which I’ve been not posting here, because I try not to be an unkind-words sort of person. But I no longer feel restraint about that.
So here’s my experience with LibLime:
They deleted my, and all my classmates’, final projects (Koha demos which they were hosting). The day before they were due.
A miscommunication was involved, and it can’t be said to be entirely Koha’s fault. The demos had been, properly, on a deletion list. But they also deleted them without notifying their client in advance. Or…noticing that there had been a tremendous amount of activity on these sites. Or, indeed, noticing that they had had support transactions on those sites within the last few weeks.
(This was ironic as part of my group’s conclusions about Koha is that you shouldn’t run it unless you personally are very comfortable with a Linux command line, or have a close and trusting relationship with an IT department or hosting company. So much for that plan…)
In addition, the demo sites they gave us were missing some very important functionality, and they couldn’t figure out how to fix it. I figured out how to fix it. Let’s keep in mind here that I’d never worked with Koha before this term, and the documentation…well, isn’t ideal, let’s say. I couldn’t implement (or verify) my solution because I didn’t have access to a command line, but I could use the knowledge to figure out a hack I could implement from the front end which got it working well enough for our purposes.
So for those playing along at home: yes, that means the person totally inexperienced with the software and without access to the command line diagnosed and fixed the problem before the person who gets paid to do that.
LibLime…oh, LibLime. I want there to be inspiring, kick-ass open-source support companies for the library world. I want open source to be able to offer both market and conceptual challenges to traditional software. I want the library world to have the agility that open source offers to try new tools and new paradigms. None of that is going to happen without quality support. That support, alas, is not you.
12 July 2009
The part I’ve been munching through: apparently it’s really, really hard for libraries to keep track of their electronic serials and database usage. If you want to know which of the things you’re subscribed to are actually getting used and how (and what it’s costing you), strap yourself in for a long ride, because ILSes don’t have rich enough functionality to harvest that information for you. Some people buy additional systems on top to help, but even those require a lot of work if you want to extract useful data.
There are some good reasons for this. Libraries frequently subscribe to databases or journals as bundles (and may be required to do so by the publisher), and the usage codes may not disaggregate resources within the bundle. Libraries may subscribe as part of consortia, but need to extract data for their individual institution.
Still, though. This seems like a pretty obvious thing to want to do — keep track of your actual use! So why do the tools not support it? I welcome ideas from people who actually know something (which is not me!), but in the meantime, I’ll brainstorm some possibilities…
- It’s a genuinely hard technical problem. (And there are a lot of problems that need to be solved here — not just capturing the data, from subscription systems that apparently don’t natively provide it, but organizing it into a database that answers users’ questions, has a usable front end, and spits out data in formats useful for budgeters and other decisionmakers. That’s not one system — that’s multiple interacting systems, possibly produced by different organizations — and potentially problems that have to be re-solved for every database vendor and ILS combination. OK, it’s even harder than I realized when I started this bullet point and was just thinking about algorithms.)
- Libraries don’t prioritize recordkeeping and review of their serials and databases enough to exert pressure (market, social, cultural) on companies to develop this feature.
- ILSes offer a tremendous number of features; while libraries might want better serials tracking, they care more about those other features, so it’s those things that ILSes are competing on. (Although this doesn’t answer why an ILS that does well on those things, *and* on serials, doesn’t emerge and stomp on its competitors. But maybe it’s too hard (algorithmically or monetarily) to do that.)
- This is a place where the culture clash between librarians and programmers is showing; maybe they just aren’t talking to one another enough for the user needs to become apparent. Again, you’d think this would be a place where the company (or open source project) that does do a good user needs analysis to eat its competition — and there are niches where librarians and programmers overlap — but all too often they don’t seem to even have a common vocabulary.