(I think Melbourne was my favorite, but that’s because I grew up in San Francisco, which looks and feels a lot like Melbourne — two cities with Victorian gold-rush roots.)

As always, I learned a lot from these visits. First I learned from all the preparations I did for my talk — piles and piles of books about library history, going back to the mid-1900s. I tried to tie together a full century of library innovations to the open source movement today. Then, as always, I learned from the visits themselves.

There were many good things to see throughout my trip (and some delish cream scones at our next-to-last library stop), but Brisbane City Library made my socks roll up and down. I encourage you to visit the entire Flickr set (just click on the picture above).

Some innovations at this library include:

* A highly-sophisticated self-check system where patrons can watch their books disappear into the automated-sortation area

* Tools and space for gaming and media that as Bibliotheka points out has resulted in a bump in library use among males aged 18 to 35

* Color-coded Dewey shelving (”Go upstairs and find the pink shelves…”)

* A lovely glass meeting room that floats celestially above the first floor

* Comfy, attractive furniture that can be angled around the terrific city views from library windows or pulled together into impromptu study circles

* A business center staffed by city experts

It’s not that I haven’t seen bits and pieces of all these innovations in various libraries — but this library has a sustained “wow factor” that keeps going and going. Should you happen to find yourself in Brisbane, do stop in.

Bookmark to:

Over on the Evergreen project blog you can find Volume 1, Number 1 of the Evergreen newsletter, a new monthly publication for all things Evergreen. This month’s issue updates you on the 1.4 release candidate, acquisitions, save the dates” for Evergreen events, the most recent libraries to “go Evergreen,” URLs for recent webinars, and more. (Except — d’oh — any mention of the Evergreen Conference next May, in Athens, Georgia. My dumb omission!)

You can blame John Fink and Dan Scott for suggesting this newsletter way last spring, even before I began working at Equinox. I held back for a little while before launching the newsletter so I could get to know the community better.

This turned out to be wise, because through the part of my job that can roughly be described as “external relations” I am learning that the seemingly monolithic open source “community” is really a series of communities with their own distinct needs, interests, goals, habits, and special contributions.

The Evergreen community includes some very dedicated developers, but it also includes people such as Robert Soullier of Mohawk College, who took the time to gussy up the recording of the most recent Evergreen webinar, and the librarians who on- and off-list, in webinars, and in small-group discussions, and in opening their libraries to Equinox, have offered many thoughtful and important ideas about the direction of Evergreen’s development and documentation, and training. In this picture you can see Jim Cooper of West Georgia Regional Library System, who recently opened his library and set aside plenteous time to help Equinox and PINES staff better understand his library’s observations about Evergreen.

Out in the field, I hear some refreshing twists on some of the hallowed assumptions about OSS development — or for that matter, development at large.

For example, in a variety of jobs in my past I’ve heard developers complain that nobody participates in testing software.

But in talking to librarians, it’s clear that call is often too fuzzy and open-ended. Narrow the request to specific features-for example, “ensure the new Frobbinator displays the Doomaflatchies in the staff client”-and at least a few willing victims will gladly step up to the plate. I’m hoping with the next release of 1.4 we can put out a laundry-list of things to test and ask people to commit to bits and pieces they have the most at stake in.

Because it does take a village — and that village has many interesting neighborhoods.

– Karen, Equinox Community Librarian

Bookmark to:

The National Weather Center Library will be the first (known) special library to “go Evergreen.” Evergreen scales all the way down to home libraries and all the way up to huge consortia such as Georgia PINES — and also fits in every type library.

Meanwhile, Grand Rapids Public Library went live with Evergreen on Monday, September 29. GRPL is the second Michigan library to go live with Evergreen. You can follow the Michigan Evergreen Project as five more libraries go live before 2009 (they’re even blogging).

Also, in addition to all the great new features in 1.4 — which is coming along briskly — Evergreen is going to get some very pretty foliage, just in time for the fall fashion lineup! Yes, there will be a very lovely, wonderful new design option for Evergreen’s catalog — not just more attractive, but more usable and a little bit more lightweight.

Plus we did a special Acquisitions webinar for Georgia PINES (the mother ship for Evergreen) and it went great. PINES is now doing what other Evergreen communities might consider: growing a committee to engage with us on acquisitions development. Expect more webinars on other topics, announced more widely.

Next, a small thing, but in case you hadn’t noticed, in the last month or so the Evergreen project site has spiffy new Frequently Asked Questions (in three acts, no less!) and a simpler-to-follow Roadmap, and also sports a new Open Source Glossary and updated Evergreen Feature Request Procedures.

