VALENJ: Evergreen Open Source Library System

Bob Molyneux of Equinox was second to speak at the VALE Symposium the other day.

Bob started by filling us in on the state of the open-source software US public library market which is only about 1%, give or take. He didn’t have the data for academic libraries yet, but he was sure it was less than the publics.

That said, a new wind is blowing and big consortia like MassCat, WALDO, Indiana open source ILS initiative, and the Michigan library consortium are all looking into open-source alternatives. The first biggy to switch was Georgia PINES using the Evergreen system that they developed to “scratch and itch” as Joe put it.

What we learned from PINES

Library users like access to the large virtual library – they don’t care about our politics or the difficulties under the hood. Patrons will also bypass libraries without access to consortial resources in favor of libraries with that access. Bob welcomes us to the long-tail :)

Bob states that “we [libraries] have failed.” We have let our libraries become information silos – separate, barely communicating collections of information – “and Google is eating our lunch.” The logic of IT is to break down silos and to integrate these collections. Unfortunately, we have these problems because of several reasons – some our fault and some the fault of others. Two biggies on this list are that our legacy vendors lack vision and we as librarians lacked vision.

OLS v. ILS

The open-source ILS (OLS) may look similar to our old systems, but under the hood it’s completely different – it’s modular and the code is being shared – even between possible competitors like Evergreen and Koha, simply to make both systems better – we’re not just duplicating what has already been done, we’re fixing the wrongs of our past.

Conclusions

Another great talk! I love the idea of libraries breaking out of their silos and sharing information for the good of the people – or as Joe would have said for the good of the “commons.” I agree that I’d rather search a group of libraries at once than just one local library at a time. When in library school I used to love using DIALOG because I was able to search multiple databases with one search, eliminate duplicates and get citations all in one easy action – why should our catalogs be any different?

Technorati Tags: , , , ,

OPAC review from a non-librarian

Yesterday I had an interesting chat with my sister about library catalogs. We were talking about the post I made regarding IM & SMS and whether librarians should skip over IM and move on to SMS? I told her about the fact that card catalogs are still being used and she replied with “Well, I’d rather use a card catalog, it was much easier to find things that way.” This from my younger sister! We all keep assuming that the younger generation wants technology – but here’s one person who’d rather use the cards than deal with the library OPAC. I asked her why.

She said that the OPAC (my word, not hers) is very intimidating (I opened up a Voyager example and we did a little keyword search and it proved her point … there were too many results, none of which seemed to match her initial intent). Instead of upsetting me, this actually got me a little excited.

I decided to show her a Koha example and see what her opinion was. We did the same search on the Athens County Public Library site and found the perfect result come up as the first result (yes, we did the same search). “So, is this better?” I asked. “Yes, much” she replied. She found that the Koha interface was familiar and friendly, less intimidating. She also said that she feels that the younger generation is less likely to learn what’s old (in her case – card catalogs are the way she learned – so while they’re old they don’t count in this argument) and more likely to stick with what’s new and hip and familiar – in this case the Koha search results reminded her of Amazon and made it easier for her to find what she was looking for without being overwhelmed.

I need to add here that my “younger” sister is only 2.5 years younger than I am – we’re not talking about a teenager here – but we are talking to someone who finished her undergraduate last year and was very recently surrounded by the next generation of library researchers.

I love my job – I love getting to go out and talk to librarians about what’s new and available for libraries – but I also love talking to the non-librarians to see what they want and expect from their libraries – this was a great chance for me to talk to someone about libraries who doesn’t actually work in a library. I think I’ll try to do this more often :)

Technorati Tags: , , ,

Taking the Catalog out of the mix

I’ve been saving a post by Karen Coyle for a while now – wanting to give it a good read. The post was titled The ILS minus the catalog. If you couldn’t tell, I’m spending this morning catching up on blog reading and blog posting ;)

Anyway, back to Karen. This is an interesting post and on that I can relate to both as a librarian and as a developer. Karen mentions that the movement to pull the Catalog out of the ILS seems like a strange move since the ILS was such an amazing feat not too long ago. At the same time she understands the need now that we’re all focusing more on our patrons. In the beginning the systems were built to make librarians’ lives easier – bringing all library functions together under on roof. In that process something had to suffer and unfortunately patron search/research success is not easily measured and as such the OPAC was not focused on as much as it should have been.

