The OPAC Project

A Blog About OPACs and Library Technology

  • Home
  • About The OPAC Project
  • About Me
  • Subscribe

Koha Install Take 1

By adam on 02/14/2011

Directly after the first interview, I decided to do my own install of Koha. This was sort of a dry run to see exactly how difficult it is to install and get it up and running.

I wanted to use one of the versions of Linux that is known for being user friendly. This choice was made not because it makes installing Koha any easier, but because I intend to use it as a machine to learn about the viability of running Linux on staff and patron computers. Unfortunately, installing Koha was still a bit tricky.  There have been a few versions of Koha since I did the install, so my hope is that many of the difficulties have been eliminated since then.

I have included some screenshots from the install process. I plan to write up a more detailed guide when I do the next install from scratch. As you’ll see from the pictures, I tried doing an install of Koha on the Mint distro, but for various reasons I decided to opt for Ubuntu instead. It seems as if many libraries have made the choice to go with Debian, which works as well.

Doing this project does not require the fastest new computer, in fact I used an old one that was given to me. The first step was to install a fresh hard drive on the machine. This step is optional.

The next step was to install the operating system. We ended up choosing Ubuntu. You can download the software here. Once you have downloaded the software, burn the disk image and put it into the Koha machine. Most machines are set to boot from cd if it is inserted before start-up. If your machine does not boot from the cd, you probably need to enter the setup menu at start-up (BIOS) and change your boot order. Once that is completed, you should be able to boot from the cd and follow on-screen prompts to install the operating system of choice.

Once the operating system has been installed correctly, the next step is to update Ubuntu (if needed) and set up your machine as a LAMP server. From this point forward, much of the information and guidance that got me through the install process came from the Blazing Moon web site which was created by Andy Giesler. Thanks for your work on this, Andy! As versions change, there are new bugs, incompatibilities, and other issues. I certainly ran into some trouble along the way, but it was nothing that could not be worked through. Don’t forget to write down all of the usernames and passwords that you assign. I made all of mine the same, but you may want to choose something more secure. Using Webmin to set things up saved me a lot of command line work, I recommend it.

Installing the correct packages and PERL modules did give me some trouble, but this was primarily due to not always having the correct version. Especially with the PERL modules, downloading the newest version by using the Comprehensive Perl Archive Network (CPAN) fixed problems 90% of the time.

Once all of the required files are installed, you can begin to install and test the OPAC. Here are some screen shots of what Koha looks like before customization:

In total, the install took me the better part of a day. This doesn’t include importing MARC records. I was happy that I was able to get this done. I think it would take much less time in the future, now that I’ve done it once. I intend to try this again with the newest versions of all of the software. I assume that many of the issues that came up during install have been resolved.


Posted in Koha, OPAC installs | Tagged Andy Giesler, information and guidance, Koha, LINUX, MARC, Online public access catalog, OPAC, ubuntu | Leave a response

Interview with Jessamyn West: The VOKAL Koha Project Part 5

By adam on 07/01/2010

This interview was originally conducted between Adam Girard and Jessamyn West on December 30, 2009. This post is part 5 of 5 that comprise the complete interview.

Adam: I wonder if you think that it’s necessary to make mistakes along the way. Do you expect a certain number of mistakes in these new projects, doing things that not a lot of the libraries have done? Do you think that teaching people who are working on these projects as they go pays for its self?

Jessamyn: Well, I think so. I spend a lot of time in some of my other jobs kind of teaching people how to use computers and helping them get to use computers as novice users. A lot of times, people don’t really need me around but they like to have me there if something goes wrong because I sort of help them troubleshoot. I feel like there’s a lot of people, especially in the library profession, for whom troubleshooting a problem isn’t how they’re used to interacting with stuff. Not that it’s a problem, but I feel like a lot of the things librarians know how to do are kind of social problems, or people problems, or logistic problems, but not troubleshooting, not “I’m getting unexpected results, how do I turn it around to get an expected result”?

So, I feel like telling people that everything’s going to be a little broken for a while, number one kind of makes people jumpy, but number two, I also think it ignores the fact that everything’s always a little broken and like that’s okay. Who knows, maybe the bathroom flooded and now you’ve gotta go in there with a mop. That’s no problem, it happens. It’s not great, but it happens. As far as I’m concerned, computers are the same way, they mostly work and they’re sometimes broken, but learning how to troubleshoot them isn’t as easy as saying “get the mop” and its one of those things that you learn by doing, you get better at by doing. Part of that is learning to not freak out when something goes wrong, learning how to assess and do triage. Is this fixable? Is this not fixable?

Just in my computer classes, teaching people how to google an error message that they get is life changing. When they get that error message, they feel like they’re the only one, they’re doomed, and they broke something; their computer is very expensive and now it doesn’t work. I feel like showing them how to do that, gives them a tool, it’s a “teach them to fish” metaphor, but it gives them a tool that not only solves that problem, but helps them solve problems when other people aren’t around. I feel like for libraries, getting used to that, like “okay, how do we deal with this unexpected result?” is not a bad thing to be able to do in general, and honestly, I think it’s something libraries all know how to do. They just kind of feel that when it happens in the computer world, they’re less able to deal with it, and I sort of think that’s not true.