Finally, we have found several terrific documentation writers — woohoo! (But if you were thinking “gee, you know, I’m still interested,” drop me a note at kgs at esi library dot com — we have some other documentation needs.)

Bookmark to:

The Evergreen developers are reporting good progress on Release 1.4, which means that we’re on track with the Evergreen roadmap. For even more details, you can follow the developers’ Roadmap.

If all that seems a tad cryptic, this is what it means.

Tippecanoe, and 1.4 too!

Based on this progress, expect a 1.4 release candidate by the end of September. In software, a release candidate is similar to a political candidate: it should have a strong platform, it should be more “walk” than “talk,” and it’s out there for all of you to evaluate.

We all have busy lives, so when we announce this release, we’ll provide ways you can offer input that are sensitive to real-world schedules.

Going forward, by popular request (well, actually one library director, but it was a great suggestion), we’ll spell out release features in small sips and nibbles — snackable bites that go into a little depth, but not too much.

In this post I’m focusing on two features that will be particularly visible to library users, but upcoming posts will address speed improvements and other bug fixes/staff-oriented fixes.

Reminder notices and web self-check

Two of the features in 1.4 –  due-date reminder notices and web self-check — are being tested right now at the Hussey-Mayfield Library, the first live library in Indiana’s open source initiative, which funded this development.

Due-date reminder notices (also known as pre-overdues):  Hussey-Mayfield didn’t want to lose that popular, user-oriented feature. Evergreen has always had hold and overdue notices (I’ve experienced both!), but the addition of courtesy reminders are an example of the healthy diversity in open source development.

Reminder notices perform two functions. First, they help get books back on time — which can have ancillary benefits with popular items, so patrons don’t have to wait so long.

But perhaps even more significantly, whether or not patrons act on reminder notices (which can be emailed, or a list can be printed so library staff can place calls), these notices build good will — the kind of hard-to-measure success that translates to local support. In a recent query to the PUBLIB mailing list, librarians unanimously reported that “patrons love them” — and particularly in grim budget eras, love is a many-splendored thing.

(As a patron of my local library in Florida, I merrily observe reminder notices fly by me… they don’t impact my actual behavior that much, which is why I think of them as “pre-overdues.” But I do feel like I’m getting terrific service.)

Web self-check is another new feature developed for (and funded by) the Indiana project. Evergreen has supported SIP2 functionality since day 1. Web self-check is a slightly different animal — think of it as affordable self-check.

Evergreen web self-check is not SIP-based, and you can use standard computer equipment. So if your library system were running Evergreen 1.4, you could have Evergreen web self-check up and running with a desktop computer, barcode scanner (stand-style is probably best), monitor, and a receipt printer.  The PC needs to run Firefox.

I don’t know about your library, but I’ve worked in a number of libraries where we usually had some  almost-new desktop equipment, plus a few spares. If that describes your library, you could have self-check up and running very inexpensively; even if you had a buy a scanner or a receipt printer. (The receipt printer and the scanner are the two pieces of equipment users will be interacting with, so don’t pull that wheezy old Star SP200 out of the back shed or try to make do with that CueCat wand some vendor threw in on some purchase.)

Even if you bought all new equipment, an Evergreen self-check station could easily beat the price of many proprietary self-check stations — and if parts broke, you’d be replacing them with commodity equipment, not waiting for the self-check vendor. These self-check stations could also work in tandem with your library’s existing barcode-based self-check solution.

One last comment about self-check. I know a lot of community libraries bank on the idea that patrons like to schmooze at the front desk, so they think self-check isn’t for them. But a self-check option can be a nice addition for patrons who may want to schmooze some days… yet on other days would, if they had a choice, prefer to wave at their library buddies while they zip their books through the self-check station and dash to their next appointment.

I can remember when libraries thought closing book-drops during the day would lead to better service… or that requiring patrons to go through a librarian to place a hold was a good idea. But as long as patrons aren’t left to flounder (like me at the grocery store, holding up a frozen dinner that won’t scan and begging, “Will someone PLEASE help me?”), self-check is one more service option that may prove more popular than you think.

Bookmark to:

The temptation would be to pick up the loose threads on a progress report on Evergreen Release 1.4, which I do have in work. The developers met in August and have good things to report. We’re on track for a release candidate in September (and next week I’ll also explain what a release candidate is).

But I’d rather do this update justice next week, following the suggestion from a library director that we offer snackable introductions to each part of a release, to explain more clearly what the Evergreen developers fixed and what they developed.

Bookmark to:

It’s been a couple of weeks since we did a link round-up, and that seems like a pleasant amuse bouche for a Monday in late August.

