by Kyle Hall, Cindy Murdock Ames, and John Brice

Introduction

How does a rural Pennsylvania county library system develop open source solutions that are used by other libraries? A more important question is why does the Crawford County Federated Library System, with slightly less than 100,000 citizens and nine libraries develop open source solutions? The long version of the above two answers is presented in the article below. The short answer is that we can. Actually, any library can.

American libraries embraced computers as soon as the technology was practicable for use. Unfortunately, the computers at the time were large, required engineers from MIT to write the software, and were quite expensive. The necessary know-how to setup, manage, and support such systems was best left to large corporations with libraries purchasing their services. Even the biggest libraries in the country could not develop their own circulation systems. Even when libraries formed consortiums to develop software it was very expensive to market and distribute circulation systems. For all these reasons, circulation systems, which eventually became Integrated Library Systems (ILS’s), were eventually spun off to commercial interests.

Today, technology has become ubiquitous; software languages are accessible to individuals with the proper training, and programming is taught in every reasonably sized university. Communities of like minded libraries can collaborate using the Internet around the world for free. Once an Open Source project has been developed and released it can be distributed, again for free, and it can be updated and changed as more libraries give their input. Eventually successful Open Source projects develop vibrant communities around them. All of these trends have resulted in libraries now having the tools they need to develop, maintain and distribute their own software, as well as take advantage of the work of others. For example, any library using the Apache web server to host their website is benefiting from the open source methodology.

As you read the rest of the article we ask you to think about what impediments are in your organization’s way to do what we do. We would hazard to guess that most of the impediments are how things are done traditionally, not necessarily what can be done now with current technology and open source methodologies.

The Road to Libki