I think they deal with all sorts of unexpected results in the library constantly, all the time, but for some reason, looking at it in the computer setting makes people jumpy, and I feel like it doesn’t have to. Especially with the world of google and the fact that if it’s a computer problem, chances are a thousand people on the internet have had the same problem.  If you know how to look for them, and we’re good at looking for stuff, we’re librarians, you can not only solve your problem, but share that solution out with the rest of the community, and then we all learn, so it’s neat.

Adam: The strategy we use to solve problems that we don’t get jumpy and freak out about, really is exactly the same as the strategy we would use for a technology-related problem.

Jessamyn: That’s my feeling. I feel people who draw really big lines and say that they are totally different are having some sort of emotional issue with the computer that’s not rational. I mean, not that it’s not true and real for them, but that I feel that people who are like “computer problems I can’t deal with, but, you know, plumbing problems I can deal with”. It’s just like it’s a plumbing problem, in a different outfit.

Adam: Absolutely. Great, well, I guess before we finish up I wonder if there’s anything else as we’ve been talking about open-source, OPACs that you wanted to add.

Jessamyn: The only thing that kind of comes up when I’m thinking about this issue is the fact that talking about this stuff now, at the very end of 2009, the world is already so different than it was like 5 years ago. I’ve been kind of interested in open source as an idea, ever since I learned about UNIX and LINUX and Linus Torvalds and all this stuff, but really watching this stuff come to the forefront, both with online catalogs like Evergreen and Koha that I think are ready for prime time, but also in consumer software like Firefox. Firefox is just starting to eek out Internet Explorer 7 in browser statistics, and it’s really exciting. It’s a real option. It’s not just nerdy computer people like this, but other people can’t understand it.

There’s now open-source alternatives to every major software product out there, whether you particularly like it, maybe you like Photoshop better than GIMP, that’s fine, that’s your business. But just in the last 3 or 4 years, seeing real options show up in the open-source world. So, if you are a library that’s considering something like this, you don’t have to be a trailblazer. The trail’s already been blazed and you can make a decision how you feel about that. I feel like that’s a change, and a very very positive one, one that I’m personally excited about.

I feel like we have new challenges, like dealing with digital rights management, dealing with digital content and how to deal with that, dealing with digitization, a whole bunch of other challenges are coming up as I feel like this one’s getting a little bit more established. It’s sort of exciting times and things are changing and they’re changing kind of rapidly, which is neat just for me to watch as kind of a, as almost a sidelines open-source aficionado here. I just want to be like, hey this is a great time to be into it, and it has been a great time to be optimistic and really be able to help out with these kinds of projects. It’s exciting to me that people can go to library school, being interested in open source and also having that mean there’s probably a job they can do that’s kind of a unique, interesting, valued and something someone will pay them for. So that, I think that’s my final thoughts on it.

Adam: Great. Well, I wanted to thank you for taking the time to talk to me about it. Your work has been a true inspiration to me. I hope that this interview will reach more people and continue the inspiration to embrace open source technology.

Jessamyn: Sure!

Posted in Interview, Jessamyn West | Tagged Adam Girard, Evergreen, Firefox, freak out, Internet Explorer, Interview, Jessamyn West, Koha, Libraries, Linus Torvalds, LINUX, OPAC, Open source, software, unexpected results, UNIX, VOKAL | Leave a response

Interview with Jessamyn West: The VOKAL Koha Project Part 4

By adam on 06/20/2010

This interview was originally conducted between Adam Girard and Jessamyn West on December 30, 2009. This post is part 4 of 5 that comprise the complete interview.

Jessamyn: Well I was just going to say, for example, the other project that we used, which is downloadable audio books; our task was to find a downloadable audio book vendor. Basically, there are two and they’re both horrible. And we picked the one that was less horrible, and they’re still horrible. Every time I have to use the software I want to kill myself because, they’re just so bad. Yet, the people that were choosing did the best job they could with what was available. There isn’t a way to get a downloadable audio book product for a library that isn’t horrible because all of the choices are horrible. So, in a lot of cases people do the best they can. It’s not like I mean to point the finger, like “they’re bad at their jobs!” It’s just that, in many cases, we’re between a rock and a hard place where all the choices are bad. If you have patrons who want downloadable audio books, it’s kind of lame to tell them “I’m sorry, all the software is terrible so you can’t have it.”

Adam: Sure. One thing that I think libraries have been fairly good at, by necessity, because they’ve been forced to, is forming consortiums.

Jessamyn: Yeah

Adam: I wonder if you think that if larger consortiums were to band together and define needs from software, or even wants, and they said to all vendors, and any vendors that don’t yet exist, “this is what we need and when you make it we will buy it, and not before”. If they took a little bit more control and said “we actually have requirements”. Do you think that’s an approach that could be successful?

