Fourteen demos (four by me, ten by the brilliant and accomplished Shae Tetterton), several programs, many breakfasts, lunches, and dinners, and a million-plus “hello-welcome-to-our-booth” greetings later… what a terrific conference!

(My personal favorite moments came every time I was able to clarify that Evergreen is the software, Equinox is the support & development company, and GPLS/PINES are the founding library organizations that got the Evergreen ball rolling. I have such a love of disambiguation…)

– Karen, Community Librarian

Beyond the booth demos, the following events at ALA Annual 2008 offer some Evergreen/open-source/Equinox representation from Karen, Community Librarian (as she ponders writing about herself in the third person):

There’s No Catalog Like No Catalog: The Ultimate Debate on the future of the Library Catalog
Saturday, 1:30 pm - 03:30 pm HYATT Grand A
(It’s massive hubris to call anything “the ultimate debate,” but any panel with at least two Karens is going to be fun, at least in my completely unbiased opinion.)

LITA Top Tech Trends
Sunday 1:30 – 3:30 HIL California Pavilion D
(This is particularly fun, since I feel as if I’m not just talking about a trend — I’m in the middle of it! Though there are many OTHER trends to think about, including outside forces pushing technological change)

LITA Next Generation Catalog Interest Group, where my panel talk will be, ““Running a Free and Open Source Software ILS does Not Equate to a Tightrope Act with No Net.”
Monday 10:30 am - 12:00 pm ACC 213 C
(This will be a fun talk too, though I wish I had the presence of mind to counter-offer with a title that was framed in the positive — as in, “Open source support models: a breath of fresh air.”)

We are now flying over what I call the ALA Cone of Confusion, where we are so close to the air tower we lose radio contact.

In other words, ignore my bold announcement to expect posts here every day; during ALA, blogging here will be light. I fly out tomorrow morning and I will be in Anaheim by noon, Delta willing.

Equinox will be at Booth 1888 (whee — I haven’t worked a booth in three years; this will be fun!) and during exhibit hours we will always have some folks there, not to mention a fabulous demo lineup. Y’all come on by!

– Karen the Community Librarian

Equinox Project Manager Shae Tetterton and I (Karen Schneider, Equinox Community Librarian) will be doing booth demos all through ALA Annual, at Equinox Booth 1888. Shae will focus on the Evergreen software and I’ll be talking about open source in general (in other words, Shae knows her stuff while I’m brand-new…). Both demos should be a lot of fun, if I say so myself.

You can also arrange for one-on-one booth time at ALA — just let us know!

Saturday, June 28

9:15, Shae
10:15, Karen
12:30, Shae
3:00, Shae

Sunday, June 29

9:15, Shae
11:00, Karen
1:00, Shae
3:00, Shae

Monday, June 30

9:15, Shae
11:00, Shae
1:00, Shae
3:00, Karen

Tuesday, July 1

9:00, Karen
10:00, Shae

These presentations will be a little over half an hour, with time for Q&A. See you at the booth, if not elsewhere!

Note: Expect to hear this announcement more than once this week, but Equinox will be at Booth 1888 at ALA Annual in Anaheim (that’s a triple-A statement!). Come on by!

As the newly-minted Community Librarian for Equinox, the open source support and development company for Evergreen, I’m going to be writing at this blog and at the Open-ILS blog as much as possible. I’m going to try to keep my posts short — the blogging equivalent of Lunchables, for readers who are busy and on-the-go — but I’m breaking my own rule with my first post to roll out a carb-heavy five-course post explaining why I took this job and why I feel so passionate about it.

On being at the right place at the right time

A few times in your life you get to be part of something truly important. Sometimes you realize it after the fact, as happened with me in 1989, when en route to my next Air Force duty station I turned on a motel television set to see the Berlin Wall being torn down and realized I had spent that decade as something that had just ceased to exist–the Cold War warrior.

But other times you are fortunate enough to know it right then and there. I remember the night—it was 10 p.m. on a mild evening in New Jersey in 1993 — when after spending a day installing Trumpet Winsock and NCSA Mosaic on my computer and patiently tinkering with inscrutably geekish settings, I rebooted, dialed into my Internet connection, and saw the graphical Web for the first time—huge, glowing images of the planets, courtesy of NASA.

