Month: October 2008

Eric Lease Morgan
University of Notre Dame

MyLibrary is about creating relationships. It’s a way to catalog resources — very broadly defined (people, databases, books, you name it). MyLibrary invented about 10 years ago, had a lot of success/popularity then. Concept of “my library” picked up by others such as MyILibrary, etc. It was a turnkey application — download, install, and run. It was simple, and it worked, but wasn’t as complex.
MyLibrary is made up of four kinds of resources:

1. Resources
2. Patrons
3. Librarians
4. Facets and terms

All of these resources are stored in “Dublin Core-esque” data structures. Patrons in system have name, major, etc. Librarians have name, subject areas, contact info, etc. Resources have material types, subjects, academic level of primary audience. All of these descriptive terms are “facets and terms”. Facets are classes of terms. For example: format: book; subject: forestry; and so on. You can have as many facets as you like, and as many subjects under each facet. It’s all 2 levels deep.

Examples

Examples from the Notre Dame site:

• Research tools — lists of research tools
• Subject
• Reading list — combination of things classed “format: journals” organized by subjects. This was created via OAI from the Directory of Open Access Journals. Specific subjects or specific journals can be added to “my library.”
• Facebook MyLibrary widget. It’s not “facebook” that’s important. The fact that the MyLibrary toolbox allows it to happen is important.
• FAQs — each frequently asked question/answer pair is a resource. They’re cataloged. Then they are browsable and can be displayed on relevant subject or topic pages.

MyLibrary is not meant to do everything — just managed “piles of stuff”. It does not support search. It does not support OAI. But data can be pulled out of MyLibrary and fed to a search engine. For example, Alex Catalogue of Electronic Texts. Browsable and searchable lists of 14,000 full-text public-domain books.
MyLibrary is not a particularly strong open source project — there isn’t a community around it, for which Eric takes blame. It’s in Perl, but that’s a passé language now. Coming up is a web services interface on top of it, probably Atom. But some sort of RESTful web service is coming.
Question: It’s been in operation about 5 years; how are students using it?
Answer: Students don’t know they’re using it. They don’t customize it — it’s just the way the web site work.
Question: What are privacy issues with patron data?
Answer: Librarians take privacy more seriously than patrons. Patrons expect easy to use interface that gets them what they want. Libraries are behind the curve on this. MyLibrary makes some broad guesses about what patrons are likely to want. Any future personalization effort will be opt-in. Individuals won’t get assigned resources, but aggregates (freshmen, math majors, etc., not John Smith).

Dale Askey
Kansas State University

Libraries are not particularly good at making their own code open source and sharing. This is especially true of the small, lightweight applications that we build to make ILS systems “work right” or to solve small problems. These are frequently small (a few hundred lines of code). Why not? Several reasons…
Perfectionism — the code’s not ready yet, there are bugs, not commented well, it’s inefficient. Even though it gets the job done — which is really what counts, many developers are hesitant to share their code with others.
Dependency — we don’t want to be supporting you; we can barely support ourselves. Putting it in a repository, with documentation — a good idea. Puts a bit of distance between developer (library) and user. Rutgers is planning to launch a library open source platform — but it hasn’t happened yet (announced in April 2008).
Quirkiness — What we do is so unique there’s no point to releasing it; our problems are ours alone. This is false; while the exact problem may be different, but the general problem very often is shared. But — if you don’t share the code, you end up with the full support and updating burden. There’s nobody else who can help you find and fix bugs, add new features.
Redundancy — Perfectly good software already exists that works for most people, so why should we offer our own? Good enough — the available solution — is often seen as better than doing it oneself.
Competitiveness — Our code is better than someone else’s, so we want pride of ownership and don’t want to share it. We build our own to be the best, not to share the technology. Institutional Repositories are a case in point — institutions develop/implement their own but all too rarely share their successes to save others time.
Misunderstanding — Administrators do not understand nature of OSS tools — they understand and know how to deal with vendors. Functionality can be built on a good foundation — the open source tool — and customized. This is the antithesis of what vendors offer. Open source puts responsibility for getting it right in institution’s hands, not in a vendor relationship.

What Can We Do?

Figure out a way to share software among libraries. There are methods for “big stuff” (Koha, Evergreen, etc.). But what about small stuff? Several initiatives, but none global Google code is one, but it doesn’t meet everyone’s need and isn’t accessible to non-technical librarians. A library-specific repository might be useful.
Put a license on our code and let it go when asked to share it. Even for the small snippets.
Commit to the necessary human investment to build and maintain open source software for our own good.
Reward staff for contributing to open source communities. This should be viewed as a form of professional development/contribution.
Re-prioritize internally to make open source contributions happen.
Favorite soundbite from Dale’s talk: “Minesweeper is like digital heroin.”

Keynote: Karen Schneider
Community Librarian
Equinox Software (Evergreen)

Karen Schneider on “Open++: Dispatches from the OSS Frontlines”. Karen’s job is to travel around Georgia talking with libraries around the state helping them with the Evergreen installation.

Evergreen

We’ve seen lots of open source software in libraries in recent years. Tons of experimentation has taken place, lots of it by and for libraries.
Pines had a need for a consortial catalog for 270+ libraries across a large state. Some vendors said they couldn’t do it; others offered far-too-expensive options. In 2004, a development team started building their own ILS. In 2006, Evergreen was launched in 200 libraries. Version 1.4 is imminent (first couple weeks of October). They have kept a tight development cycle.
Key point: With Evergreen, librarians are once again writing their own ILS. This is analogous to what happened about 30 years ago (for example, with the Melvyl catalog, built at home in pre-vendor times). In recent decades, libraries strayed from path of doing their own stuff and went down the vendor path. Now, we’ve come full circle and libraries are once again starting to take control of their own destiny again.
Network effect has been huge (combined with general state of economy and price of fuel): holds and interlibrary loans within the Evergreen system is growing exponentially.
There are now 275 libraries in PINES. Other consortia include those in British Columbia (Sitka) and Michigan. There’s also an academic installation — Indiana University — live now. In development are other consortia, including an academic one. But these are just the “known” sites — it’s open source, so many other K-12 schools likely use it.

Observations about open source and libraries

1. Documentation is critical — must be a formal requirement. Documentation doesn’t come easy. Evergreen got a Mellon grant to write it — but that’s not the normal path.
2. Trickle-up Engagement: Originally, it was thought that libraries would automatically know how to “do open source.” However, that turns out not to be the case. Libraries need some help getting started — getting re-engaged in the software development process.
3. Gift economy: Community around Evergreen is small, skilled, and dedicated — a smaller community of developers than they initially expected. People contribute actively, though not as broadly.
4. A surprising revelation: end-users are all alike – but library workflows are unique. Users are much more similar than libraries. Evergreen has a very flexible back end. This turns out to have been a very good idea. Flexibility in the workflows is critical.

Features of Openness

Open has several positive features. Communication becomes distributed — no longer vendor-contact, it’s many people looking, many people fixing. Many eyes makes a better product, with many hands to fix them. The network effect is significant on the library side: the more libraries participate, the better. Local issues and requests lead to global improvements. Customization is the user side of back-end flexibility. Fosters partnerships — there’s no need for secrecy, keeping vendors in the dark about local implementation, and libraries in the dark about vendor plans.
Cost — it’s not necessarily cheaper to go open source, but it moves the costs around from licensing to updating/maintenance.