Jessamyn: I think it would help. I think we’ve seen some really interesting failures of that. With the WALDO Project, who basically directed LibLime to build what they wanted and LibLime did it except then they didn’t release the code. That’s bad, and it created a schism in the Koha community which is a bummer. Everybody has their opinions about why that happened and what the really bad part about it is.

Basically that was a consortium who took that approach, but then the vendor, in order to kowtow to the consortium, actually kind of broke the spirit, if not the law, of the open-source feature of Koha. I mean, its much more complicated than that, obviously, but in this case you did have a consortium, who was using their purchasing power.  Yet, according to LibLime, that depends who you believe, the consortium then didn’t want to release all that code back into the community and just give it away for free. So, in this case you have a consortium who was really encouraging innovation, but at the same time, not sharing it back out. So, good news for WALDO, kind of crappy news for everyone, else except maybe LibLime.

Then you see other libraries, like I think it was Queens Borough who’s suing SirsiDynix because they made a decision based on a whole bunch of factors, I can only sort of remember these stories, but basically they made a decision to purchase certain software, which once they had already signed the contract, they realized wasn’t going to be sustained and supported the way they thought it would. So, now they have to sue SirsiDynix for a whole bunch of money. SirsiDynix, of course, who had Stephen Abram, who notoriously came out with a kind of weird open-source white paper that said of all sorts of sketchy things about open source, and a lot of people called him to task for it, and so he left SirsiDynix a months later to go work for—who’s he working for?—Gale.

So, I kind of feel that that’s a true scenario and I’m curious if we’re actually going to see that happening moving forward. One of the things about consortia is, I was a lot more kind of —blar, about consortia until I saw some of the really innovate, wonderful things that they’ve been doing. I’ve seen more and more as  consortiums doing things that I think are innovative. I think they’re also concerned with the training, the tech-novice issue. I mean, they have to deal with a lot of training and a lot of handholding, you know, jumping ship from a known, established vendor is risky for them. I think, open-source communities aren’t usually motivated by money, per say. So, I think what winds up happening is, you have consortia but what they really wind up having to do is a lot of in-house development and spend their money that way.

Michigan Library Consortium did that, they brought in a whole bunch of libraries up on Evergreen, and it was very exciting and everyone was thrilled. It’s delightful, oh my god its wonderful. But they were kind of operating in a weird little vacuum, because they were actually small enough that they were dealing with teeny libraries, and so did not have a whole bunch of fear, uncertainty, and doubt that you would get if you were, Queens Borough, for example, who may not really have the option to move to open-source because, part of what they feel they need to have is a support contract, not an in-house team of programmers.

So I feel like the culture has to shift a little more so that the whole idea of an in-house team of programmers, to a consortium, can be a reality and then they can do more of the development themselves. So its not even ordering the vendors around, it’s becoming the vendors so that smaller libraries can benefit from the kind of strength of a larger consortium, in my dream world.

Adam: And possibly even developing and understanding of the fact that once you enter into that kind of structure you’re in a different economy.

Jessamyn: Right, yeah! Totally, totally different economy. For us at Tunbridge, saving a couple grand a year on not-Follett, ( or not buying something) is real money to our community. You know, a couple grand a year is 80 books. That really matters to a library with 8,000 volumes, whereas to a bigger library, that might matter differently, and it’s partly a different economy and partly a different risk assessment. I feel like Queens Borough, and I love their library so I don’t want to be like talkin’ smack about them, I feel like its been very useful for them to have someone to sue when they got screwed over with this contract and you couldn’t really do that in an open-source environment. People, I think, would argue, and probably rightly, that this wouldn’t happen in an open-source environment, but because they’re dealing with a lot of public money, being able to go after a company when things don’t work out, is useful for them.

I think that’s what a lot of larger consortiums think about. I liken it to filtering, that the whole thing with the Children’s Internet Protection Act and having to filter if you take federal money. The larger systems are the ones who can be like “keep your federal money, we don’t want to filter” but they’re also the ones who have the most exposure if there is a filtering-related issue that they have to answer to. So, it’s both the good news and the bad news that they have that kind of weight to throw around. The power that they have is also equal to the exposure that they get if something does go wrong, there’s a lot of eyeballs on them.

Adam: So to paraphrase, you’re speaking about the fact that bigger systems especially enjoy being able to depend on vendors to fix things when they break, so they don’t have to.

Jessamyn: Yeah, I don’t even know if its enjoy so much, but I feel like if something crashes and burns, being able to tell your vendor to go fix it and not having your entire system come to a grinding halt because all of your people have to be on hand to fix it, can be a good safety net. I mean I don’t even think a consortia are like “we’re so happy its not our responsibility” I just think that they’re like “we’re really happy that we have this risk managed in an efficient way.”

Adam: True, it’s insurance.