The Crawford County Federated Library System has been using OSS (Open Source Software) in its IT operations since around 1999, beginning with some basic floppy-based routers used to share a dialup Internet connection among each library’s computers. (Please see http://meadvillelibrary.org/os for a full listing of all of our OSS projects.) Following the success of that project we recognized the potential of OSS, integrating it increasingly into our infrastructure.

From that first project onward we decided that whenever possible any future new IT solution we offered our member libraries would utilize Open Source software. We made this decision for a number of reasons. First was reliability. We were frustrated with commercial products that were a closed book to us, relying on reboots, fresh installs, and/or phone-based tech support to attempt to resolve problems, often unsuccessfully. We found the hands-on approach to resolving issues with OSS to be a refreshing alternative; generally with a bit of web searching or queries on appropriate mailing lists or IRC channels we could find solutions to most of the problems we encountered. Secondly, developing our own solutions with Open Source software allowed us to gain control of hardware purchases. Numerous times we had to allocate precious dollars to replace perfectly fine computers because they no longer met the specifications of the latest commercial software. By choosing to use OSS software on desktops and servers we were able to extend the life of much of our hardware. The third issue was customization; we could customize Open Source software to meet our needs, from locking down public desktops to creating custom websites and services for our libraries. Finally, the last reason was the cost. In addition to saving money by being able to extend the life of our hardware through the use of OSS, we were able to save considerable funds with OSS since it is largely free, unlike most commercial software, and doesn’t require the payment of per-user or per-seat licence fees.

Of course, no solution is completely free; with OSS you might save funds on software and license fees, but there are costs associated with hiring staff capable of installing & managing it. However, we have found from our first OSS project onward that the costs of such employees can be considerably less than many organizations pay for commercial software solutions. Furthermore, our IT staff were able to apply the skills and knowledge gained implementing OSS solutions in our libraries to a wide variety of projects, since OSS projects are often built using many of the same tools.

Our first OSS project, shared dial-up Internet access for our libraries, was done in desperation because CCFLS had written a grant based on what became vaporware software. Back in the late 1990’s before broadband was available in rural communities, we needed to construct dialup routers for our seven rural libraries in order to provide staff & public Internet access. We estimated the cost of using a commercial software and hardware setup at about $3,150 per library or about $22,000 total, money which CCFLS did not have. Through a local contact (one of our rural librarians was married to a college professor who had learned Linux to build his own weather station) we found a Linux expert for free. The consultant found the Linux Router Project (LRP), a floppy-based Linux distribution that could convert an old computer into a router and firewall. We purchased several old 486s on Ebay, spending about $40 each. We removed the hard drives, installed 56k modems, and simple as that we had shared network Internet access and a firewall. What was great about this solution is the systems were relatively hackproof (the floppies were set up for read only) and very easy to maintain. Total cost of the project was less than a $1,000. The last of the dial-up servers was retired after five years of trouble-free service.

Realising that we could save a considerable amount of money using Open source Software and understanding that we couldn’t get free help all the time we then hired this same Linux expert to train Cindy Murdock Ames, our IT Director, to use Linux. The total cost of the training was less than $2,000.

Using the strategy of using our own internal resources for Open Source Solutions we started replacing our proprietary solutions. The next project after the floppy-based router project was to replace our Microsoft IIS web server with a Linux-based one running Apache. Not long after we replaced our public Windows desktops with a Linux-based thin client solution called LTSP (the Linux Terminal Server Project, http://ltsp.org), in January 2000. The LTSP-based thin clients provide patron Internet access as well as an office suite (currently LibreOffice). We also use them as public catalog computers within the library.

Of course reading all of this on paper makes it sound like it was a snap. It was not! On just the LTSP project alone the development work took over six months, mainly because it was our first large scale project and the learning curve was quite steep. However, we were able to take the skills gained from implementing LTSP and apply them to many other useful projects, such as building OSS-based routers, filtering public Internet terminals, customizing staff & public desktops, building websites, fileservers, and so on.

As for the cost savings of the LTSP project we saved a considerable amount of money over the lifetime of the project. Instead of purchasing new public computers we purchased new hardware to upgrade our old computers, repurposing existing cases & power supplies. The cost of upgrading the hardware for our seven original thin clients plus the LTSP server totaled $3,779.25 (the server cost $1,485, the upgraded thin clients were $327.75 each). Our average cost per seat for 15 thin clients plus the server was $426.75; we priced the same number of Windows-based thin clients and server at $1,649 per seat; according to CNET the average cost for a Windows-based PC in January 2000 was $873. However, if we had chosen Windows-based PCs we would additionally have had the cost of software to lock down the computers for public use, which we were able to accomplish inherently with Linux. We used those upgraded computers for over ten years before they were replaced by newer hardware, though we did replace the server twice during that ten-year period. Not having to purchase new computers every three years and new software every three to five years saved just one library in our system at least $31,000 (two replacement cycles for hardware and three for software and licensing for 15 terminals) over a 10 year period. During this time we did not increase staff size, and development work for OSS projects was done around the normal routine of system maintenance and training.

We culminated the switchover to OSS by migrating from the Winnebago CIRC/CAT ILS to the Koha ILS in 2005. The actual migration cost from Winnebago to Koha was slightly more than $45,000 for 9 libraries (two medium sized libraries and 7 rural libraries). This cost was in line with what other proprietary vendors quoted us for the migration. The cost of migration for a library working entirely on their own to implement Koha would not likely be this high today–most of our cost was hiring one of the companies that supported Koha to integrate IndexData’s Zebra indexing system into Koha so that it could support libraries with collections of our size or larger. Our initial costs included the purchase of a server and staff programming and development time; we developed our own staff front end for Koha as well as many custom reports, since we had full access to our data with Koha. At the time there were no current costs associated with Winnebago CIRC/CAT, since it was no longer supported by Spectrum, the company that currently owned it. We had looked at Spectrum’s current offerings but felt that with our past successes with OSS we could get more out of a migration to Koha than going with a commercial vendor again. Since Koha is entirely web-based we would not be limited to using Windows on circulation and catalog computers, so we were also able to convert our staff computers and public catalogs to Linux desktops or thin clients as well, saving us both future Windows license fees and freeing staff from supporting a Windows desktop environment. Furthermore, since we could support Koha in-house there are no annual support fees involved. The only ongoing cost with Koha is in planned hardware upgrades and staff.

With our decision to migrate to Koha, we also decided to hire Kyle Hall as an addition to our IT staff. Since Kyle has a Masters in Information Technology we could use his skills as a software developer to guide the direction of development to meet our organization’s needs. In essence, we leveraged the cost savings of choosing Free software into hiring staff instead.

One interesting aspect of using an open source ILS is that we were able to install it as a proof of concept system, exporting the data from our current ILS into a test Koha installation. Using these proof of concept servers our library staff could test drive Koha as much as desired without having to purchase any software. We were also able to make repeated test runs of the migration process to ensure that all our data was migrated as expected. We were also able to migrate each of our libraries from their individual installations of Winnebago to our centralized Koha server on our own schedule, over the course of several months. If we had hired a company to migrate us to a proprietary ILS we might not have had that flexibility. When we migrated each library we would shut down their old system on Friday or Saturday at closing, migrated all their data, and then they would open on Monday using Koha with all their MARC, patron, and transaction data intact.

Once we had a developer on staff the question became how to best use his time. In the beginning a great amount of Mr. Hall’s time was in developing, improving, and customizing Koha for our own use. Once those projects were finished our librarians suggested we find a better way to manage patron time on our public access computers.

Since CCFLS had been using Open Source Software for several years on most of its public computers, it was a logical choice to use OSS software for patron time management on those computers. Almost all the public computers in our nine libraries are either standalone Linux workstations or Linux-based thin clients. At first we tried to use existing OSS-based solutions for patron time management, but none of them met our needs, so we made the decision to develop it ourselves.

How was Libki developed?

The inspiration

The development of Libki was inspired by Kyle Hall’s (the developer) idea to automate our member libraries’ signup process for public Internet computers. In the beginning, the library simply used a signup sheet for patrons to sign in with their name and the time that they logged in. A librarian would need to constantly check this sheet to see if someone had used up his or her allotted time. When a patron’s time was over, the librarian would have to approach the patron and ask them to log off the computer so the next patron could use it. This method of time control served only to complicate the librarian’s job.

The search

Libki was born out of a search for a kiosk management system that fulfilled our requirements. Though many such systems exist, none met the library system’s basic requirements. Those requirements were that, A) the software be cross-platform and run on both Windows and Linux, B) the system be completely Free Open Source Software, and C) would use the existing barcode number and password used on our Koha ILS for patron authentication. In addition the librarians required that the administration functions of the program allow them to add time to a patron’s account, view who is on the public computers at any given time, send messages to patrons, and kick patrons off the system if necessary.

