12.16.09
I even really like citrus fruits! And yet.
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.
(via Jessamyn West; Nicole Engard, the author of the bait-and-switch post linked, is also a regular on the thought-provoking Library 2.0 Gang podcast with all sorts of library-luminary names)
07.12.09
why is serials recordkeeping so problematic?
I’ve been reading this post, from the charmingly named In the Library with the Lead Pipe.
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.
Ideas?