Jessamyn: Yeah, I feel like it’s an insurance. Whereas, if its all you, then if something really really goes badly, you’re totally on the hook for it. And, maybe you feel like you’re up to it. I feel like I’m up to it if something goes badly at my library, but I could understand if I had records for 100,000 people instead of 1,000 I might be less comfortable with that.

Adam: And although it’s clear that it’s not the best solution for every library or every library system, to those libraries who could approach doing things differently and handling that responsibility themselves, other than sort of putting your money where your mouth is by being involved with the projects that you are, what would you say to them to convince them to make the leap?

Jessamyn: Well, I mean, my feeling is that libraries are all about the local, right? The reason we don’t have some national library system that gives all the same books to all the same places is that we really are all about our local communities and our local people. I feel like having projects like this, around Vermont especially, we buy from farmer’s markets. I know where my milk comes from, all that stuff, and I feel like, that’s important. That’s a value that we have. Being able to take your money that you have, and around Vermont, we get that money funded locally too, you have to go to town meeting and ask for it.

Getting to spend it locally on local people keeps people employed in Vermont, which is a community good in addition to all of the social good that being a public library has. So, I feel that it’s not green, but it’s the kind of functional equivalent of green from a human resources perspective, keeping that money local, knowing what’s happening with it, the whole sharing aspect. Anytime you make a change, anytime we fix something in Koha, we can fix it for everybody that uses Koha in the entire world and that’s kind of cool. My tech guy, I have a tech guy that does the “techie techie” stuff that’s too high tech for me. He found a way to make the initial loading of records go more quickly. He told the Koha  dev-list and they were like “oh great, we can roll that into the next, dot release” or whatever. So, he fixed something, which was just him doing his normal problem solving, he fixed it for everybody, that’s kind of awesome.

In the library world, where I feel like sharing is just what we do, and caring about the local is really what we do. Those two things together I think make it a genuine option for people. That it’s two things we really like to do, put together and most of the big hurdles have to do with, risk management and being careful and being cautious and being nervous, and I feel like as more libraries do these kind of thing successfully, the more it lays the ground work for other libraries that might be more trepidations or less well-skilled to be able to do it efficiently and with grace, I guess. You know, the first early adopters have a hard time, admittedly, but they’re also a little less risk averse so that’s okay for them.

Moving forward, I’m surprised, frankly, that my library in town managed to do this without a bunch of kicking and screaming and they totally did and I’m totally proud of them. I feel like they’re proud of themselves, too, which is good in tough economic times, when you’re asking people for money and you can be like “hey, look, we spent your money really smart on people in town and helped solve problems for other people”, that’s kind of neat.


Stay tuned for part 5!     Please share your thoughts and comments.

Posted in Interview, Jessamyn West | Tagged Children's Internet Protection Act, Interview, Jessamyn West, Koha, LibLime, Michigan Library Consortium, Open source, Queens Borough, SirsiDynix, software, Stephen Abram, Vermont, VOKAL | Leave a response

Interview with Jessamyn West: The VOKAL Koha Project Part 3

By adam on 05/22/2010

This interview was originally conducted between Adam Girard and Jessamyn West on December 30, 2009. This post is part 3 of 5 that comprise the complete interview.

Adam: So in terms of the developing the catalog that spans the whole consortium, once it’s shared, how far along is that? What’s the next step?

Jessamyn: The statewide scheme?

Adam: yes.

Jessamyn: I’m less plugged in with that because the Department of Libraries is this “big institution on the hill” kind of thing. But I believe the State Librarian has said this is something she wants to do, I believe they’ve committed some resources to it, and one of the things about some of this stuff is there’s funding. If you want to do a big project that involves computers, a lot of times you can find people to help you financially with that. I think she’s in the assessing phase. I’m not sure if they chose the product yet. There’ve been murmurs and rumors about it, but I’m not quite as plugged in on that one. I feel like they’re going with Evergreen, but I’m not sure if that’s because somebody told me that or because I actually know that. And so, we assume that’s going to be a three-year project…

Adam: Sure.

Jessamyn: …and mostly it’s going to be porting their homegrown system that they have now. I have no idea what they have now, and it makes no sense to me. I’ll send you a link and you’ll laugh because it looks like it was built in 1994. It was probably hot shit in 1994, and it’s ridiculous now. So, they have all the records, so for them it’s mostly going to be developing a new system that does all the stuff with the old system that hopefully is more automated. Then, once it’s sort of up and working, libraries will have the option to save a ton of money and just use the Department of Libraries front-end to their same records, if that makes sense. The fact that it does not currently exist, that offends me on some very real level, but it was just a different world ten years ago and no one was really thinking about that. But it’s weird to me

Adam: Well…

Jessamyn: It’s just weird to me that if I could search a catalog that includes the records from my public library, the one that’s not even automated, why can’t I just get a front-end, like an API, for that data set so I can search my own stuff? I mean it just doesn’t have check-in and check-out data, but it has everything else. So, it’s strange to me that it has taken so long to get to this point, especially in Vermont where most libraries are free to everyone. If you come to Vermont, you can use any library for free with a couple exceptions. So the resource sharing and stuff like that doesn’t involve a whole bunch of “we pay you so much money for your patrons to use our stuff”.