All that said, as a developer – who does understand this predicament – I disagree with the way the ILS was designed in the first place – I disagree with the librarians who told their developers that only quantifiable services were important and the other areas were secondary. Whenever I developed an application I always made sure that the librarians I was working with knew that the patrons were my first concern. If that meant that the staff interface was going to be less than ideal – so be it! If it means we have to work harder to make our patrons happy – so be it! That’s what we’re here for – isn’t it? To help the patrons?

I would think that this is more an issue in a public library than an academic or corporate library where there is a captive audience – but that doesn’t mean that academic and corporate librarians get to focus more on themselves. I think we all need to take a good long look at our libraries and the services we provide. Are we really making it as pleasant for the patron as possible?

I know that I’ve been very hard on the proprietary vendors in the past – and while I still have strong feelings on the matter – I think Karen’s post makes it clear that this is not the sole fault of the vendors, but the librarians who initially requested these systems as well. We all know it’s time for a change – and I can’t wait to see what happens.

Code4Lib 2008: VuFind

In Andrew Nagy’s presentation From Idea to Open Source, he took us through the process of creating VuFind, an open-source OPAC replacement/Library portal.

At Villanova, they wanted to develop a portal for library patrons that would let people search the catalog, the article databases and digital library all in one – and keep it separate from the ILS. The goal was one single interface for all library resources in order to minimize the learning curve associated with having many different interfaces.

After doing some asking around, they quickly found that many other academic libraries were having the same problem – so the question became – why don’t we do it together? Why not make this an open-source project so that others can participate and benefit from the work of others?

The Goal

At Villanova, they wanted to build a system that would work with any ILS (including Koha & Evergreen – which Andrew called “our open source cousins”) and needs to work on a variety of platforms (Linux, Windows, etc).

The goal was not to replace the ILS, keep the ILS to do what it does best – but change the web app our patrons use so that it better meets their needs and expectations. VuFind uses the ILS to pull live holdings data from and either harvest bib data (if the ILS doesn’t provide direct database access) or query existing index (mostly used on the open-source ILSes which provide a way to let you in to search directly).

By having this top layer in addition to your ILS, you can easily change ILSes in the future without disrupting your patrons or changing the way they’re used to working. All this, just by separating the OPAC from the ILS.

Making it Open Source

The next step is to take this open source and share it – Villanova is not the marketplace to sell/support software. Andrew made a call to the audience to help build a collaborative community around VuFind so that this project can take off and be successful. Since other institutions are interested in it it would be a shame for Villanova to keep it to themselves – this is why open source is the next logical stop for the project.

In order to do this decisions have to be made, the right tools need to chosen. Some options were Sourceforge and Google Code. Right now, the VuFind team chose Sourceforge – they don’t find that it has all of the tools they need, but it was a good first step in making the project shareable.

The future vision includes having a local SVN or CVS and using a tool like JIRA, TRAC, Bugzilla, etc. These options lead to true freedom, but require a hosting institution.

Positives of Open-sourcing

  • collaborative code sharing
  • idea sharing
  • university gets national attention (good for the university – and shows the directors that it’s worth spending time on)

Negatives of Open-sourcing

  • mailing list support – requires time that you may not have
  • facilitate communication – also takes time
  • possibility of people not have things unanswered due to time constraints
  • time involved with marketing – getting the word out (the true success of an open-source project is word of mouth) – requires traveling and schmoozing
  • project switching is expensive (we all have other jobs – jumping from our primary roles to assist in VuFind is time-consuming & thus expensive)

Where VuFind is now

Most importantly, we need easy ways to install the software. Everyone knows about the famous WordPress 1 minute install – this should be the goal. The product requires easy install and integration, strong user interface and strong functionality before it will be widely adopted (I’d argue that the interface is pretty strong already – just a few more tweaks and it’s there).

When open-sourcing a project you need a roadmap for organization, to keep the process agile and to communicate with the community so they know what you’re doing from time to time. The start to this is the VuFind site and Sourceforge, but as Andrew said, not everything needed can be found in Sourceforge.

Conclusions