I was so filled with belief and expectant wonder I had to immediately leave my house and drive up and down Route 17 for an hour, just to shake the willies from my flesh. I had seen the future, and it thrilled me to the core. I didn’t know if I would ever again have a moment like that, and that knowledge only sweetened the feeling.

Many interesting events in the world of computing and technology have come and gone since then, but none with the full-tilt amazement I felt that night as I zoomed past strip malls and garden stores and suburban cul de sacs, my brain shimmering with the excitement of being There, in the glory of the era when the Web as we truly know it was born.

None at least until September of 2006, when a small announcement wangled its way into the Biblioblogosphere that Georgia PINES had gone live with Evergreen. By then I had racked up close to fifteen years in libraries–closer to twenty, if you added in my college years typing overdue notices in Columbia’s Butler library and the summer in high school I spent inking book spines for San Francisco Public.

Sad, sad software

I had been part of the Great Diaspora, the pioneers trudging across the plains to move libraries from card catalogs and bound periodicals to OPACs and Web journals. I had a great, fierce belief that technology could improve our libraries, but I was also aware that sometimes, as Walt Kelly’s Pogo was wont to reflect, “We have met the enemy, and he is us.” Most libraries used software so bafflingly bad that when I was a special librarian for a library in the Environmental Protection Agency, my boss, an engineer and an overall smart cookie, took me aside to ask, in a whisper, why library software was so hard to use.

If an engineer can’t find a book in a library catalog, Houston, we have a problem. But it wasn’t any better in the public or academic libraries I worked in. It was all profoundly bad, from the cataloging modules that made it hard to catalog to the acquisitions modules that didn’t work with our vendors’ software to the online catalogs that simply puzzled our users.

It’s easy to point at vendors and ask why our software isn’t better. (Furthermore, some vendor software is pretty good—which has been particularly true of the vendors who have moved into the public-access layer.) But the real question is why we–an organization of information professionals–don’t fix our own problems.

With traditional commercial software, we can’t fix our own problems. We propose, and the vendors dispose. Commercial software is designed around the assumption that there are great secrets to be hidden within the software’s code, and that we buy and use software “off the shelf” — a truism I’ll tackle in greater depth in future posts. It also encourages some very strange and sadly duplicative behavior.

Imagine the same several dozen libraries having the identical problem with their software, but unable to share this knowledge on lists or wikis or blogs, because they (in most case government agencies!) had signed nondisclosure agreements with companies to Protect Their Secrets. Imagine each library using thousands of hours of developer time coming up with the same “fix,” because (bizarrely enough, for librarians) we had signed away our rights to share information.

Now take away the imaginary component and you know my life as a librarian for most of my career. It made no sense, and the more I lived it the stranger it seemed, particularly as outside of LibraryLand I watched open source software expand from the wrinkled-teeshirt fringes of avant-garde technology to embrace the crisp pressed shirts of mainstream automation.

Open source is here to stay

As one librarian commented recently, you know open source is viable because first, people can make money from it, and second, all the commercial vendors use it. That latter fact is amusing (or irritating, depending on your point of view) — the same vendors who swear their clients to secrecy for their super-secret code have no compunction about using open source in their own products. There’s no rule against this — part of the charm of open source is that there are very few rules — but it tells you something that the same vendors who take their clients into smoke-filled rooms and swear them to secrecy have no problem not just using but depending on software whose code is built and managed in the open.

We in LibraryLand have a lot of allied enterprises. Librarians work with many partners–book vendors, technical services companies, database vendors, data enrichment companies, and others–who need to be able to work with our software, and we don’t make it easy on them. There really should be no impediment to hooking up our software with the services of a library support company. We’re all in this together.

A few folks out there in LibraryLand think open source is still the Beatnik of the software world. But another test of open source is that people like me are now working in its industry. I’m not a soothsayer; when I first looked upon the graphical Web in 1993, I was part of the early majority, just barely ahead of the crest of the people who would find the Web.