Adam: Right.

Jessamyn: I think we’re looking at three to five years on that project, and I’m hoping it takes off and is awesome, but it’s a little more out of my hands. I feel like I’ve helped with the enthusiasm, pushing the VOKAL project forward.

Adam: And as I’ve been thinking about how choices are made, about particular OPACs and features, I’ve been wondering if you have opinions about standards that OPACs should be judged by, or if the people who chose the system that you’re working with have certain criteria, do you know anything about that?

Jessamyn: Well my feeling is that a lot of the commercial OPACs that are available now have this sense where the hard work is getting the functions to work. So, the user interface, which is for most of our patrons is the only thing they will ever see, or really know about. There’s this sense in which, one can gets online, type a word in a box and click search, and you get records back. I also feel that there’s this sense that they’re like “Okay! It works! Ship it!”

I feel like its only been really recently that we have seen commercial vendors that even understand what user interface design is. On the flipside, when I was going to VOKAL meetings (more), I was briefly on the usability committee. For one thing, the usability and design committee kind of didn’t understand their individual roles; they didn’t really know the difference between design and usability. A lot of the people that we talked to, who were rural librarians who didn’t have a ton of computer experience, it was really kind of at the minutia level of “Well, I want this to be a radio button and not a pull-down” and you’re like oh god, how about, “are keyword or subject the default?” To me those are huge and radio button or pull-down are small. Each individual person has their own sense of what’s huge and what’s small. I feel like a lot of decisions get made based on things like “Oh, I really like the color” without the idea “Dude, seriously? You could change the color in like 30 seconds.”

So, my feeling has always been (this kind of a tangential to what you asked) We’re always judging based on the wrong things, most of the time, because the people who make the decisions are very rarely the people who have to interact or work with the tools over and over again. I’m horrified, horrified, at the usability of some of the products that I’ve been using as a librarian working in a library. I don’t understand why they’re so bad. It has always been really interesting to me, talking to other people in the library, who are like “yeah it sucks, but it sucks less. Product X is terrible but it’s less terrible than product Y.” Like I really feel like in a lot of cases librarians are used to being like “You have to choose: a, b, or c” and so they pick the best of the three instead of sitting down and conceptualizing “What would you like your dream online catalog to look like? How would you like it to function?” and then trying to create that out of a best-case scenario. You know, it’s like what do you want to drive, a Ford or a Chevy? And you’re like, uh, a Volvo?

The whole capitalist model of like going to the store and picking one of the things off the shelf discourages creativity and innovation because people are like, “you’ve just got to pick one” instead of being like “well, maybe we can design it to be terrific. Maybe we can design something that we really like, that can fulfill all of our hopes and dreams, or at least most of them. Or maybe we can own more of the development, whatever that means, of this product.” I like pointing to Firefox a lot with this kind of thing. Firefox doesn’t have to look like what the Firefox-developers want it to look like. Firefox can look like what anybody that knows how to do the four steps to modify Firefox wants it to look like, and that’s huge!

For most people, they only take the stuff in through their eyeballs. Software doesn’t feel like anything, doesn’t taste like anything, certainly doesn’t smell like anything. If all you’ve got is how it looks and how it makes you feel, it would seem to me that you would want to heavily, heavily, heavily have an impact on that and yet so many people don’t. They think about how they feel about the vendor, or price, even though, as we know, price is random in software vendor world, enterprise software. So I’ve really found that people don’t really have any idea how to evaluate software and they evaluate it irrationally, which is fine I guess, until the point in which somebody’s being like “You’re being totally irrational about this” and they’re like “Got a better idea?” And, you know, maybe not. It’s hard to say, right?


Stay tuned for part 4!     Please share your thoughts and comments.

Posted in Interview, Jessamyn West | Tagged Adam Girard, Evergreen, Interview, Jessamyn West, OPAC, Vermont, VOKAL | 2 Responses

Interview with Jessamyn West: The VOKAL Koha Project Part 2

By adam on 05/09/2010

This interview was originally conducted between Adam Girard and Jessamyn West on December 30, 2009. This post is part 2 of 5 that comprise the complete interview.

Adam: I wanted to ask if you know more about how the stages of the project were organized, how it was structured from the beginning, what the phases are and when you became involved.

Jessamyn: Well, I was sort of aware of it from the beginning, but not really super involved. I’m a really bad team player by the way, just terrible—and so I was kind of finger on the pulse and yet not doing a lot of the steps. Stephanie Chase is the librarian, right now at the Stowe Free Library. She left Vermont, and then came back to Vermont. She was like, “its crazy that we haven’t done this!”.