We first evaluated existing open source solutions to see if they would meet our needs.

The first candidate was OpenKiosk. This software seemed to fit the requirements exactly. The source code was released under the GNU Public License, and the client would run on both Linux and Windows. However, further review discovered that though the author may have adhered to letter of the license, the spirit had been violated. The client half of the system would compile under Linux, but to compile it on Windows required a special file that was not made available. To obtain a Windows compatible version of the client required payment for each release. To quote the author’s website:

The Windows client uses the same source code from the Unix client but it is not linked to any GPL’d Qt library. However, it is interfaced to a Qt-like C++ Win32 layer. This way, source code between the Unix and Windows clients can be shared without any major changes.[1]

This combined with the fact that the author had announced he would be ceasing development lead to the abandonment of OpenKiosk as an option.

The second candidate was far more promising, OutKafe. Very similar in features to OpenKiosk, OutKafe was indeed completely Free Open Source Software, with no catches to be found. In testing, the software appeared to work without issues. The design of OutKafe included a database of users names, password and statuses, the client software that ran on top of an operating system (Windows or Linux) and the administration software. However, it was discovered that the administration software, though compatible with our Linux operating system in use at the time, was not capable of running correctly on the LTSP server it would be deployed on.

The seed

So with no viable existing Open Source options, the decision was made to tailor OutKafe to meet our needs. The project started out as simply a web-based replacement of the OutKafe administration program, while retaining the rest of the OutKafe application. The OutKafe client and server were designed not to interact directly with each other, but via database access using the Postgres DBMS. Both sides of the software would connect directly to OutKafe’s database and make updates to it that the other could then read. Though not the best design, it made writing an alternative administration interface easy. This new administrative interface was released as Free Open Source Software using the GPL under the title outkafe-web. So at this point our Kiosk management system consisted of two components (client and database) written as OutKafe and one component (Administration) written by Kyle Hall.

