A chance encounter with Equinox COO Grace Dunbar can make conference downtime into the most interesting session of the week. Rather than relying on fate and the hotel bar to ensure a chat with Grace, I asked her if she’d let me interview her for TechSource at this year’s Evergreen conference. In the course of conversation (sometime after she introduced me to pimiento cheese), Grace mentioned that she had worked at Stanford and been involved in the Google Books project. That’s about when I brought my laptop out
KS: What was it like to work with the Google Books Project?
GD: At times, it was like working in manufacturing. The idea, of course, was to make a whole bunch of resources available for discovery. Our students are going to Google and Google can do keywords in context in a way that we can’t. But the mechanics were difficult.
We would check out a bunch of books in batches with these little handheld devices, but because we were so physically close to Google, by the time we found any problems or exceptions, the books were across the bay. We worked a lot with Google to figure out logistics- instead of sending items by quantity, we started sending by linear feet.
KS: Wait, how does that help?
GD: Google originally wanted items by quantity, which made sense when we were sending monographs or bound serials. But once we started sending pamphlets…
KS: Oh, I see. 1000 pamphlets looks very different from 1000 books. Did you personally have any reservations about working with a big company like Google instead of, say, doing it yourselves?
GD: It would be perfect if we could do it ourselves. There’s a point where you need to take advantage of what a business can offer you. You need to be smart about the contract. We still own the physical item, we will get a copy of the digital version, and we decide if the quality is good enough. If it’s not, they have to rescan it. But it’s better to have things digitized in a non-archival copy than not digitized at all.
Really, it’s about mutual beneficiality. Google wanted something, so how does the library leverage what Google wants in order to get what it needs without sacrificing library ideals?
KS: Leveraging what other organizations want in order to get what the library needs without sacrificing ideas seems like a good way to think about any partnership with a business. In the case of Google, we’re sort of relying on them to live up to their “don’t be evil” mission.
GD: Google didn’t do anything evil. What was their long-term plan? They’re obviously ingesting as much content as they can and working it into their e-book retail venture, Google Editions. They’re clever and they’re profitable. But I don’t begrudge them that.
KS: It seems like your Google Books experience overlaps with the library open source world in that it requires both the 30 thousand foot view and the ability to focus on the nitty gritty – like barcodes and book counts. Librarian street cred tends to venerate details. We often resent the big-picture view after a while, unless it gets connected to the front lines. Even though I am a huge fan of open source, I tend to gravitate towards the practical over what my ideals tell me is best. I feel guilty for not being 100% open source.
GD: Our developers have a mantra: don’t let perfect be the enemy of good enough. We’re not coming down the mountain with stone tablets. We’re excited about open source, not evangelical.
KS: I think that can be the Achilles heel of open source in libraries – it can feel Important.
GD: There’s a line between practicality and evangelism. You can be an advocate for open source without falling into the pitfall of being blinded to practicalities. Open source is not for everybody.
KS: Who is it not for?
GD: It’s not for an organization that’s already in flux. Don’t add this on top of a whole lot of other change. It’s not for tremendously change-averse organizations. It’s not for people who think it will save them money this year or next year. There will be cost savings, but probably not in the first two years. There are always costs with a new ILS or new consortia. Training, migration costs, those are still there. It’s a tough concept.
KS: Folks who are plugged into the open source world in libraries may be over talking about kittens and beer but you’re saying there are still a lot of people out there who don’t understand the change in costs with open source. Do you think it’s mostly smaller, understaffed libraries that don’t have the time to invest in learning about open source culture?
GD: A smaller library will see cost savings sooner and they can be much less change averse – if it’s three people who have made the decision together to move to open source, they are in it. Our smaller libraries are usually more successful right out of the gate, actually. Overall, people complain about stuff in open source that they complain about with proprietary systems, but the open source part gives them something new to complain about.
Open source doesn’t give you the blame contract you had before. It does give you someone on your side to help you through the rough patches.
KS: 2010 was a big year for the Evergreen community with King County Library System (KCLS) going live on Evergreen with support from your company. They’re known for being an ILS killer because they’re so huge. From an outside perspective, the go live seemed a bit tough, especially for the OPAC. Should they have waited, or is that just armchair quarterbacking?
GD: KCLS was brave to set a date and stick with it. Once you push back your go live, the doors open. Once you wait three months, there’s something else. We brought them up on Evergreen and they never went down, as they did with their previous ILS. They are an ILS killer, so everyone was really happy with that. Their materials handling robots worked well with Evergreen, and KCLS did such a good job of provisioning their system. The database had no trouble keeping up with their high volume, although we fought through a few issues with SIP lag. But, of course, the most external facing thing is the OPAC.
KS: We all want our own systems to be judged by what we’re experiencing as staff, but we feel pretty free to judge other systems based solely on their OPAC. How did the KCLS OPAC come together?
GD: Equinox didn’t feel like they had the bandwidth to take on the OPAC project. Also, we wanted to work with someone who had the aesthetic skills to make the OPAC shine. KCLS allowed multiple vendors to bid on the RFP. Equinox has the most experience with the backend, which for the OPAC would only require API calls. If they needed new backend functionality, Equinox could create it, but most of the features KCLS needed were already available in API calls.
KCLS worked with a design company that had never worked with libraries but were amazing designers. I think the main issue was that the timeline was very short overall.
KS: Bringing in designers from outside of libraries seems like a big plus – you won’t just end up with an OPAC with rounded edges, you’ll (hopefully) get a really great design.
GD: Exactly! With an open ILS anyone with the skills can make it better. You and I have talked before about open source ILS being new but still needing to do the same things all ILS need to do. There’s always been concern in the open source community that we are simply recreating what we already had. But that openness really does make a difference. Also, we may be reinventing the ILS, but we’re inventing now, not thirty years ago. Anyone can make this better and it’s critical to bring in nonlibrary people.
Outside organizations can also offer much needed perspective, especially in the public-facing arena. Libraries struggle to communicate what we have to offer to our patrons. There are people out there who can help us with that. We can pay them once and have all their work be free. Everyone wants to make their patrons happy. There are people out in the world who are good advocates for patrons. We can hire them to help us.
It’s great to bring in more vendors, but in the KCLS case, the timeline caught everyone. There were things that were complete but untested and you can’t go live with things that aren’t tested.
In hindsight, it’s easy to say we should have gone live with the native OPAC. If there was enough time and we could have informed the public and given them milestones for when the functionality they expected would be back. But we have to try things to know which approach is best. We would have had to know ahead of time that the skins wouldn’t handle the production load with grace.
KS: It’s always easy to say we should have taken a different path. But by the time that path is clear, it can be too late to take it. I have to say, though, I was still relieved when we [Bibliomation] upgraded to Evergreen 2.0 and the OPAC was zippy.
KS: Coordinating between developers, designers, and librarians makes me think of the librarians from PINES. At this conference, they’ve talked about learning to communicate with developers in order to understand what their ILS and OPAC can and can’t do. There’s a big gap in how we talk about things – librarians frustrate their techies by saying things like “my email is broken” without specifics, and that gap gets even wider when we’re talking about requests for development. I’ve been really interested in the process at PINES for opening up channels of communication.
GD: Yes! This applies to everyone in the Evergreen community; let’s have a good framework of expectations. What expectations do we have of DIG (the documentation interest group), the developers, everyone? The developers are often making improvements on their own time. Let’s all respect each other’s time and create an even better framework. That’s something we have in open source that’s lacking in proprietary software: an open framework to work within to change things for the greater good.
Librarians try to be open with their communities to deliver better services. How can anyone do that without an open framework to create those services? To help me, you have to be interested in my community. And open source is community, we understand that drive.
If you’re horribly change-averse and your organization is so heavily reactionary that even talking about a new ILS causes riots, then you’re not going to be happy with anything. That shouldn’t stop you. Sometimes you need to make change even if it makes people unhappy. Moving to open source because you’re mad at your vendor is not a good reason. Do it for the right reasons: open source, collaboration, being part of the process, having more control over your system. The end goal is to get changes that make sense for libraries faster.
Image courtesy of Flickr user evergreen-ils