So, she found a couple other people who were also interested in transitioning their catalogs, and they started having meetings about how this would work. There was a lot of talking about it. Then they got some vendors to give them ideas. I believe they looked at closed-source options as well. They had LibLime, for example, give them a quote, which was astronomical and crazy, but at least they knew what it would cost them to have a services company come in. They looked at Evergreen. I’m not sure if they looked at anything else. They selected Koha, and then the timeline was really, kind of a meeting every month, and I’m pretty sure the project has been going for two years. It may be in its third year. The first libraries came online, I believe, after a year, or a year and change. So, the specifics of the timeline I don’t really know, I started going to meetings when it became clear that I would be helping Tunbridge with their automation project.

Adam: Okay

Jessamyn: Our project has always been slightly parallel to the, the VOKAL project, only because the meetings are really early in the morning and they’re really far away, and I just can’t do it. So, I’m kind of like “Let me know what happens at the meeting!” but I’m not really good at actually getting to the meetings. So, I can read the notes and I kind of figure stuff out. Some of the stuff, like installing Debian for example, me and my tech guys can do ourselves and we didn’t really need the hand-hold-y steps that other people took, not that there’s anything wrong with that, its just we had a slightly different trajectory.

Basically, the steps were:

  • Figuring out if there was interest
  • Choosing a vendor
  • Choosing a product
  • Figuring out the fee structure
  • Figuring out the timeline.

Everybody installed and built their own server, you know, they brought in some old computer and then they installed Debian on it. They decided on a feature set for Koha, like things they wanted turned on, things they wanted turned off. They chose a designer to do some of the designs so it looked more the way we wanted it to and less like a generic install. People installed Koha on their servers, and every step along the way there’s been this guy, Richard, who works at one of the local libraries, who was available for questions. There was a brief period of time where it looked like he would start his own local services company, like doing a hosted Koha solution in-state, but didn’t wind up happening for whatever reason. And then as people started installing Koha, it was a question of figuring out how to get records, figuring out how to import records, which is kind of a challenge if you’re not automated.

If you’re already automated, you’ve just got to port the records over. If you’re not automated, you kind of have to get the records from the department of libraries and pray, which is sort of what we did at Tunbridge. There was lots of prayer and it mostly worked, but it was really kind of ugly compared to Kimble, my town library, who basically paid ByWater to port their stuff from Follett to Koha, including all the check-in and check-out information, which is really a pain to transfer by hand. What we’re going to do at Tunbridge when we finally flip the switch, which should be in the next couple months, is we’re just going to have to start from the assumption that everything’s checked-in, and then as things cross the circulation desk, gradually get a sense of what’s in and what’s out, and doing shelf-reading as we go. So, once you get the server, and Koha running on the server, and the records in Koha, a lot of it is just cleaning data, cleaning data, cleaning data and then training…

Adam: Right.

Jessamyn: …because the big deal for us at Tunbridge is that nobody’s ever dealt with digital records before. Everything’s been pieces of paper. Some people are really not particularly psyched about that, and other people are really psyched. So, there’s a certain hearts and minds aspect to it, which I’m not particularly good at and don’t like, but that other people are better at. Part of it is really just explaining the change of culture that’s going to happen as a result of becoming automated generally. This has nothing to do with open-source. When I check out a book at Tunbridge right now, I write my name in the back of the book, full name. That’s going to go away, that’s going to be weird for a town that’s used to being able to see everybody who read every book in the library forever.

Adam: Right.

Jessamyn: And so that’s its own interesting cultural thing, it has nothing to do with technology, but it’s going to be almost bigger than “oh, now we have an online catalog.” It’s not a very online community.

Adam: Well, that happens with any change.

Jessamyn: Right right right.

Adam: Especially going from not being automated, to being automated. Any time there’s a migration from one system to another, anytime someone has to get used to something new, there’s a lag there.

Jessamyn: Yeah, and unfortunately that’s the thing that I, personally, just me, Jessamyn, am kind of less good at because I’m like “well you just gotta power through it!”. I think people that are really good at that kind of change management are a little better at explaining what’s going to happen, letting people know, setting up expectations properly, a little bit of hand-holding when people are upset or feel weird about it, but also trying to stress that this change is good. It gives us these benefits, this is why we decided to do it, but not getting into the, “no, you can’t use the card catalog anymore, rrr”. I’m dreading that, personally, but I’m so psyched about the automation project that I hope that it will spill over, that I will explain to people why I think it’s such a good idea.

Adam: Yeah, and everybody has their own role in managing those changes, so even if that’s not something that you’re better at, I’m sure there are plenty of people in the community that can more naturally take on that role.

Jessamyn: I hope so. It’s a community of like 950 people, so you really do wonder; “maybe there just isn’t someone in the community who’s good at technology who can explain it to people”. But I feel like that will kind of rise to the surface. The library is well-loved, fairly well funded, and a real central institution in the community, so people support the library, and if this is something the library’s doing, they’ll find away to support that, too.

Adam: So in terms of the developing the catalog that spans the whole consortium, once it’s shared, how far along is that? What’s the next step?


Stay tuned for part 3!     Please share your thoughts and comments.