In the same vein, when I saw the message from Georgia PINES announcing that hundreds of libraries had gone live with open-source library software, I wasn’t part of the visionary crew that had put blood, sweat, toil, and tears into a faith effort that proved to be an excellent bet. I was just a librarian who had an “ah hah” moment, a tingling in my soul that said, this is where we need to be—and this is also, specifically, where I need to be.

Saving room for dessert

You’re pretty full by now — I see the waiter coming by with the after-dinner espresso — so I’ll stop. But so you know what’s ahead, I’m going to use these blog posts to talk about open source: why it works, how you know it is right for your library, how to evaluate it, events and factoids, and what the FUD is. (FUD stands for Fear, Uncertainty, and Doubt, and some desperate vendors are spreading it around like manure on a tomato garden.)

Mostly what I want to do is welcome you to the table. This has been a long time coming, and I hope through my writing to make it clear there’s a place set for each one of you.

(Oh, and thanks to Flickr user Elmada for the great Lunchables photo!)

– Karen G. Schneider, Equinox Community Librarian

Generations dealt with the architecture of Evergreen and summarized its uniquely modern design. This design allows Evergreen to provide individual libraries with an ILS and also large resource sharing consortia. It can function, then, both as a traditional integrated library system (ILS) but also as what we will call a Consortial Library System (CLS). It can be argued that resource sharing consortia are the current state of the art and that in time—and wherever practical—systems will provide such consortial capabilities. Evergreen, then, is just the first such CLS and the next step in the evolution of automating an everything-everywhere national library system.

The term “consortium” is used in the library world to mean many types of things. Here we are referring to a “resource sharing” consortium. Even “resource sharing” however, is also used in several ways. We mean a consortium that is designed to share resources between administratively separate systems. Interlibrary loan can be seen as an early attempt to share resources between separate systems but this method was bound by its cumbersome nature. A CLS changes that because ILL becomes, basically, a type of circulation in a larger but still closed system. In order for these separate systems to share resources with a modern computer environment, there are necessary conditions.

For large systems, one needs a CLS and it is our belief that these systems, once their benefits are understood, will grow first to state networks, and then beyond.

What is a CLS?
A CLS is a software application, or set of related applications, that provides background computer resources for these resource sharing consortia. This type of consortium is one that unites libraries and their users, breaks down information silos, and provides enhanced access to the consortium’s resources for members of the consortium.

When the acquisitions and serials modules are added, Evergreen will also provide consortial ordering and serials control. These capabilities will increase the value of the discovery aspect of the CLS while adding features found in buying consortia.

What should a CLS do?
First, and most importantly, it provides an online union catalog for all items in the consortium. This catalog should be organized to provide users a means to discover the consortium’s resources. Therefore, the catalog should be deduped and items grouped by format, among other characteristics.

Second, the CLS provides a means for the resources to be shared. The PINES experience makes it clear that this aspect of the CLS is highly valued by a consortium’s users. And as a result, at a certain point, the system seems to have begun to generate its own pressure to grow.

Conditions for a CLS
Large consortia will require the ability to handle large databases. This has proven to be the easiest problem for ILSs to solve and although necessary, it is not sufficient for a CLS.

Deduping should be as automated as possible as should grouping of items returned on a search. Deduping still requires human editing, of course, but good programming practice can go a long way to suggesting like titles. Grouping of items by format or subject should be handled via database functions using the catalog records. That way, the results can be improved and updated with better search algorithms. Given the size of these consortium, as much of deduping and grouping like entries should be automated as possible through backend database functions. Consortia grouped by manual processes just don’t scale to union catalogs with millions of records. And a CLS must scale to larger than anything running now.

CLSs will require the ability to handle a large number of transactions. These transactions are circulations, cataloging changes with materials being added and withdrawn, searches, and so on. To handle these transactions, the database must be able to handle rapid, real-time updates. This capability has proven to be difficult to solve in the industry. There are a number of systems that can handle many transactions but the problem is that the other ILSs that handle many transactions can’t update their underlying databases fast enough. They pay the price of their old architecture.

Related matters
Migration into the CLS will necessarily involve migration from a variety of ILSs each with different data structures, configurations, and options. Migration, then, involves a number of tasks, not just bringing in the bibliographic data from the various libraries, deduping the records, and making them available for users. The backend database processing is key, as are the politics.