Soon it became apparent that the process in OutKafe that managed the decrementing of time used had to be rewritten. Then came a request to customize the client interface. These customizations were not possible with the client as written, and Kyle was not familiar with the programming language (Pascal) in which the client had been written.

The birth of Libki

Since our evolved solution could not meet the demands of our librarians we decided to create our own solution which included all three components (administration, client, and database management) written by Kyle. After a period of about nine months of on and off development all of the original parts of OutKafe were replaced. The new replacements were packaged up by the developer and released as Libki, a Free Open Source Kiosk Management System.

Libki was first installed at the System Headquarters library and went through a three plus month testing period to work out all of the kinks. Training was needed on the staff side and the program had a few bugs that needed to be fixed. After an appropriate amount of sorting things out we then presented Libki to the rest of the libraries in CCFLS. Most of them chose to use it.

Though not perfect, the system worked, and continues to work for libraries in the Crawford County Federated Library System and elsewhere. Though the number of institutions using Libki is unknown, a few have contacted us to thank us and some have contributed in support of Libki development.

The advancement

Though functional enough to be used by many libraries over the years since its release, the developer realized that there were a number of areas in the software that could be improved.

Both the client and server required direct database access, a holdover from being a replacement for a different piece of software. The administration web interface required full page refreshes to update the data about the patrons and clients. In other words, if you left the administration page open for any period of time the data would quickly become stale. In addition, the client software was slow to load.

These deficiencies in the current version of Libki have led to a complete ground up rewrite of the entire system, Libki 2.0. First, the client was rewritten in C++/Qt4 a language that allows for much faster startup times and better integration with the host operating system. A ‘shim’ was written for for the existing server to allow it to communicate directly with the server, rather than the previous method of direct database access.

Currently, at the time this article is being written, a new administration system is in development. Web-based, like the previous iteration, it is vastly improved in nearly every aspect, both visually and mechanically. This new server leverages AJAX to allow for constantly up to date information to appear on the page. It additionally can display a history of client usage, and also has a permissions system to limit staff from changing system settings.

Another big improvement for Libki 2.0 is support for the SIP2 protocol. The current version of Libki integrates with the county’s ILS by leveraging the Open Source nature of Koha. Kyle was able to modify Koha to send alerts to the Libki servers across the county in order to add, update and delete accounts as they exist in the Koha ILS. By adding SIP2 support to the system, Libki can simply make a request to the ILS to authenticate a given user and act on the results accordingly. This advancement also allows Libki to have single logon integration with any ILS that supports SIP2.

The current status as of November 2012, of Libki 2.0 is that it is up and running on a test server getting ready for Beta Testing at System Headquarters. It will probably take about a month of Beta testing before being released for production. The current code of Libki 2.0 is available at SourceForge.net via Libki.org. At this point future possible enhancements include reservation of kiosks, as well as print management and payment.

Discussion on CCFLS OSS Strategy and how it relates to the rest of the world.

If you do the math the total amount invested in the project is slightly over $15,000 including labor and hardware costs. The biggest cost of the Libki project was Kyle Hall’s time. CCFLS is located in Northwest Pennsylvania, which is an area of the country with a very low cost of living compared to much of the US. Therefore development staff cost here is actually on par with what a large urban library would pay a professional Librarian I.

The process we have followed with OSS projects and development is that we identify a need, investigate the OSS solutions available, determine if development is necessary, develop the software, create a proof of concept system, get feedback from our librarians, develop a beta test version and launch it in one of our libraries, and then finally roll it out to all of the libraries interested in the product.

The actual development time is not budgeted, it is just one of Kyle’s duties. Kyle, at the time of the Libki project, not only wrote code but also installed and maintained computer systems throughout the county libraries including tasks such as running network cables, installing security systems, and researching possible software for adoption in our libraries. Development was done outside of other routine tasks or during times when it was not practicable to visit other libraries such as in bad weather. Currently he does development work for CCFLS part-time while working for ByWater Solutions as a Koha developer full-time.