Posted in Interview, Jessamyn West | Tagged Adam Girard, ByWater, electronic catalogs, Evergreen, Interview, Jessamyn West, Koha, LibLime, library technology, OPAC, software, Stowe Free Library, Tunbridge, Vermont, VOKAL, Web 2.0 | 2 Responses

Interview with Jessamyn West: The VOKAL Koha Project Part 1

By adam on 04/29/2010

This interview was originally conducted between Adam Girard and Jessamyn West on December 30, 2009. This post is part 1 of 5 that comprise the complete interview.

Adam: First off, thanks for being willing to do the interview.

Jessamyn: Sure!

Adam: I wanted to do this interview because I’d like to help libraries and librarians realize that we can take some control over the way that we manage software and information and that we don’t have use vendors as a source to do that. I’m talking to people who have done some work in that area about their experiences and hoping to make it feel a little bit less frightening.

Jessamyn: Great

Adam: So I asked you to do this because of your involvement with the VOKAL and Koha projects. I wondered if you could begin by giving us a little bit of background about what that is.

Jessamyn: Sure. The VOKAL project is Vermont Organization of Koha Automated Libraries. Essentially it’s a sort of homegrown grass roots consortium of around 20 libraries in Vermont who all decided they were at various stages of automation; some weren’t automated, some were automated with products they didn’t like, some were automated with products that were sunsetting, that were going to go out of business and they needed to figure out something new, and they wanted to work together on an open-source product. They all wanted to work together on a joint catalog product and sort of banded together as a group of interested people looking into what they could do. This started a couple years ago; there’s now an informal group called the Green Mountain Library Consortium which both does the Koha project, Koha was what they decided on after looking at Koha and Evergreen and I’m not even sure what else, Scriblio maybe, but they also do a project called Listen Up Vermont which is a group buying project for overdrive subscriptions, which is something totally different.

The Koha project is a whole bunch of librarians and they went to regular meetings where they would talk about what they wanted, and how they wanted to do it. It was really sort of hand-hold-y but also kind of mutual-aid hand-hold-y, so everybody there was kind of at the same level. There were a couple librarians that were techie and many who were not techie at all. Everybody went through the same steps together, installing Debian on their server, for example, everyone did it together, figuring out how they had to install Koha, doing it together, figuring out how to import the records, that kind of thing. Every library chips in some amount of money, I think based on the amount of records they have, this is something I don’t know as much about. So, basically the pool of money is then used for a support agreement with ByWater, who’s a company who does support for Koha and other open source products, and also goes to pay a designer a little bit of money to do a custom style sheet, and we can pay programmers little bits of money to fix little things for us that we then can contribute back to the open source community which is, of course, incredibly exciting and awesome.

Since this project has started, which is two or three years ago, there’s now been a movement afoot at the state library, and when we started this the state library was like “we don’t care, we just don’t care”. There’s a new state librarian, she’s kind of awesome, so she and other people at the department of libraries have been looking at the possibility of a union catalog at a state level and they’re looking also at Koha and evergreen and maybe some other options, I’m not sure. This is exciting because it will facilitate inter-library loan and also other stuff like that.

Right now, there’s a state level catalog, like if you wanted to order a book but your library didn’t have it, there’s kind of a union catalog that you could search, but its cryptic and arcane and very difficult to understand. That catalog itself is not usable by the libraries themselves, if that makes any sense. So I work with one specific library, the Tunbridge Public Library, and we are going from a card catalog to a Koha automated library, and we’re 80-85% done with that process. It’s been kind of slow motion, going pretty well, and it’s very exciting. So I think a lot of people who aren’t as like, you know, fanatical about open source as I am have grown to understand why that kind of a project is appealing, and people like me, who were already in the band wagon, are like “see, it actually works!”. It’s been very exciting.

Adam: It sounds like there are a lot of opportunities that you’re able to take advantage of because you’re in a small, rural community and because of these developments. You can do resource sharing and take advantage of what that can do for you.

Jessamyn: Exactly, exactly. I mean, the department of libraries is really kind of bare-bones, so the extent to which librarians can embrace some of the DIY culture, a lot of times we’re sort of human resources rich and cash poor. So, Koha has a great catalog for a number of reasons, but really one of the reasons is that it’s free. Free like beer and its okay for us to hire someone to do some programming and do the sweat equity ourselves. It’s really helpful that we don’t just have to send a lot of money out the door to somewhere else and get nothing for it. I mean, ByWater, granted, they’re not a Vermont company, but we’re really happy with how accessible, approachable and friendly they’ve been when we can’t answer our questions ourselves.

So, the economies of scale that we’ve been able to get out of being able to re-purpose the catalog and make it fit exactly what we want, and take advantage of the open-source community, has been very cool from my perspective. I kind of come to open-source almost from a philosophical, “I BELIEVE in open-source” perspective, but its nice to see it actually implement-able by other people who aren’t necessarily gung-ho in that way, just because its good software, and because there’s a lot of documentation and that sort of thing.

