Feeds:
Posts
Comments

Archive for the ‘OSS ILS’ Category

Do you want to meet up and talk about libraries, library software, and coding?

I’m organizing a small, informal Ottawa-area code4lib North meetup at the end of March.

When: Wednesday March 28, 5-7 PM

Where: Royal Oak downtown at 188 Bank at Gloucester (on the corner across from L’Esplanade Laurier).

The details are also up on the code4lib wiki.

Beginners are very welcome to join!

Let me know if you are interested by e-mailing me at warren.layton@gmail.com so that I can reserve enough seats for us at the Oak.

Read Full Post »

The SirsiDynix paper on open source — the one that caused a stir last fall — seems to have disappeared from WikiLeaks and from Stephen Abram’s related blog post. Fortunately, there’s a copy here, in case anyone is looking for it.

Read Full Post »

Evergreen: Brief Review of 2009

As 2009 comes to a close, I’m in the thick of Phase 2 of our migration to Evergreen. Migrations feel very…introverted. My nose is an inch from the ground and I’m focused on transferring our data. It has been a while since I looked up and considered how far Evergreen has come in one year.

One year ago, Evergreen was still at version 1.2.x, with 1.4.0.0 still a month or so away. Since then, there have been two major releases: 1.4.x, which hit the downloads page in early 2009; then 1.6.0.0, which landed this past November. Each introduced many new features. Perhaps seasoned Evergreen veterans at places like Georgia PINES are used to this rate of progress, but for me, who’s first real experience with Evergreen came only about a year ago, it’s pretty staggering.

To give one small example, our Evergreen site went from having no Z39.50 server (April 2009), to a Z39.50 (and SRU!) server without holdings info (May 2009), to a Z39.50/SRU server that includes holdings and can be very easily scoped to provide “databases” for each of our locations (November 2009). All that in about the span of 8 months. Where once there was a lack of functionality, we now have something better than we had with our previous ILS.

That’s not to say that Evergreen is perfect or fully complete yet. There’s still a lot of work to be done and new features to implement. However, I’m encouraged by the growing community that’s developing. It’s still relatively small and the major patches still come from the primary developers, but new code, patches, and translations are starting to come from outside of Equinox. That’s been acknowledged in some way by the developer meetings on IRC that have begun to take place periodically, where some core and non-core developers get together and hash out the development issues of the day. The use of LaunchPad as a public tool for bug reporting and translations has also helped lower barriers to participation. (That said, Equinox has grown a lot this year and their rate of progress on many big ticket features has consequently increased).

The first Evergreen International Conference was held in 2009 and looks set to become an annual event. Most notably, the inaugural conference helped launch the Documentation Interest Group (DIG), and the DIGgers are currently busy organizing the existing community documentation and getting ready to write up the missing pieces. The next Evergreen International Conference is coming in April 2010.

And, of course, many new libraries migrated to Evergreen in 2009, with others already planning their migrations for 2010. Should be an interesting year ahead.

Happy New Year!

Read Full Post »

We have a new addition at work – a server for testing and development (mercifully, my suggestion to name it “dev-ergreen” didn’t stick). There were some initial ideas for this new server, including:

  • allowing staff to test out new features and upcoming versions of Evergreen; and
  • providing us with a proper place to test our own enhancements and developments.

While those forward-looking objectives are still planned, the first thing I did was rather more conservative: I tested our backup recovery procedure. If our production server spontaneously combusted, how quickly would we be able to restore our services? (After e-mailing the fire department, of course.) Although we have backed up our data from day one, we had not yet tried the backup restore procedure from bare metal.

We restored our data to the development server without a hitch. While doing so, it occurred to me that this is something that open source software makes incredibly straightforward. There’s no concern about obtaining permission from a vendor to install another copy of the ILS on a second server, or moving the data from the production to the development server. Both can be running copies of the ILS without any extra money being spent on licenses. Additionally, new versions of the ILS can be tested without having to sign NDAs and obtaining vendor permission.

As a result, we now have a separate system with a copy of our production data, ready for testing by us and our staff…and I can sleep a little bit more soundly.

Read Full Post »

At my place of work, we signed up for a site-wide license to RefWorks last fall. We’ve also recently moved to Evergreen for our new ILS (press release). Naturally, there was a request from library staff to add a function in Evergreen to export citations from the OPAC directly into RefWorks.

supercatI was happy to discover that Evergreen makes this relatively easy, thanks to SuperCat (part of Evergreen’s backend). With SuperCat and a record id, a record can be fetched in many different formats, simply by changing the URL (e.g., OPAC view vs marcxml vs MODS). This comes in handy when dealing with RefWorks.

Sending citations to RefWorks can be done with a callback. Essentially, you add a link to RefWorks’ import function page and send it your credentials, as well as a callback URL that RefWorks uses to grab the record from your ILS…in a RefWorks-supported format. The problem is that RefWorks doesn’t accept MODS, MARC, or even MARCXML. They say they accept MARC, but it’s actually what I call “MARC text” (it is described very well by Bill Dueber).

So with Evergreen, all that was needed to support Export-to-RefWorks was:

  1. a new transform for SuperCat that converts MARC to “MARC text”;
  2. a new SuperCat feed for the new format;
  3. a button in the OPAC that links to RefWorks and provides the credentials and callback URL.

Voilà! The new “marctxt” SuperCat feed (which uses the new transform) provides the callback URL for RefWorks to grab the record and import it. I submitted a patch yesterday to address #1 and #2, above. A patch to auto-generate the info needed for #3 is forthcoming (and pretty straightforward). So Evergreen should soon support Export-to-RefWorks right out of the box.

(“Fine. Now take it off.” [SuperCat] photo created by “Allergic to Work” on Flikr, and licensed under the Creative Commons Attribution-Non Commercial-Share Alike license).

Read Full Post »

Evergreen Z39.50 Server

It’s the end of Week 2 at the new job[1] and it has been productive. Part of that may be because I ingested a decent amount of coffee. (I can’t get enough Bridgehead coffee and tea after being away from Ottawa for so long – I hope they expand to other cities in the near future.)

Late last week, I got Evergreen set up to act as a Z39.50 server following the instructions on the project’s DokuWiki. SRU worked fine out of the box and Simple2Zoom was easy to install and get working. I was retrieving records with yaz-client in no time.

This week, while testing the server with other Z39.50 clients, I found and fixed a bug in Simple2Zoom that was causing us some minor trouble. The first bug fixed in a new job, however small, is always very satisfying.

[1]: Okay, it’s not really a “new” job – I worked here during my co-op term last fall.

Read Full Post »

Randy Dykhuis has an article in this month’s Collaborative Librarianship in which he discusses the history of the Michigan Library Consortium’s move to Evergreen (full text[PDF]). From the abstract:

“In 2008, seven Michigan public libraries migrated to Evergreen, an open source integrated library system developed by the Georgia Public Library Service. The Michigan Library Consortium and Grand Rapids Public Library provided the support, training, networking, and system administration for the system. This article examines the reasons for implementing an open source system and the challenges to running and sustaining it.”
An interesting read, particularly as I have just finished my first week working as a Systems Librarian at a library that recently migrated to Evergreen.

Read Full Post »

Older Posts »

Follow

Get every new post delivered to your Inbox.