The political agreements, as Chris Jowaisis has pointed out, are a key to the success of PINES and Evergreen. For this reason, Equinox is developing FullfILLment ™ to do most CLS functions when the politics is not solved in a consortium.

Non-Standards
As a result of combining records from so many libraries, the variant cataloging practices of the various consortia’s member libraries becomes a serious a problem. These varying practices are, of course, old wine in a new digital bottle but their effect is to make the resulting union catalog harder to use and to result in inaccurate search returns. F, Fic, Fiction as shelving/cataloging are well-known but when a search result on a large consortium has these kinds of designations and also those were the same title may appear in more than one Dewey number, you have the makings of a problem that has far-ranging effects throughout the CLS. We have been giving this lack of standard practice thought and have some notions about how to work around it that we will report on in time.

Bob Molyneux
Mike Rylander

ILSs have evolved over time. What started as as a way to manage the printing of catalog cards (1950s and 1960s) eventually morphed into a system for tracking inventory, and then finally into a full-lifecycle management system for general library operations. None of this is news, of course.

What is news is that Evergreen is the first and only ILS to go into production that does not suffer from decisions made 20, 30 or even 40 years ago. Too often I see quotes from respected luminaries in the library world suggesting that Evergreen is simply duplicating what has been done for the last 30 years of ILS design. That means two things, actually:

1. We’ve done a very good job of creating an interface to the Evergreen ILS that feels like what librarians are used to using. This means a shorter training cycle for front-line staff, greater ROI and lower TCO.
2. We may have done too good of a job creating an interface that makes librarians comfortable with traditional ILSs feel comfortable with Evergreen, and haven’t explained well enough just how the core Evergreen is designed and shown just how easy it is to expand services in ways no one has yet considered in terms of an ILS

Looking Back

What we now call the ILS, a product purchased from and maintained by vendors, first emerged in the late 1970s and early 1980s. This is, for all intents and purposes, where history begins.

Over the last thirty years we’ve seen, more or less, three architectural generations of ILS arise from the original proto-ILS. Each generation learns from the lessons of those that came before, as well as from the wider world of software engineering. At each stage there are specific changes in architecture which provide obvious differentiating features that are wholly new so far as the ILS is concerned, but there are also concepts and constructs carried over from previous generations. In addition, there are non-architectural design components that are typical of each stage of evolution, and while the basic architecture of systems at each evolutionary stage may not be directly relevant, there is an identifiable correlation between the overall architecture and these higher-level design decisions.

The Client-Server Age

In the beginning (the late 1970s to mid 1980s) there was the monolithic client-server system, and it was good. Mostly it was good because there was nothing else, and something was needed. These systems were designed to run on the computers of the day; that is, large (for their time) central computers with dumb terminals, or later, thin clients on PCs, for data entry and output. They were (and are, it’s amazing how some of these systems persist) consolidated 2-tier systems that contained all of the logic in a single program on the server.

The back-end storage systems, and in many cases the display engine, were integrated directly into the main program, and required that this one program run on one server. The only way to scale such a system is to purchase a larger server. It is far from impossible to outgrow the largest servers on the market, even today, unless an institution is willing to dedicate a very large portion of their budget to such a system.

Another design constraint of theses systems, though not related to their client-server architecture but still endemic to the age, is that they were never meant to run the operations of more than one organizational entity. There is little or no consideration for location independence. If a staff member has a permission, they have that permission everywhere within the system. In other words, there is no concept of location-specific privilege separation.

Case in point: PINES is the state-wide consortium in Georgia at which Evergreen was initially developed. Although functionality was lacking in their existing solution, an equally concerning problem was the performance of the server during normal business hours. The 48 processor E10K they were running on was straining under the load of a state-wide consortium, and regular maintenance jobs that would not be a problem for smaller scale installations were requiring a mid-day restart of an essential, core service, and a nightly restart of all services. To upgrade out of the red zone would have meant investment in a 2 million dollar E20k, or larger. The PINES budget for one year is around 1.5 million dollars. Putting aside the cost and scaling factors in running such a system, there was no way for PINES to separate privileges based on which library or library system a staff member worked in. Among other things, this meant that PINES could not implement centralized Acquisitions.