When analyzing this situation it is easy to say that what CCFLS does cannot be replicated at other locations. CCFLS hired a programmer at far below market rates, used him for routine IT chores and does development when it suits the schedule. However, if you analyse the situation further we figured out how to do open source development even though we have a very small staff, very limited funding, and difficulty recruiting people to northwest Pennsylvania due to our low pay and long winters.

The strategy we followed was to train our existing staff on OSS operating systems, use all of the available sources of free support available, hire smart individuals from local state universities who were content to stay in our area, and develop one project at a time with no firm due date for roll out. Will this exact technique work for every library in the country? No. What we wish to say here in Crawford County is that OSS tools and individuals trained in their use are more readily available now than ever before. By mixing and matching the latest tools and resources an effective OSS development or adoption strategy can be developed by any library. It just takes a fresh perspective, a willingness to think in nontraditional ways and full management backing in order to formulate an effective plan for developing and/or adopting OSS for libraries.

Conclusion

Overall the development of Libki has been spread out over five years with an estimated 500 hours of development time. For that effort CCFLS has had the use of an efficient and free kiosk management program. The program is available for free to anyone wishing to use it and we do know that numerous libraries have benefitted from its use. A representative from Coos County Libraries shares his experience:

We utilize Libki in 5 public libraries and 1 academic library in our consortium. Libki has enabled library staff to remove themselves from distractive public computer management chores while allowing them to concentrate their efforts on circulation and reference services. With an easy-to-use staff interface, and support for OSS as well as Windows, Libki is a perfect solution for public computer time management in a public library.

Did CCFLS save money with this project? A closed source solution for nine libraries over the same period of time would come close to the same amount of money that we spent developing our own solution. However, we now have kiosk management that exactly meets our needs. If there are issues that arise we can fix them ourselves, there is no waiting for the next release to be made available in order to fix bugs and no reliance on external support services. In addition, as the product matures and other libraries help contribute to the development of the Libki project, our yearly investment decreases. So if you look at the total value of Libki to CCFLS in the first five years it was a zero gain proposition; however, going into the future we save money. This is typical of other open source projects we have done. The original cost is similar to commercial solutions; however, the savings downstream can be tremendous and can be invested into development of other projects plus the library community gets a dividend of a new open source program.

It can be said that the Libki project shows what can go wrong with open source development. A simple project to implement time management using open source software was not possible. By changing one aspect of an existing program we could make it work. Once we had it working we found we needed additional capability. So, we had to do further development to the point where we eventually had to rewrite the rest of the program. Once we got that second solution up and running we decided to make it even better and include the latest software (Ajax) and standards (SIP2) to the program. So, once again, we redid Libki to make it better. So to get there we had to do basically three versions of the program. Would we have been better off writing a fresh program to begin with? Maybe, but chances are we wouldn’t have gotten it right the first time anyway. The end result is that CCFLS now has an up to date Kiosk management program that seamlessly ties into our Koha ILS, all for the cost of a similar commercial system that wouldn’t necessarily meet all our requirements.

The upside to all of the work and treasure spent so far is that not only does CCFLS have free access to Libki, but so does the rest of the library community. This is exactly the type of collaboration that all libraries should consider. We know the excuse will be given that not all libraries can afford to hire a developer. However, if we all have to hire accountants for the finance department or catalogers for technical services shouldn’t we consider that programmers are a vital component of a library as well? Shouldn’t a developer’s skills and abilities be included in a library organization? We here in the rural forests of Pennsylvania believe that the answer to that question is yes.

End Notes

[1] http://openkiosk.sourceforge.net/dw.html

Author Information

Kyle Hall is the project manager of Libki and a software developer at Crawford County Federated Library System. Cindy Murdock Ames is the Director of IT at Crawford County Federated Library System. John Brice is the Executive Director of the Meadville Public Library and the CEO of Crawford County Federated Library System.