I’ve seen Andrew talk a few times about VuFind and I think this was the best of all of the talks I saw. It showed me how I can help, it showed me that there is a plan and a pretty mapped out one for VuFind. I see this as a viable option for librarians looking for a way to to integrate searching of all of their collections in one easy to use, clean, interface.

Technorati Tags: , , ,

Koha Camp

Don’t miss this free opportunity hosted by PALINET:

Koha Camp is a unique first opportunity for systems librarians, library software developers and designers to come together for an open source experience with Koha Library Integrated System.

This one-day workshop, limited to 25 participants, is a place where teams of software developers and librarians will join to explore the open source community and to solve real-world problems. Staff members from LibLime, the library software solutions company that developed Koha, will attend the workshop to work with participants.

By the end of the workshop you will be able to: communicate with other Koha users worldwide, install Koha, understand and navigate the source code tree, create and customize Koha templates, modules, scripts, and utilities, send your improvements as patches to the Koha community for inclusion in the next version.

Koha Camp is free, and will be held at PALINET, in Philadelphia, on January 11, 2008, from 9:00 AM to 5:00 PM ET. Continental breakfast and lunch will be provided.

Technorati Tags: , ,

Conversation on Cataloging

I had an interesting chat with a friend regarding cataloging rules and tools that I wanted to share with you all. I know it can sometimes be hard to follow someone else’s chat transcript – but here you go:

Brooke: I think I want to try gluing my catordogging cripple speak to my lack of coding knowledge
Brooke: You know how there’s dublin core
Brooke: RDA and MARC
Brooke: as well as other junk
Brooke: and a bunch of folks that use Koha for personal collections
Brooke: I think all of the interfaces I have ever seen with cataloguing
Brooke: have fields and boxes and junk to fill in
Brooke: they just aren’t particularly interactive
Brooke: is that so with you?
Nicole: yes – if you mean dragging and dropping as interactive
Nicole: it’s a pretty static form where you hit a key to add a row
Nicole: and tab through the fields
Nicole: in OCLC it’s hitting enter to add a field below and shift+enter to add a field above
Nicole: in Voyager is F3 above and F4 below
Brooke: *nod*
Brooke: but is any of that stuff actually important to the aboutness of a work?
Brooke: is there anything inherent to this interface that _aids_ in cataloging?
Nicole: um … I guess not – it aids in usability for me – I often forget a field and need to add it in
Brooke: *nod*
Brooke: suppose, and I know I’m losing my mind, that the program asked you what it wanted and that stuff was in plain language
Brooke: such as
Brooke: What is the title of the material?
Brooke: and had a simple text box
Brooke: then it said something like what’s the author?
Nicole: the problem comes in with MARC and AACR2 rules
Brooke: then it said something like is the author corporate?
Nicole: the title isn’t always a 245
Nicole: and there are different titles
Brooke: *nod*
Nicole: there’s a uniform title in another field
Nicole: and a different title in 246
Brooke: *nod*
Nicole: and the author isn’t always a 100
Nicole: sometimes it’s a 110
Brooke: *nod*
Nicole: or a 710
Nicole: ….
Brooke: *nod*
Nicole: so without letting me say what field it is “title” isn’t enough
Brooke: but those instances have a related question, don’t they?
Nicole: yes
Nicole: but I think it would take me longer to answer the questions then to type the field myself
Nicole: ….
Nicole: it might be dumbing cataloging down too much – which would work for people with no experience – but those of us with experience would start to get annoyed – I think
Nicole: it’s like this contractor I worked with once
Nicole: he always wanted to copy paste cause he couldn’t type
Nicole: but I could type faster than he could copy paste
Nicole: so I always did it that way
Brooke: do you think they’re really going to change those rules?
Nicole: MARC rules?
Nicole: no
Nicole: AACR2 – that’s what RDA is – but I haven’t read it so I have no idea how different it is
Brooke: but isn’t that curious?
Nicole: curious? no – it’s stupid as hell
Nicole: :)
Brooke: I mean you’re changing the basis for the stuff that a record is
Brooke: but you aren’t changing _how_ you’re inputting the record itself
Nicole: aren’t we? I don’t know – isn’t RDA more like XML? and I agree with you – the how that I hate is the stupid rules about periods and semi-colons –
Brooke: all of these disparate methods of working round or gluing to MARC is just kind of funny
Nicole: I’m not sure … see even as I was learning MARC I thought it was pretty cool
Nicole: I mean think of the power in the data by using so many fields and subfields
Nicole: there is so much there
Brooke: (punctuation and a bunch of convention seems to be disappearing with RDA, but I am far from a cataloger…)
Nicole: the problem is with the systems that read the data …
Nicole: they don’t take advantage of all of the work I put into my MARC records
Brooke: uh huh
Brooke: the problem isn’t either the system OR marc, it’s both, yes?
Nicole: and if I didn’t have to follow AACR2 then I could work much faster
Nicole: I don’t know
Nicole: maybe MARC could be updated a bit
Nicole: but the systems are the big problem as I see it
Nicole: they don’t read all of the amazing data we have …
Nicole: example:
Brooke: (Yes I weight the systems heavier in the blame equation, too.)
Nicole: when I have a photocopy of a dissertation I put in data about the photocopier and that data never shows in our catalog
Nicole: I enter data about the fact that our books have been deacidified (yes there is a field for that) but that never shows
Nicole: I enter all kinds of valuable archival data that never shows to the user – which is the system
Nicole: the system doesn’t read all MARC fields
Nicole: and if it did it would have to come up with a reasonable way to display it all….
Nicole: maybe because I was a db admin before learning MARC – I like MARC – I like all the fields – I like how they have the potential to link together
Nicole: I enter in the fact that a title was indexed in X index and that’s an awesome resource for a researcher – but my system doesn’t link that to the index – it just says if you want you can look here – but you have to figure out how to do that yourself
Nicole: silliness
Brooke: *nod*
Brooke: I agree completely
Brooke: I think you said what I anticipated you might, which is just nuts
Brooke: I think the cataloguers are beating sense into me thick skull
Nicole: hehe
Brooke: here is one thing I have always wondered about
Brooke: Our Library types ought have their own out of box distribution
Brooke: you, as an academic, want a deliciously complex cataloguing setup
Brooke: BUT the interface for you is simple
Brooke: you want a text box, rev her up, I know my fields, I’ll data dump em into a box
Brooke: yeah, I might forget summat, but as long as I can fix that, no big deal
Nicole: that’s not necessarily an academic thing – that’s a cataloger thing …
Brooke: *nod*
Brooke: I was getting to that
Brooke: large publics would want that, too
Brooke: presumably
Nicole: I agree that there need to be different types of systems for academic, special, and public libraries though
Nicole: the problem at the special library I used to work at was that the system was built mostly for academics
Nicole: and it didn’t fit some of our very particular needs
Brooke: *nod*
Nicole: that’s where the modular system comes in
Nicole: and is needed
Brooke: *nod*
Nicole: but that still doesn’t change the cataloging aspect – I think if there is one professional cataloger in your library then they’re going to want a system pretty similar to what I want …
Brooke: *nod*
Nicole: they’re used to it and they know their job
Brooke: absolutely
Nicole: that said
Nicole: it sort of sounds like “we’ve always done it that way” and I hate that….
Brooke: no!
Nicole: so if someone comes up with a better more efficient way – I’m all for it
Brooke: you get what you want is the reason OS is
Brooke: I’ve just had this problem rattling in me brain for at least 5 years
Brooke: what does someone who’s in the middle of no where
Brooke: who isn’t like you
Brooke: who doesn’t have cataloguing experience
Brooke: or even more dire, is a volunteer
Brooke: but really wants to help the Library
Brooke: how do we construct a way for them to help
Brooke: AACR2 is very particular
Brooke: you start with nothing
Nicole: we develop a simple cataloging system that isn’t built on rules like AACR2 and doesn’t use MARC
Nicole: we develop the system you described in the beginning
Brooke: yes, but the kicker to that
Nicole: one where title, author, publisher, call number … are all fields
Brooke: is that the computer CAN assign it MARC fields
Nicole: why does it have to?
Nicole: why can’t you have a different cataloging system than me?
Brooke: bingo!
Nicole: why can’t your system just read the data the way you need it to?
Brooke: bingo!
Brooke: the only reason that information is constructing MARC is that we tell it to
Brooke: there’s no reason the same information can’t morph a little and be dublin core
Brooke: or nothing
Nicole: I agree
Brooke: but it has to have a box
Brooke: so that it can be a proper database and get retrieved
Nicole: so you need an OPAC that reads XML – or another format … something that reads a format that anyone can write
Nicole: this wouldn’t be hard to develop
Brooke: I don’t think so either
Nicole: and in fact it probably exists
Nicole: there has to be some small library with a homegrown system just like this out there
Nicole: but if you want to fit this data entry format into a traditional cataloging system – you can’t – there are too many variables involved
Nicole: like I said – title is not descriptive enough for those systems to put the title in the right place to display the data correctly
Brooke: yes
Brooke: I realize that
Brooke: I was simplifying things
Brooke: but I think most materials in smaller collections could be seen to with relative ease
Brooke: in fact, there’s so much copy cataloguing
Brooke: that most of the stuff I’ve seen is just barcoding
Nicole: but if you’re that small a library do you have access to tools like OCLC to copy catalog from?
Brooke: no, but you don’t need OCLC to copy catalogue
Brooke: >:)
Nicole: k
Brooke: ^^^^^ Ghetto Librarian
Brooke: I almost wonder if I’m thinking of a tutorial
Brooke: and not a module at all
Brooke: wouldn’t you improve after a few go rounds at this
Brooke: wouldn’t you realize that you had a corporate title right away
Brooke: or a translator or whatnot?
Brooke: I mean, you weren’t born knowing that the 856u was a field with a link in it
Nicole: I’m losing you
Nicole: right
Brooke: but after seeing a few of those records and digging around a bit
Brooke: you figured out what was displaying and you learnt about that field perhaps
Brooke: I don’t know too many people that sit down and read the AACR2R cover to cover…
Nicole: I do!!!!!!!
Nicole: it’s insane
Brooke: :)
Brooke: I do too, but I read the dictionary as well
Nicole: I agree though – you can figure out MARC by poking around a bit
Nicole: it’s the rules from AACR2 that stop things up
Brooke: which are going to be changing…
Nicole: so drop the silly punctuation rules from the card catalog days and let me enter my data however I want in the right fields and then be done with it
Brooke: uh huh
Nicole: there is no reason a computer can’t change my capitalization or my punctuation after the fact
Brooke: BINGO
Nicole: let me do the human part and let the machine do the machine part
Brooke: YES!!!!
Nicole: :)
Nicole: so are we back to a MARC based system minus the AACR2 (or RDA) rules?
Nicole: or are we still talking about a simple system for non-catalogers?
Brooke: all of the above *duck*
Nicole: how does it work?
Nicole: you allow for 2 interfaces depending on preference?
Nicole: like me and the consultant who wanted to copy paste?
Brooke: mmm hmmm
Nicole: both our ways worked – and one was just faster for each of us?
Brooke: I can’t decide if cataloguers will string me up or embrace me if I figure out how to get what’s in my head out
Nicole: both :)
Brooke: this’ll take forever
Nicole: there are those who are willing to change and those who aren’t – in all fields of life
Nicole: I’m up for anything that makes my job easier ….
Brooke: I think most folks are
Nicole: seems like a no-brainer to me
Nicole: but some people are all about tradition
Nicole: and the way it has always been done
Brooke: *nod*
Brooke: thank you so much for humoring me
Brooke: I don’t meet too many people that really know cataloguing
Brooke: I told my clerks it was like elementary school
Brooke: there are kids at the front of the class that everyone copies off of
Brooke: and by the time the record gets to the back row, it’s not so great anymore…
Nicole: do you mind if I share this convo on my blog – minus your name?
Nicole: I think it’s a good convo for people to read
Brooke: bwhahaahah
Brooke: not at all
Nicole: k
Brooke: someone has to externalize my thoughts
Brooke: feel free to use my name
Brooke: you can even put up my email
Brooke: I want to talk about this stuff with lots of people
Nicole: keep and eye on the comments – maybe you’ll get some good feedback
Brooke: mhelman@illinoisalumni.org
Nicole: okey dokey – I can do that
Brooke: thanks
Brooke: I know you have readership