The Web Application Age

Then in the late 1990s, scurrying around the feet of the lumbering, antiquated 1- and 2-tier client-server dinosaurs, there evolved the 3-tier web application. These systems are characterized by a nod towards database independence, the use of non-library standards for core functionality, and interface rendering handled by a generic third-party application such as a web browser. Such systems can be made to scale horizontally — that is, the full spectrum of functional areas can be scaled up — by adding more web servers in a dumb cluster, but because all of the web servers must run all the business logic for the ILS, as well as generate web pages for display, this scaling is not linear — one sees less usable per-server capacity added with each new server in the cluster. A related scaling problem is that there is no opportunity for balancing base-line resource utilization against the specific needs of the installation — in a low-circulation, high-search environment the server still has to load and run all of the heavy circulation logic with each instance of the search logic, sapping memory and CPU resources that could be used elsewhere.

These systems also carried over the lack of location-aware privilege separation from the earlier generations. While adding new services to such systems is somewhat simpler than in a client-server architecture, they are still basically a monolithic code-base built to run the operations of a single organization. They are also targeted at smaller library systems lacking the need for some of the more sophisticated business processes of larger institutions. As such, scaling is not a primary concern — and rightly so, with their small-system focus — and is not addressed directly but comes as a side-effect of the architecture, to the level that such scaling exists.

The SOA/Distributed/Dis-integrated Age

In the mid-2000s we see the rise of REST and SOA. New software systems in most industries are being modeled on distributed and modular architectures that allow the dis-integration of services and interfaces. ILSs designed and developed in this time period have the specific characteristic of incorporating concepts of SOA and distributed computing from the ground up. Each functional unit of the ILS is implemented as a service with a well-defined API, and these services can be replaced or augmented over time without the fear of disrupting the rest of the code-base. New services snap in like Legos and are trivial to implement in comparison to new services in previous generations, and service APIs stay consistent across time and even development and implementation methodology. Because ILSs built this way have intentional separation between all service layers (UI, business logic, storage) they can present many different workflow-optimized interfaces to the user, or to other services, while leveraging existing code.

Because of the focus on service dis-integration, resources can be applied precisely where they are most needed, and horizontal scaling is linear in the worst case. Scaling in this architecture is managed through the addition of simple, replaceable commodity hardware, making it extremely cost effective for initial capital outlay and providing the possibility of “just in time” cluster expansion using hardware that delivers the most bang for the buck at the time of need.

Greener pastures

Evergreen is the first production ILS, and only we are aware of as of this writing, to be designed with Service Oriented Architecture (SOA), Representational State Transfer (REST) and “n-tier” architectural concepts specifically in mind. Evergreen achieves this by building services and applications on the OpenSRF (Open Service Request Framework, and pronounced “open surf”) platform. OpenSRF handles all of the details of implementing a stateful, decentralized service architecture and the Evergreen code supplies the business logic and UI framework that matters to libraries.

To provide a specific example of the ease of extension that Evergreen and OpenSRF provide, the online bill pay functionality coming in the next major release was designed and developed by someone that had only passing familiarity with the underlying of Evergreen, or with the OpenSRF framework on which it is built. It was created in about 4 hours, and adds integrated, ILS-wide support for credit card and PayPal payment processing.

Another mistake I hear repeated all too often is the fallacy that Evergreen requires uniform policy definition across participating institutions. This could not be further from the truth — Evergreen supports the most flexible and location aware circulation and hold policies of any ILS available, and can even be extended with ad hoc exceptions to any policy definition via simple rules. This is, of course, unrelated to the architecture of Evergreen, but as it is the only example of a system based on such an architecture, this feature is also endemic to this pattern.

But wait, there’s more!

Another natural consequence of the SOA/dis-integrated architecture of Evergreen, facilitated by OpenSRF, is that most if not all of its code can be re-purposed largely without modification. We at Equinox Software are currently beginning development on FulfILLment, a large-scale, cross-ILS borrowing platform to facilitate the functionality of large ILL consortia, such as state or region-wide networks. This system will leverage much of the organization-aware business logic that Evergreen already provides to support cross-institution circulation in a completely ILS agnostic fashion.

