Evergreen ILS

Open Source Library Software

Observations and Ideas

Scale Economies

Economies of Scale is a concept from Economics that describes a condition where expanding an activity results in decreasing costs per unit at the margin. These savings result from efficiencies that are realized as the activity increases in size. In other words, being able to do more or make more, with fewer resources spent per unit. For instance, a company could expand production by using a machine already purchased to make more widgets by adding a second shift and hiring machine operator to keep churning out widgets.

In this post we discuss such scale economies that we are observing in the Evergreen community, but before we go into that, it’s important to note that some activities get less efficient as they get larger, resulting in Diseconomies of Scale instead. The Wikipedia article on Diseconomies of Scale summarizes a few of the reasons costs can increase with an increase in size of an enterprise or activity. It is hard not to read such a litany of causes without reflecting on the experience of vendors in the library world which have bought out or merged with competitors.

There are several contributors to Evergreen’s scale economies.
1. Design architecture. Mike’s Generations post discusses the various generations of ILS software. Each generation of software reflects the current understanding of how software is best developed, how databases should be designed, and takes into account the underlying computer technology available at the time. As time passes, new design concepts are developed and computer equipment improves. In time, what was new becomes obsolete or encrusted with ad hoc patches to fix problems with old code.

Evergreen is based on the most current architecture in a time when databases are designed from an increasingly sophisticated understanding of how to create large databases which are robust and relatively inexpensive compared to earlier designs. We believe that the design architecture of Evergreen will scale to handle all the library catalogs and all the transactions of all libraries in the U.S….at least. A bit of work would have to be done but, as said, we believe the foundational design is in place.

2. Consortial design. As Mike and I discussed in Consortial Library Systems, Evergreen was the first ILS designed to be consortial. It was an important breakthrough in library software.

Consortial design in library software has to solve more problems than handling a large online catalog with many transactions. The catalog must be usable, it must be capable of rapid updates, and the software must allow for flexibility in configurations to fit local conditions. With the consortial design, library consortia can scale in another sense: by adding more libraries. Library users like having access to the resulting longer tail of materials and in the Google era, libraries cannot afford the retro option of maintaining information silos.

3. Finances. Libraries in a number of the Evergreen consortia have found that running a large Evergreen consortium is less expensive than paying for separate and smaller implementations at proprietary vendors—often times paying individual vendors separately for ILSs at different libraries. As we know, as Evergreen implementations increase in size, they become cheaper per unit.

This aspect of Evergreen is built on the two previous points: you have to be able to handle the larger databases and you have to have flexibility of configuration to scale in this financial sense. This flexibility of configuration is important. There are Evergreen consortia which have a public union catalog which allows users to borrow resources from other systems in the consortium without mediation from library staff. There are also consortia which have Evergreen configured so that library users cannot do unmediated borrowing from other members of the consortia. Configuration is a local option and we have an unadvertised special: the open source nature of Evergreen allows the users greater control of the library’s software if they choose to exercise that control.

The fact that there are cost savings in an Evergreen consortium can be a mixed blessing. The libraries in at least one Evergreen consortium saved a great deal of money using Evergreen in its new consortium over paying their legacy vendors for the separate pieces of proprietary software; however, the popularity of resource sharing caused the costs of transporting materials to waiting patrons to absorb the savings. Users of the consortium got better service and were happier with their libraries; in addition, library materials are being used more now than before.

There were no net savings in this Evergreen consortium but, in the end, for about the same dollars, service increased dramatically. There was more bang for the buck.

4. Development also scales. With open source development, the code is open to anyone to examine and tweak. As the Evergreen community has expanded, there are more people developing code. Moreover, these are not just random people but people who work in libraries and who have practical ideas to improve the code. The numbers of such people potentially increases with every new library or consortium using open source software. Proprietary vendors have a harder problem with software development both in affording a comparable number of developers, and in the practicality of developments resulting from having those developers be library employees who use the software in day-to-day library operations.

We also discussed a development multiplier in our post about the Evergreen Superconsortium where we described a new type of development that is quickly becoming a mainstream activity within the Evergreen community: consortia cooperating in developing Evergreen capabilities. This kind of development not only increases Evergreen’s functionality but, given that more than one consortium is involved, the development is cheaper and more robust by virtue of the fact that specifications for the development will be broader.

Open source development relies on scratching an itch. That is, if a function does not exist and a library wants it, that library will pay for the development of the function and give it to the community…just as the forerunners in the community have given other functions. Once a capability is developed, then, everyone can have it from that point on for no charge. The same functionality is not sold over and over again once it exists.

Bob Molyneux
Mike Rylander

Thanks to Joe Betz for his clarifying suggestions on the draft’s language.

Why do you do it that way? (or, design rationale)

Yesterday I was explaining to some librarians how Evergreen relates Items (the actual physical barcoded material that circulates) to Volumes (where the Call Number lives) to Bib Records (which contains the MARC), and one person was curious and asked, “why do you do it that way?” The short answer is because it’s good design, but the question momentarily threw me for a loop because the implication is that they’re used to systems which do not do it that way.

Imagine that the structure used for items in the database for your ILS is laid out something like this:

Item Table
———-
Internal ID
Creation Date
Barcode
Call Number
…other fields

In some automation systems, that Call Number field will be a free-text label. If you want to change the Call Number for an Item, then that field will necessarily get changed. If you want to change the Call Number for a large grouping of Items, then you will have to change the field for all those items (sometimes one at a time).

In Evergreen, that Call Number field will actually be a foreign key to another table in the database, one that looks something like this:

Volume
——-
Internal ID
Owning Library
Call Number Label
…other fields

This allows a Call Number to be shared amongst a group of items, and be modified with a single edit.

This is also an example of database normalization.

Why is this important? It has to do with redundancy of information (and I’m not talking about backup storage, RAID’s, etc).

Human beings love redundancy when it comes to communication; our meanings get emphasized by our body language, and the syntax and structure of our languages, both spoken and written, encode information in multiple ways. But redundancy opens the door to discrepancy, and discrepancy leads to ambiguity. Human beings can deal with ambiguity, but computers (and most software developers, and maybe catalogers) can’t abide it. “Time flies like an arrow, but fruit flies like a banana”.

A computer might resolve ambiguity in a non-obvious way, or worse, it may resolve ambiguity in a manner that coincidentally matches a human’s expectation, only to cause trouble later when you start getting data anomalies.

Normalization is a best practice design technique for designing relational database schemas, though there are cases when you want to make a trade-off and de-normalize certain data structures. But those cases are usually optimizations that should occur after you already have a good design as your starting point.

Relational databases are powerful enough that they have sunk into the consciousness of librarians, to the extent that they put down “Must be built on a relational database” in their RFP’s. But most legacy ILS products actually use hierarchal databases, which are good for some things, but not for others. The design decisions made when you go with a hierarchal database are very different than the ones you make when you start with a relational database, and I worry about the legacy products that have “tacked on” relational databases for buzzword and RFP-compliance. Legacy automation may now have relational databases, but are they actually using them as a relational database? Some are, but I know of at least one that isn’t.

Let’s return to Evergreen for a moment. Because Call Number Volumes are represented as their own entities, you have the option of thinking of them differently. For example, you can move a set of items to a different “call number”, one which may be associated with a different Bib Record altogether (or you could move a volume itself to a new bib record). You could even change which library “owns” a volume, and suddenly all the items attached to that volume have a new owner. And you’re able to place a hold on a specific “volume”, in addition to title-level and copy-level holds (and in Evergreen, meta-record holds across editions and formats).

But you can also do what you may already be used to, and change the Call Number for an item (or a batch of items) from an Item Editing interface, and not have to know about the more flexible structures that are being manipulated underneath.

Because we already have Volumes, we’re also in a better place for adding Serials.

There are fewer widespread repercussions to changing an end-user interface than there are with changing your database schema, so that’s why it’s important to have a good database design from the beginning, so that your interfaces have more options. To steal a sentiment from Mr. Miyagi, Evergreen has strong root.

— Jason

Congrats to not one, but two other Open Source ILSs

First I’d like to welcome NewGenLib to the virtual family of FOSS ILSs. In truth, we’ve known about them for a while and have been looking at their serials interfaces during our ACQ/SER design, but now that eIFL is covering them, well… 😉 It’s great to see another entrant, and one that has already found an itch to scratch. I’m sure cross-pollination is in the stars as they seem to have an interesting system.

Next up, a pair of kudos to Koha.

Over the past weekend they added, at a mailing list member’s request, a call number browser inspired by Evergreen’s, which we call Shelf Browse. In Evergreen, because it supports a hierarchical organization of libraries, you can actually browse an entire system or even consortium as one huge virtual shelf! It’s a very nifty feature, and one that we know the PINES patrons have been making good use of (to the tune of 66,965 and counting so far this year, and about 300,000 times in 2007) since Evergreen launched in September of 2006. Now Koha will have a similar feature at the request of a small church Library! This, my friends, is Open Source at work.

By way of evidence from our users, I’ll mention that Evergreen provides call number / shelf browse as a “Quick Search” from the advanced search interface, which is useful to Evergreen users and may be useful for Koha patrons as well. In any case, good work.

I also noticed that Koha has incorporated, as of November of last year according to their source repository’s timestamps, the SIP2 code that David Fiander and Bill Erickson wrote for Evergreen. We’re glad to see the code that GPLS funded is going to good use in and inspiring other projects!

Three and a half years ago, when I first joined PINES and the Evergreen team, there was a dream and a small test server. Now we’ve written more than a quarter of a million lines of code, and that code runs the day-to-day operations of one state-wide library consortium (biggest in the world, he bragged 😉 ) with at least two more in the works, and is helping to build a province-wide consortium in Canada — and let’s not forget the Laurentian/McMaster/Windsor “Unholy Trinity.” These are amazing, and they fill my heart with a satisfaction that is difficult to describe, but none of those things, even as possibilities, are why I signed up. I joined this effort because I believe in Open Source software. I believe whole-heartedly that it is a force for positive change in an industry I love, and fits perfectly with the mission of libraries.

Again, congrats to both NewGenLib and Koha, and let’s keep the cross-pollination going.

–miker