Woa – what an amazing idea!

From a post by Joseph Lucia at Villanova on the ngc4lib mailing list:

If we look beyond money to personnel, the option looks even better. Let me suggest some numbers. What if, in the U.S., 50 ARL libraries, 20 large public libraries, 20 medium-sized academic libraries, and 20 Oberlin group libraries anted up one full-time technology position for collaborative open source development. That’s 110 developers working on library applications with robust, quickly-implemented current Web technology — not legacy stuff. There is not a company in the industry that I know of which has put that much technical effort into product development. With such a cohort of developers working in libraries on library technology needs — and in light of the creativity and thoughtfulness evident on forums like this one — I think we would quickly see radical change in the library technology arena. Instead of being technology followers, I venture to say that libraries might once again become leaders. Let’s add to the pool some talent from beyond the U.S. — say ! 20 libraries in Canada, 10 in Australia, and 10 in the U.K. put staff into the pool. We’ve now got 150 developers in this little start-up. Then we begin pouring our current software support funds into regional collaboratives. Within a year or two, we could be re-directing 10s of millions of dollars into regional technology development partnerships sponsored by and housed within the regional consortia, supporting and extending the work of libraries. The potential for innovation and rapid deployment of new tools boggles the mind. The resources at our disposal in this scenario dwarf what any software vendor in our small application space is ever going to support. And, as is implicit in all I’ve said, the NGC is just the tip of the iceberg.