The Future

While neither I nor anyone else can predict what the Next Big Thing will be in terms of application architecture, we can draw some clues from the current state of the art. Bleeding edge application development in 2008 seems to be moving towards refining the SOA model. Efforts such as SOA 2.0 and Service Component Architecture (SCA) point toward a near-term future where SOA and dis-integrated services become mainstream, and service-on-demand and mashups are the norm. If these trends are any predictor, Evergreen and OpenSRF are in for a long ride, especially as more features and functionality are incorporated over time.

Note: Updated 2008-04-22T10:00:00-04 to add some term clarification.

In preparation for the Texas Library Association conference this week, I have been looking at data from public libraries in Texas using the same method I used in a post on the open-ils blog on library characteristics: A Riff on Big. Not surprisingly, Texas public libraries show similar patterns as we saw there for all U.S. public libraries: a few very big libraries and many small ones.

Taking total circulations as in that earlier post, we find the following summary figures for Texas from the same fiscal year 2005 data used there:
The maximum number of annual circulations at any Texas public library was 10.4 million at Harris County. The fourth quartile, though begins at 87,800. That is, one fourth of the libraries in this sample had total circulations greater than that number including, of course, Harris County. One fourth had between 31,732 and 87,800. The central value is that 31,732 which means that half of the libraries had circs greater than that number and half had less. The first quartile—the lowest fourth—had fewer annual circulations than 12,050. As I said, the central value is 31,732 but the mean, that is, the arithmetic average, is 180,574. The big libraries are so big that they pull this average way above the median.

This kind of relationship with circulations exists with most other variables. For example, total expenditures: median (or central value): $ 116,000, while the arithmetic mean is $655,856. And so on through most of the variables that relate to size. The big public libraries in Texas are very big and the small ones are very small.

There are implications to the fact that the distribution of libraries by their sizes and resources have these characteristics. I discussed the profound and worrisome policy implications in more detail in that earlier post but, briefly, differential resources like these numbers indicate have a lasting effect on our notions of a foundational premise in our form of government, that is, an informed citizenry. In addition, in an era where so much is changing in our economy and so fast, continuing education is vital. Smaller libraries have fewer resources to aid a population that is adapting to continuing change and is trying to stay informed. What I neglected to mention earlier, however, is the fact that libraries provide their users entertainment as well as edification—and sometimes both at the same time.

In the Transforming Texas Libraries initiative, there is a clear background of realizing that the changing information environment faced by libraries and the public they serve are changing. Google and this new information environment are affecting libraries.

I have an idea:

Why not put all Texas public libraries in one resource sharing network like the folks in Georgia did? The technology exists now with Evergreen and a related development effort, dubbed FullfILLment ™, that will use the proven Evergreen back end processing to connect to library catalogs that are not using Evergreen through opportunistic connectors and, voila!, you have a PINES-like consortium. FullfILLment is discussed in two long blog posts: anda one anda two. We are working with some other large consortia to get development funding.

What would happen? Well, all sorts of things as the network filled out.

Right now, users of libraries face an information environment with their libraries that resembles “silos” as they are called in the IT world: separate and barely communicating collections of information. In a Google world, library users and potential library users find library resources broken up in small lots while they are now expecting to see the whole panorama of what is available. Interlibrary loan is a sluggish, time consuming, and awkward way of sharing materials between libraries; its cost in time and complication reduces its use and its effectiveness.

Within PINES, however, ILL become “holds” that result when someone searching the local catalog can’t find what he or she is looking for locally and the ILS offers a simple means to request it from another library. The material is already verified and the user authenticated. Without going into too much detail, I discussed elsewhere what I dubbed “The Evergreen Effect” which is what I called the increase in holds coming from the result that Evergreen was easier to use than the legacy software. Holds were up in the 30-50% range and total circulations were up 10% or so. This increase was after the consortium already existed so we have no easy way to estimate how much of a circulation increase came about as a result of a consortium alone. What would all this mean to Texas with its 100 million circs (again, 2005 figures)? Would a 25% increase be outlandish a projection if Texas were to emulate the PINES experience?

