Librarians and Open Source: We Need Code, Too!

We Need Code For Ourselves

Vendor Options Are Sometimes Not Helpful

Bad Vendor Options - collectionhq

Let's have an example of a regular library problem that could be helped greatly with access to code and development tools. There's some form of SQL database behind all the item and bibliographic records for each of the objects in the library system. Librarians and those in charge of the collection often have to make decisions about what to keep and what to discard in their collection based on the number of times an item has or has not been checked out, and whether those checkouts are recent or old.

Until somewhat recently, my library subscribed to a service called collectionHQ, which processed our records and generated a set of reports for us in our various categories. The two reports most used were:

  • Grubby Items, those that had a high enough lifetime circulation count that they might need replacing on their condition
  • Dead Items, which were items that had not circulated in a set period of time.

Global Variable Setting in collectionhq

The limitations of the system were pretty apparent once we started using them. collectionHQ only allowed us to set global values for collections with regard to when they were grubby, and a global value of inactivity across all collections to see when they were dead. So as soon as an item hit the threshhold for circulations for its collection, it would be on the grubby list, regardless of whether it had been mostly handled by people who were rough with their books or gentle. If an item hadn't circulated in the amount of time that the dead list prescribed, it was dead and appeared on a list to be weeded. That length of time was usually about 180 days, so a work would need to circulate approximately once every six months to avoid getting on the dead list.

As one might guess, neither of these options was particularly effective - many "grubby" items that had been well taken-care of would have more than a few circulations left in them, and many "dead" items were classics, assignments works, or had been really popular at the beginning of the year and were having a lull at that particular point. Or had just been recently added to the collection and were still winding their way through their popularity points. Things like the seventh copy of The Hunger Games would show up as a dead item, despite the series itself having circulated 75 times to that point in the year. The item that needed to be gone was likely the first copy, the one that had been read and checked out the majority of those 75 times, but because it was being checked out, we would have to wait for it to appear on the "grubby" list before the system would believe it was ready for anything. And while we could delay the reappearance of an item on the grubby list by up to 40 circulations (in increments of 10 only), there was no such cure for the Dead list except to think about checking it out and then back in so that it would have a circulation to count against being dead.

collectionHQ did have a useful feature, in that it would allow one location to request another location's dead copy to replace a grubby one of their own, but after the first few times, the collection had shifted to where it was going to stay and nobody was really in the market for trading as the larger locations settled into requesting the copies of the smaller locations to replenish their own higher-circulating stocks. Our selection team and already established processes could replicate that, and in a far more granular manner.