Adam: And being able to do that without having a techie background, I would imagine, increases the feeling of ownership that everybody there has over the thing that they themselves are creating.

Jessamyn: Oh totally! In the VOKAL group, we have one guy who’s a real techie, a couple other people that are kind of like me—I can kind of do CSS and HTML but I don’t really understand PHP but I’m really good at learning software—and then there’s a lot of people who are real just kind of end users, comfortable end users. The library in my town, which is not the library I work at, their Koha instance just went live literally this month. The librarian there… she’s a rural librarian, her husband’s a farmer, they’ve been in this community for a very long time, and she basically gets to talk to the people in the community and be like, “I did this, I did this.” And so they look at her as if she’s a freaking hero, which is great, and but also they look at her as if she’s solving a problem for the community. I tell everybody that pays taxes to the town, you know, they’re not paying x number of thousands of dollars to Follett anymore, that money goes to pay Lynn to help maintain the system, and to our regional consortia project, to keep it going and that is something that people can really understand.

Adam: Yeah I bet, that’s really exciting.


Stay tuned for part 2!     Please share your thoughts and comments.

Posted in Interview, Jessamyn West | Tagged Adam Girard, ByWater, electronic catalogs, Interview, Koha, libraries and archives, library and information science, OPAC, Open source, software, Vermont, VOKAL, Web 2.0 | Leave a response

What is the OPAC Project?

By adam on 03/24/2010

I began thinking about the OPAC Project when I started doing user instruction at the library where I work. The goal was to help patrons to learn how to conduct successful searches for materials using our catalog. What I learned, was that unless you were trained to do specific searches, chances were that you would not find what you were looking for.

I’m still uncertain whether this lack of successful searching is more frustrating to me or to the patrons that are searching for materials. I believe that providing materials to patrons is an essential part of each library’s mission. Patrons should not have to learn special search techniques in order to find materials if they already know the title or author. Rather than deciding that patrons should adapt to OPAC shortcomings, I decided that OPACs should adapt to patrons.

I am aware that some OPACs are better than others. Recently, I have noticed a wide variety of bibliographic search technologies that have improved greatly as compared to the last generation of comparable tools. I would like to see these technologies continue to improve. If OPACs are compared to commercial bibliographic search tools, OPACs fall short. While the mega-vendors don’t use authority control and their databases are often a mess, it is still simple to find a title such as “The Secret” without any other fancy search techniques.

I’ve written about my feelings concerning OPACs before. After I wrote “The Library: Where Patrons and OPACS Meet”, I decided to prove that there are solutions to the problems that face us. This has been a more productive way to answer many of the questions that have come up regarding electronic catalogs and their use.

When I began to ask questions about OPACs and the work that was necessary to improve them, I quickly realized that most vendors who sell this sort of software do not allow access to all of the data and code that would be needed to make changes. This is a common business model, but the more that I thought it over, the more I contemplated where bibliographic information comes from, and who owns it. There has been some dispute over that very question. I decided that for many reasons, it would be best to use open source technologies in order to have full control over the search and display of bibliographic data. The choice was clear that the OPAC Project would focus on open source OPACs.

Don’t Be Afraid

I plan to use this project to encourage librarians to take OPACs into their own hands. OPACs can work better, increase patron satisfaction, and cost very little. I will include interviews and demonstrations with people who have used a unique perspective to improve their OPACs.

Posted in purpose | Tagged Adam Girard, bibliographic search tools, dominican university, library and information science, OPAC, opacs, Open source, search techniques, search technologies, shortcomings, Web 2.0 | Leave a response

Tags

about academic librarianship academic library Adam Girard bibliographic search tools ByWater Children's Internet Protection Act databases dominican university Education electronic catalogs Evergreen experience girard instruction Interview Jessamyn West Koha LibLime Librarian Libraries libraries and archives library and information science library science library technology LINUX Michigan Library Consortium OPAC opacs Open source Patrons Queens Borough scholarly communications search techniques search technologies shortcomings SirsiDynix software special libraries Stephen Abram Stowe Free Library Tunbridge Vermont VOKAL Web 2.0 Interview (5)
Jessamyn West (5)
Koha (1)
OPAC installs (1)
purpose (1)

WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.

Talk about it:

  • Kai:

    “it looks like it was built in 1994. It was probably hot shit in 1994, and it’s ridiculous now.” — I feel like people say that about my wardrobe…   Jump to this post

  • leah the librarian:

    Adam, these are looking great! What a privilege for all of us to have a glimpse into your conversation with such an amazing librarian. Thank you so much for sharing!!   Jump to this post

  • Elena:

    The nitty gritty of which systems you all are using is a bit beyond my ken, but I really appreciate the look that comes in part 2 at the way using these different systems changes the cultural experiences of being in a community, by having a visual connection to...   Jump to this post

Blogroll

  • adamgirard.net
  • Chicago Deskset
  • Young Librarian Series

Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org

Copyright © 2012 The OPAC Project.

Powered by WordPress, Hybrid, and Leviathan.