Q. Can Evergreen really handle the circulations for all the public libraries in the state?
A. Yep. That is what it was designed to do.

Q. Is Evergreen perfect?
A. Nope. It will do a lot but acquisitions and serials won’t be working until late this year or early next year. But, it will take longer than that to get the libraries loaded anyway.

Q. But won’t this expected increase cause problems?
A. In the short run, very probably. People like libraries and if you make it easier to use them, count on it: they will. Folks will be coming in your library more to avail themselves of a virtual collection that is substantially larger than what they have access to currently. In Georgia, we have seen that library users do not care about our politics but they do love access to the long tail—or at least the “slightly longer tail” than they find at their libraries. The public that uses libraries also uses Google and information silos pain them. These users have been trained to expect better in this era.

More broadly, there are good problems in libraries and bad problems. A bad problem is what happened to many libraries in Louisiana after the hurricanes: they’re gone. A good problem is when folks want to use your library so much that they bust down the doors. Now they tell the mayor what a great job the library is doing so the library director doesn’t have to. The budget meeting without that problem. In Georgia, the legislature has just passed a bill increasing the PINES budget by a third. It is on the governor’s desk and we will see if he signs it. But, the support PINES received in the legislature, I believe, is a result of the support it receives among its many users for having done a good job. A good job means more support.

People like what libraries do and if given the opportunity to have libraries that make more materials more available, the users of libraries will visit them more often. That will likely mean more work in the short run but in the long run stronger libraries and a better informed citizenry that uses libraries. We have the ability to run very large, very dispersed networks now and our users like them. What are we waiting for?

Bob Molyneux

April 1, 2008

The Martian State Library and the Lunar Provincial Library System (LPLS) have selected Evergreen, the open source ILS, for their next-generation library automation systems. Thus, Evergreen’s unique and well-known capabilities as a robust, high capacity ILS will be utilized to provide libraries on the two systems with a unified catalog and resource sharing network. Equinox Software, Inc. will provide migration, on-going support, and consulting services.

Libraries on Mars and libraries on the Moon will each be linked through Evergreen and a single-planet borrower card, thus providing their users with access to all materials in libraries on either planet. More broadly, using FullfILLment ™, a development of Equinox Software, Inc. that uses the Evergreen engine to provide non-Evergreen libraries on Earth with many of the advantages of cross-library resource, work will now go forward on integrating libraries on all three of the major human settlements using the hyperspace transfer protocol as the communications transport mechanism.

A library automation system serves as the technological backbone of the library, facilitating circulation and cataloging of library materials as well as letting patrons search for items online. The Evergreen system was originally created by the Georgia Public Library Service for use in its libraries and has been made available to the libraries throughout the solar system through an open-source license.

Noisette Rhysling, Martian State Librarian, said “We are delighted to commit to Evergreen to power our state-wide library network. Evergreen works now in doing what we want to do and we do not have to rely on promises of what might be developed in some vague future to do what we want to do now.”

Adam Selene, director of LPLS, observed: “Evergreen’s modular structure allows us to accommodate our local configuration requirements and also allows us to use modules from other open source suppliers. We no longer need to rely on companies supplying only monolithic solutions to our libraries and their users. With the enhance content options available through Evergreen’s partners, our users have the best user experience, for the least cost, with the most options.”

About Evergreen

Evergreen is an enterprise-grade open-source ILS initially created to support Georgia PINES, a consortium of over 270 public libraries. Since its debut in September 2006, Evergreen has received significant attention from around the world, including the reception of a Technology Collaboration Award and grant from the Andrew W. Mellon Foundation. Additional Evergreen implementations include a growing consortium in British Columbia, Canada, and new implementations planned for Indiana and Michigan. Evergreen was designed from the ground up to be a flexible, fault-tolerant system capable of supporting libraries of all sizes. Boasting a myriad of standards-compliant methods to access and control data, Evergreen is a robust platform that evolves with the needs of even the most complex library system or consortium.

About Equinox Software, Inc.

Libraries interested in joining the open-source software revolution often face concerns over where to find the technical expertise to take advantage of their desired software products. Equinox Software Inc., based in Norcross, Ga., is a firm dedicated to working with libraries in all aspects of Evergreen, the enterprise-grade, open-source Integrated Library System (ILS).