Now this is a list I subscribed to back when it started, but I was totally overwhelmed by the emails – but I think I should re-subscribe and keep an eye on what people are saying – because this one idea is just awesome and so simple if you think about it.

Patrons’ Frustrations

I just had a short chat with a friend about the catalog at her local library. They used to have a terrible system that didn’t seem to work at all and now they’ve put Aquabrowser on top of it:

[09:47] Friend: *sigh*
[09:47] Friend: catalogs are so finicky!
[09:47] Nicole: yep
[09:47] Nicole: what’s the matter now?
[09:47] Friend: sheesh
[09:48] Friend: i just want a listing of the books on CD that the Indepence library has on hand
[09:48] Friend: so i can pick on out and run in and get it at noon when they open
[09:48] Friend: i dont have time to browse there
[09:48] Friend: and browsing the books on CD is so…not fun
[09:50] Friend: and they have these “overdrive audio books” but i dont knwo what the heck that means
[09:50] Nicole: :(
[09:50] Friend: yeah
[09:50] Friend: silly libraries
[09:51] Friend: i even called someone at the central library to ask if they knew how to get the results i wanted…he didnt know
[09:51] Friend: but he tried
[09:52] Nicole: see there are all these fields that catalogers enter data into that the catalogs don’t even read
[09:52] Friend: then what’s the point?
[09:52] Nicole: it’s a real pain to me too – cause why do i bother putting that info in there?
[09:52] Friend: heh
[09:52] Friend: yeah
[09:52] Friend: and i found out that it’s not possible to search by format or branch with the aqua browser
[09:52] Friend: …at least not the way they have it set up
[09:53] Friend: you have to search for something and THEN refine it by those sort of things
[09:53] Friend: there must be a way to have it both ways
[09:55] Nicole: i’m sure there is … the data is there … it’s just a matter of people writing the right damn code
[09:56] Friend: it’s true
[09:56] Friend: i wish i could query the catalog directly
[09:56] Friend: seriously
[09:56] Friend: are catalogs built on relational database systems?
[09:58] Friend: i know koha’s built on mysql
[09:58] Friend: so that would be simple
[09:58] Friend: maybe i can do some SQL injection into this FLoP catalog….
[09:59] Friend: i guess not…
[10:00] Nicole: probably not – i’m pretty sure that it’s secure
[10:01] Friend: well the only way i can even limit results to branch and material type is by using the “advanced” settings of the old system
[10:01] Friend: the one with the piss poor search
[10:01] Friend: so single letters dont give me results
[10:01] Friend: like…i KNOW they have DaVinci Code on CD but searching Title won’t bring it up

Why do we put our patrons through this?? I don’t know – and I don’t have the time this morning to get into it – but I really thought I should share with you all.