Over recent years, open source software has been finding an increasing role in libraries and other organizations, especially for behind-the-scenes infrastructure components. Apache, Linux, MySQL, Lucene, PHP, and Perl have become commonplace. Firefox has chipped away at Microsoft's Internet Explorer on the web browser front.
We're living in a phase of library automation characterized by an increased interest in open source-not just in back-end infrastructure components but also in the mission-critical business applications such as the integrated library system (ILS). In the last year, interest in open source library automation systems has exploded from an approach supported by a group of advocates and evangelists to a much broader base of library decision makers. Having just returned from the ALA Midwinter Meeting, I'm struck by the high level of interest in programs related to open source software and in the number of attendees gathering around the cluster of booths for Care Affiliates, Index Data, and LibLime-a new generation of purveyors of open source library software.
Open source library automation systems, including Koha and Evergreen, have been propelled into the limelight. An increasing number of libraries are no longer willing to accept proprietary systems and have committ ed to implement open source alternatives. The decision between open source and proprietary automation systems involves many factors. This month's column explores some of the issues that libraries might keep in mind when making decisions to implement open source automation systems versus the traditional alternatives.
Gauging Interest in Open Source
I recently conducted a study on library automation that attempted to measure the satisfaction of librarians regarding their current ILSs, the company that supports them, and their level of interest in considering open source alternatives (see www.library technology, org/perc epti ons2007.pl). I found the results to the open source questions especially interesting. Not surprisingly, automation systems that received the highest dissatisfaction ratings also received ratings indicating stronger interest in implementing an open source ILS. Persons responding to the survey from libraries running Voyager, for example, selected fairly low satisfaction ratings and gave the highest level of response to the question "How likely is it that this library would consider implementing an open source ILS?"
Yet the 1,779 persons responding to the survey generally indicated relatively low interest in open source ILS options. Depending on the automation system currently in use, ratings on a 0 to 9 point scale ranged from 2.27 for libraries running Polaris to 4.27 for those with Voyager. The modal score, or the value most frequently selected, for all systems but one was zero-hardly a resounding cry from most libraries for open source systems.
In addition to the numerical rankings, the survey included a question for general comments. A large number of responders indicated that their libraries might have some interest in open source but that they lacked the technical staff they felt they needed to adopt this approach.
The results of the survey indicate to me that a minority of libraries have strong interest in open source ILS but that this movement hasn't quite hit the mainstream.
Early Adopters
Over the last few years, a number of libraries in the U.S. have made bold moves to migrate to open source ILS options. While open source ILS can't be ignored as an emerging trend, proprietary closed source systems continue to prevail as the dominant model. We can look at the libraries that have already implemented open source ILS as early adopters. Continued success by those breaking new ground in this movement may serve as a catalyst for much larger groups of libraries to adopt open source ILS in the future. I have little doubt that over the next few years, the ranks of libraries moving to open source automation systems will increase significantly. I can also see a few issues that I think currently limit the movement's ability to enter the mainstream. A key factor involves the need for a shift from embracing open source based on philosophical grounds to selecting open source systems primarily on the basis of sound business criteria.
As I look at the various libraries that have committed to implement an open source ILS in the last 2 years among public and academic libraries in the U.S. and Canada, it seems to me that almost all of these decisions have been made based on a philosophical perspective rather than through a competitive process. Many libraries, for good reasons, find themselves disenchanted with the status quo of licensing proprietary closed source automation systems from the ranks of the established ILS vendors.
Open Source Through Commercial Companies
Another major trend in the library automation field involves companies emerging to provide a suite of services and support based on open source library automation systems. While some libraries may choose to implement an open source system on their own, only a small minority of libraries will have adequate levels of technical staff to install, operate, and support an open source automation system without external assistance. Commercial support for open source automation products stands as one of the key ingredients that will lead to increased adoption and will enable this approach to flourish.
Moving Into the Mainstream
Some libraries may make their determination because of their concerns with their existing vendor communities and because they find the promise of open source to be sufficient and compelling. Others, however, require documented evidence on the merits of a system independent of its software licensing model.
Winning the hearts of librarians based on the satisfaction of more freedom (less reliance on vendors) and the promise of complete systems in the future will only take the open source ILS movement so far. For the open source ILS to truly become a major player, I see the need for these systems to compete on their own functional and financial merits. While some libraries may have the ability to make selection decisions through an informal process, many libraries must follow rigorous institutional or governmental procurement procedures. These processes simply will not allow the selection of a system based on a preference for open source.
It is important for any automation system to offer the features, scalability, and reliability required by the library. Features not yet present in a given system must be viewed with the same degree of skepticism from the open source products as would be held with a proprietary system. Why would libraries tolerate vaporware from open source products any more than they would from the traditional vendors?
One mainstream criterion involves the ability to document functionality through the standard procurement processes required in most educational institutions and governmental agencies and companies. An open source ILS, for example, needs to perform well against the boilerplate request for proposal (RFP) documents that the library community uses to extract information from the commercial automation vendors as a means of uniform comparison for functionality, support, and expense. Not that I'm necessarily a fan of the RFPs that ask vendors to respond to many hundreds of questions about details of ILS functionality. This approach, in my opinion, has led to a very static view of the ILS that has hampered the emergence of products that might have offered an approach to automating libraries in new ways more in tune with their rapidly evolving missions. But as long as RFPs continue as the primary vehicle for ILS procurements, the open source products must also validate their functionality against the requirements of the libraries to at least the same degree as their commercial counterparts.
I've written previously on the importance of understanding the total cost of ownership as a library considers implementing any given piece of technology. Technology products and projects involve a whole cluster of direct and indirect expenses that all accumulate to comprise the real total cost to the institution through its life cycle. Some of the financial components include the cost to license the software, annual maintenance for support and updates, hardware for servers, any needed hardware or software upgrades to client workstations, and data center costs. Personnel costs should be determined by assessing the time allocations needed from systems administrators, network managers, security specialists, and systems librarians, as well as the time from other library staff involved in operating the software.
In order to compete on cost with the commercial systems, the companies prompting open source automation systems need to develop realistic total cost of ownership models that result in a budget proposal that a library can compare to those provided by the companies offering proprietary products. By now, no one really believes that open source software is free. The library community knows that the ancillary costs involved in implementing open source software can be significant. Libraries should demand a realistic cost of ownership model that details a comprehensive set of expenses that span multiple years of engagement. Indirect and unanticipated hidden costs that surface after the commencement of an implementation will not foster positive impressions of the open source approach.
Service and Support
One of the greatest impediments that I see to the adoption of open source involves concern for service. Libraries generally believe that they will need more in-house technical staff for an open source system than they would need for a proprietary system.
This concern brings with it great opportunity. As noted above, one of the parallel trends alongside interest in open source automation systems involves the emergence of commercial companies focused on promoting open source systems and offering a wide range of services related to installation, custom development, support, and remote hosting.
As an increasing number of libraries sign on with these companies, I think that we can expect to witness some growing pains. As with the companies involved with the development and support of proprietary systems, a sudden influx of customers presents a tremendous challenge to keep the capacity for high-quality support ahead of daily demands.
Just as when contracting with vendors of proprietary automation systems, libraries need to insist on standards for service. Libraries should be aware of the ratio of support personnel available in the company to the number of libraries receiving support. I've used this ratio for many years as an estimator of the capacity for an ILS vendor to offer quality support. As libraries contract for support for open source systems, they need to have a clear understanding of the expected time for response and resolution of problems, the hours in which support is available, and how urgent issues involving downtime will be addressed.
Another major trend in library automation today involves greater interest in software as a service (SaaS), or what we used to call an application service provider model. Rather than a library installing the software on a local server, it relies on an instance of the application that runs on servers owned, operated, and maintained by the vendor. This relieves the library of much of the technical and administrative effort in operating an automation system. Rather than paying upfront capital costs in purchasing server hardware, the library pays an annual fee to the vendor.
The combination of software as a service with open source automation systems goes a long way toward narrowing the differences between open source and proprietary library automation systems. Since the vendor assumes all responsibility for systems administration and hardware maintenance, the perception that the implementation of an open source system requires more in-house technical expertise no longer applies.
Beyond the Honeymoon
I would characterize the open source ILS movement today as being in a cozy honeymoon period. From an intellectual and emotional perspective, this model of automation resonates with the values of librarians. Will this euphoric state last forever? It might. But it's just as likely that the open source community has to work its way through more challenging times as it seeks to penetrate beyond the initial group of enthusiasts and early adopters.
In order to survive in the long term and work its way up through the ranks of more widely adopted systems, open source library automation systems need to compete head-to-head with the proprietary systems on their own merits and on all the fronts I've mentioned. Winning over libraries already in love with the idea of open source software is easy. We'll know that open source library automation has reached a higher level of maturity when it can compete on its own merits, even in those libraries less favorably inclined to open source for its own sake. In my view, the benchmark of that maturity will take place when open source products compete among others through rigorous and objective procurement procedures.