Founded by the original Evergreen designers and developers, Equinox offers a wealth of experience and expertise in Evergreen development, support and integration. Equinox specializes in customized packages designed for the specific requirements of individual libraries and consortia. Instead of one-size-fits-all support, Equinox works closely with libraries to ensure Evergreen is implemented in the manner that best fits their individual needs. In addition to support, custom development and integration services, Equinox offers complete Evergreen hosting packages for libraries wishing to outsource their ILS infrastructure needs.

For more information on Equinox Software, please visit .

(For both off planet Websites, you will need a browser capable of using the hyperspatial transfer protocol.)

The Martian State Library’s Website is available at hstp://pww.msl.mars/. It was founded in 2032 in Port Lowell, Mars and is the central agency serving libraries on Mars.

The LPLS was established in 2017 with the first permanent settlement and expanded with the burgeoning population after the 2075 revolt. Its Website is available at hstp://pww.lpls.luna/.

This post is an updated version of an attempt last fall to assess the penetration of open source in the U.S. ILS market. There were two posts in LISNews, one on October 15, 2007 and the second on October 19. In summary, they reported that about 1% of U.S. Public Libraries used open source ILSs, depending on the variable one used. The data gathering for this reprise of that study took place on March 3, 2008 and I find about the same percentages now as then.

The point of this exercise was to establish a baseline to measure the growth of open source solutions in libraries. I use U.S. public libraries because there is a universe, national-level data series that gives us a denominator with which to calculate percentages. It is convenient that both Evergreen and Koha, the two major open-source ILSs used in the U.S. have their homes with public libraries and are just beginning to be adopted by academic libraries so the percentages are lower. I used ILSs because they are relatively easy to discover by using Marshall Breeding’s lib-web-cats. The latest national-level data are for fiscal year 2005 so we will be using these data to make estimates of the current state of ILSs. And at this point, the vagaries of data become complex so I have moved the Methodological discussion to a separate page.

Table 1 gives summary data and has two sets of summaries. Back to Table 1 in just a bit

Table 2 has summary statistics for public library systems actually running Koha as of March 3 (there were 15).
Table 3 has summary statistics for library systems running Evergreen (48).
Table 4 has summary statistics for another estimate of public library systems running or planning on running Koha at some time in the indefinite future, according to lib-web-cats. There were 81, including the 15 in Table 1. Note the column to the far right. It has the ILSs actually being run by these Koha libraries on March 3.

Thus,the first two lines of Table 1 are based on summary data from a total of 63 (48+15) systems and the second two lines on a similar total of 129 (48+81) systems.

In these latest national figures, we have a total of 9,198 public library systems. There are about 17,000 actual “outlets” (central libraries, branches, and bookmobiles) in these systems but the detailed data here are only available for systems.I have picked data from these libraries that are indicative and provided totals of those data.

Looking at the top two lines in Table 1, as of March 3, 63 were running either Evergreen or Koha.That is .7% of the total number of systems. However, if you look at population served to measure penetration, it is 1.7%; circulations, 1.0%; if you prefer total operating expenditures, these 63 libraries in FY 2005 were .9% of the U.S. total.There are other summary figures there, but we can say that these numbers hover around 1%.

Last October, there were 62 libraries running either Evergreen or Koha and, using FY 2004 data, I found these were .67% of systems and the other figures were roughly similar to the March figures.

A New Wind Blows

Recently MassCat and WALDO announced that they will be working with LibLime implementing Koha. Also recently, the Indiana Open Source ILS Initiative and the Michigan Evergreen Project committed to work on Evergreen implementations with Equinox Software. All libraries in these consortia will not be implementing these plans tomorrow and some libraries in them may not implement either Koha or Evergreen ever. For instance, WALDO’s implementation of Koha is apparently to be with a subset of its total membership. 24 academic members with each maintaining its independence according to my understanding of what John Stromquist, Executive Director of WALDO, told attendees at the VALE Symposium. Given the state of my hearing, I would like to see the film when it is posted on that site.

These announcements plus other work in the pipeline indicate the low numbers seen so far are forming a foundation of faster growth ahead

Bob Molyneux