John Blyberg of Darien Library says that SOPAC 2.0 will be launching September 1. I’ve been watching this “discovery layer” project for some time, in part due to Insurge, an “Independent Social Repository” that will allow libraries to share social data. With SOPAC 1.0, John gained first-hand experience with the limitations of social data silos. John is always an interesting person to watch, because he’s deeply technical and yet tuned into the possibilities and strategies of social engagement.

On August 20, Villanova launched the open-source library software VuFind for its catalog. While playing with its clean, attractive interface, poking around with its relevance ranking and testing misspelled terms, I remembered this excellent article about the impact of spelling errors on discovery.
Equinox participated in a recent “Library 2.0 Gang” podcast about open source software. The question was primarily whether open source had changed vendor thinking, and of course it has. One point that didn’t surface enough is that the vendor world goes beyond the ILS vendors, to include vendor partners who find working with OSS simply easier all around.

Over at Mentat, Lori Ayre has an interesting post about learned helplessness. She makes a very strong point for librarian engagement in software development. That’s where we started, thirty or forty years ago. I wrote about those days in my biographical essay about Anne Lipow, which was a lot of fun to research (among other adventures, I spent many hours reading the weekly newsletters from the 1950s and 1960s for UC Berkeley’s libraries).

Bookmark to:

Shawn is a programmer/sysadmin/language designer/cook with (in his words) “over a decade of cripplingly painful industry experience.” He comes to ESI from Google, where he did things he says “were really, totally, amazingly cool,” but he can’t tell you about any of that (except that he’s sad his plans to dress the T. Rex up as Voltron never came to fruition).

Shawn answered a few questions for us.

What interests you about open source and libraries?

So far as FOSS goes, I barely know anything else. I’ve been a Linux user since 1993, and have contributed back to various communities since about 1997. The only commercial software I use is Mac OS and video games. I haven’t used Windows since v3.11, and have never owned a “Windows box” (though I grew up on DOS after my Commodore 64 died).

Tell us about you and libraries. What’s the connection?

Libraries… well, I was more-or-less raised by my local library. I’ve had a decent book collection my whole life. I’m captivated by problems of language, documents, archiving, and the preservation of knowledge. It seems fairly natural
Why did you come to work for Equinox?

I’ve known the core developers for a long while now, and I’ve always been impressed by their commitment to Doing The Right Thing. Competence is rare enough, but competence and ethics — that’s amazing. So take that, my gnawing desire to work in the library world, and my desire to be able to make a difference and shape things… when I chanced to see job listings on the company site, I was on the phone with Mike Rylander in under a minute.

How did you get involved in technology?

I met an Apple //c in the fourth grade (that would be 1984). I learned how to draw ASCII art forks with ‘F’s and played Infocom’s Seastalkers.

Fast-forward to 1992. My best friend (who was a year ahead of me in school) enrolled at Georgia Tech and told me I had to come check out the computer labs, so one weekend I went to visit. That Saturday night I met Unix, Emacs, and the Internet, and my life was changed forever.

I notice you bike to work.

I wake up at 8, head out around 8:45, and catch a MARTA train from N. Springs to Lindbergh Station. From there I hop the northeast line to Doraville, then cycle 10km to the office.

I do it for a couple of reasons, but the biggest one is simply that I hate, hate, hate traffic. I’d rather do anything than be stuck in traffic.

Aside from that it’s mostly about being in shape and feeling self-reliant. I like being able to shop daily and carry it home on my cargo rack. Having a commute that costs $13/week doesn’t hurt any, but it’s not my main concern.

When you’re stuck on a problem that you’re having trouble solving, what do you do to get through it?

I usually just let it go for a while, at least in a fore-brain context. My mind refuses to completely stop working on problems. There have been stumpers in personal projects that took literally years to see the right solutions to (though most things don’t take that long). I’m always reading, learning, and hooked up to my network of similarly-minded friends, so new data and points of view are constantly filtering into my consciousness (and, I suppose, subconscious).

Anything else you want to share?

I’d like to thank all the people from #code4lib without whom I would have missed out on a lot of great conversation, piles of laughs, a wealth of knowledge about the library IT world, and, of course, this job. Special shout outs to Ross Singer

Bookmark to:

FUD: We would have to run Evergreen on a locally-installed server!

Response: If your library system is providing Evergreen, all you will ever need to install locally is the Evergreen staff client (available for Windows, Mac, and Linux). If you want to see how this works, download the staff client and point it at the demo server.

Equinox also provides hosting for Evergreen for libraries that need or prefer to use an externally-hosted server and very-high-level external support. Equinox currently supports two hosted libraries, Kent County Public Library in Maryland and Marshall Public Library in Missouri.

FUD: All libraries in an Evergreen system have to use the same policy!

Response: On the contrary, Evergreen’s permissions behavior can free your library from software-driven staff and user policies. Some libraries in Evergreen networks have elected to share similar policies in some areas. However, you will find that the policy structure in Evergreen is flexible and powerful enough to handle almost any workflow configuration you could think up.

There are two contradictory variations on this FUD: that all libraries in an Evergreen installation must share resources with one another, and that all libraries in an Evergreen installation can’t share resources with one another. Both are false. Evergreen is highly configurable; it will support a variety of needs, circumstances, and local policies.

FUD: Anyone on the same Evergreen system can edit a cataloging record!

Response: While it would be possible to configure Evergreen this way, in practice, we don’t know of any Evergreen system where “just anyone” can edit a cataloging record.

FUD: Evergreen is only for very large installations!

Response: If you remove the word “only,” this FUD is true. Evergreen was designed from the ground up to support the 270-plus libraries in the PINES network, so it can and does support large installations with millions of records, requirements for high indexing loads, deduping, high transactions, and so forth.

However, Evergreen scales down quite nicely. One Evergreen user installed Evergreen for his home library, and several known Evergreen installations (including Marshall and Kent), are if not tiny, certainly qualify as on the smaller side.

FUD: You can’t place holds on items in Evergreen!

Response: This FUD falls into the general category of “you can’t do X in Evergreen.” That list of FUD could go on forever. Of course you can place holds in Evergreen, unless your system has elected not to enable this functionality.

Last week, I placed a hold in PINES (after choosing a pickup location convenient to me), got a nice email notice in response (three cheers for email! I could have selected telephone notification, but prefer a notice I don’t have to write down in my illegible handwriting), and picked up my book two days later. Not that I ever doubted it… but like many Evergreen advocates, I dogfood whenever possible.

If you aren’t sure about a capability of Evergreen, turn to its community and ask — or even post a question or comment here — and you’ll get a fast response.

(Thanks to Flickr user ckelty for the great FUD image.)

Bookmark to:

But today’s FUDBuster is a little different: not all FUD is FUD.

This isn’t going to turn into a weepy expiation of everything wrong with Evergreen or OSS. If you know of a perfect software program or design model, please do tell.

Evergreen has its strengths and its growing edges, just like anything else. This blog tends to focus on its strengths — some related to the nature of OSS, some due to its architecture, some due to the people involved in its development — and who can blame us? Creating and growing a product such as Evergreen is quite an achievement for all concerned — GPLS, PINES, the original developers, and everyone else who has since become involved.

I even like alphabetical order

But sometimes stereotypes do often hit uncomfortably close to home. (For example, I own many pairs of sensible shoes, and I also have cats. Livin’ the Library Life!) One stereotype that’s true more often than I’d like to admit is that OSS is poorly documented.

Last week I waged major battle with a piece of OSS (not library-related). The documentation was…and this is charitable…sparse and haphazard. I really wanted to work with this product for a variety of reasons — I could even buy commercial support for it at a very decent price — but the lack of documentation was one of several nails in this product’s coffin, at least for now.

Sometimes documentation is more important than other times. I confess I didn’t look at the Evergreen public catalog documentation until I decided to research all the capabilities of bookbags. I didn’t need to. I’ve been able to search, browse, find, and hold items without asking how to do this, and not, I believe, due to my magical librarian skills, but because the Evergreen catalog is easy to use.

But we do need more documentation for some of our services — reporting comes to mind — and moving forward, we know we also need to ensure we always incorporate documentation into the development process. Plus documentation should also help surface functions that might not be obvious; I intuited more about bookbags that was actually documented — such as the ability to subscribe by RSS — but not everyone might recognize that orange RSS icon. I’ll be writing about holds soon, to illuminate some of their hidden power.

In the end, documentation doesn’t write itself any more than laundry washes itself, and though it’s unsexy and a bit of a slog to produce (also not unlike laundry), it needs to be done.

Prepare Ye the Way

Fortunately, we’re able to address documentation this summer and fall through a grant from the Mellon Foundation that’s specifically targeted at documentation in Evergreen. We’re not putting documentation on our “round tuit” list to be gotten to eventually; we’re not waiting for it to grow on trees, or to float by our river on a lilypad. We’re getting ‘er done, we are, with real resources dedicated to this effort — and then, as is required by all good documentation, we’ll shampoo, rinse, and repeat indefinitely, and integrate documentation into the development process. It won’t happen any other way.

I will say that it’s easier to add documentation to good software than to add good software to documentation. But — not without some lessons-learned — we recognize the two go hand in hand!

– Karen, Equinox Community Librarian

Bookmark to: