"The principles and practices of open source software are very similar to the principles and practices of modern librarianship. Both value free and equal access to data, information, and knowledge. Both value the peer review process. Both advocate open standards. Both strive to promote human understand and to make our lives better. Both make efforts to improve society as a whole assuming the sum is greater than the parts."
We all know that feeling in our gut, that moment when it's time to sign the order for a new software program for your library. It's accompanied by a host of nagging questions: "Is it the right decision?" "Have we overlooked anything?" "Will this work?" "Have we considered all the options?" The decision to acquire or upgrade a library automation package is never an easy one and every director, when faced with this decision, wants to choose the best package at the best value that most fully meets the needs of users. Today, that decision is complicated by a new option, that of open source.
This article will examine when and why open source software (OSS) might be appropriate for your library. It also discusses why so many libraries are moving towards OSS and some of the disadvantages to be aware of when deciding to move in that direction.
Why are Libraries Moving Towards OSS?
Libraries are moving towards open source for a variety of reasons, but many find that their reasons share a lot of commonality such as:
Commodity/Infrastructure technology. Open source makes sense when a software product reaches commodity or infrastructure status. That status allows users "to obtain components (or even complete systems) on the open market and leverage economies of scale". In libraries, it could be argued that integrated library systems (ILSs) have reached that status.
Consolidation. Libraries have seen a great deal of consolidation in the last few years among ILS vendors and federated search applications. As vendors consolidate, it raises concern among current and potential users of a product. While not always the case, there have been examples of software businesses that are more focused on short-term profitability and resale than meeting the longer term interests of their customers. The end result is staff downsizing, product lines being terminated or consolidated, and customers being stranded on a product without support options and being forced to migrate to a new product. Administrators, as a result of this experience, are looking for alternative options and for continuously evolving software that allows them to control the speed and direction of their library migrations. That's one promise of OSS.
Equivalent functionality. Many open source products are still fairly young and don't have the same level of functionality as proprietary library products that have been in the market for many years. However, because of the way open source development leverages large communities of developers, a committed effort can rapidly replace key missing functionality. While it will depend on the needs and capability of a library, many find this a satisfactory solution for missing functionality.
Ease of procurement. Procurement processes are frustrating for both libraries and vendors. Libraries are burdened with purchasing office and legal conditions, as well as tedious and costly document preparation. Open source offers the potential for a more streamlined procurement process as many libraries download the OSS application, install it and test it against their needs. In the proprietary world, this option may not exist, or may be a limited-functionality or a time limited version. If you want commercial support for the software and/or custom developments, then you can issue a request for proposal (RFP) for service on the product. Because this is a much more focused procurement, the document will be smaller and more manageable than the document for proprietary vendor products. With OSS, libraries are finding a better way to examine the product at a lower cost.
More reliable products. One of the advantages of OSS is that the associated community of users and developers can be larger than for some proprietary solutions. When that is the case, there is likely to be a greater level of peer review, not only for the specifications for new features, but also for the code that is written to implement those new features. The result is a more reliable product.
No vendor lock-in. When a library adopts an open source product, they have access to the source code. This means that the vendor can't lock them into their proprietary customer base and the library is once again in control of their future. With open source, if their service provider/vendor were to be bought, sold, or consolidated or they wish to terminate service or support, they can move to a new vendor that will continue to enhance, support and maintain the product. The library remains in control of the decision of when to upgrade or migrate.
Support options. In the early days of OSS, you either had to be a programmer or have one on your staff to use OSS. Many libraries didn't meet that requirement and left the OSS option aside. However, commercial entities have since been created to provide commercial support options at a reasonable cost. These companies handle data conversion, installation, training, support, maintenance, ongoing development, customization and all the other services you've come to expect with proprietary software. If libraries don't like their current support or costs, they can move to another OSS vendor. For libraries stuck with proprietary vendors that are more focused on profit than customer satisfaction, this is proving to be a refreshing change.
Development options. Libraries have grown frustrated with slow and costly developments from some proprietary vendors. Often, what gets delivered is not what was requested or needed. Most companies build walls between users and their programming teams, and only the most savvy of analysts can describe exactly what a library wants to a programmer in a way that ensures delivery of the right software. In addition, many developments get caught behind new contracts or return on investment (ROI) calculations that make the company move slowly. Open source models alleviate these frustrations. Furthermore, if the library doesn't like the quote or timeline from their vendor, they can hire or outsource their own programmer. They also have direct access to the programmer through email or instant messaging. The end result is that libraries get what they want, much closer to when they want it. Features can be implemented in days and weeks instead of years and decades. And, once any library has exactly the open system it wants, it can share that system with other libraries around the world.
More efficient use of financial resources. Moving to open source doesn't mean that everything is free. You remove one huge cost in licensing and create a competitive market surrounding other costs. The financial model changes, in favor of the library.
What are the Concerns about OSS?
We've identified numerous reasons why open source is under consideration at many libraries today. However, there is no perfect solution and everything has pluses and minuses. If you announce you're moving towards open source, you'll hear many arguments such as those which follow.
"Is there legal protection from lawsuits if you use OSS?" Clearly this is a complicated topic and even a library that uses proprietary software is not totally protected. Software developers are always exposed in that they trust the contributors to not copy or steal product code. In the OSS world, as in the proprietary world, if a violation happens, you'll need to have new code written and substituted that avoids the legal claim. The good news with OSS is that you have more helping hands than you might have inside of a proprietary company facing this claim.
"How do we know the software won't branch?" Branching usually happens when the community grows so large that the code can't accommodate everyone's needs. However, the use of an open service oriented architecture means code components can more readily be re-used and/or interfaced with other software, thus allowing customized implementations to be more readily achieved.
"OSS lacks maturity." New products often face this concern. But, just because the idea is new does not mean it is immature. Most vendors of proprietary products want you to forget that there are often more people at work on an OSS product than there are on their proprietary product(s). In the proprietary model, the development process tends to be tightly controlled and limited by the vendor. OSS vendors join forces with their customers in a community effort to develop the product. The result is faster development and a product where users get exactly what they want.
"Open source companies have no product road map." This is not true, as the road map followed by open source vendors doesn't belong to a company but to the users of the software. You have a major say in where an open source product goes, what roadmap is followed, when updates get applied to your systems, and what costs you decide to take on to use those updates and new features. OSS represents a true collaborative approach. Librarians are in control--not the company.
"What will it cost to add functionality to open source products?" Those who raise this question don't understand one of the major benefits of OSS. Open source development is more cost effective, allowing more functionality for the expenditure. Why? Because your library is not paying the vendor to maintain a research and development (R&D) environment. In the open source development model, every library that uses the software can (but doesn't have to) be an R&D environment. Because there are libraries that will join together to contribute code, the cost of adding functionality can be lower, and the results tend to be far more comprehensive and have higher quality when released.
"Is open source really open?" If you can get the source code, if it uses an open source license, and if you're free to modify it, support it yourself or purchase support from other companies, it is open.
"Is OSS really free?" What is "free" in OSS is freedom. Freedom from having the future of your automation product dictated or terminated by your vendor. Freedom to obtain service where you want at a price you want. Freedom from licensing and license upgrade charges.
"Is OSS viable over the long road and will support be available for the long-term?" This question can and should be asked of every software product, whether it is open source or proprietary. The answer does not depend on whether the software is proprietary or open source. It depends on a combination of the quality of the product and the stability of the company. If a proprietary software product has reached the end of its development road and/or the company is sold, current users may find themselves saddled with a product whose future is in doubt or even terminated. This scenario is less likely to happen with OSS, because from early on the software is understood, improved and supported by many parties, any one of which can extend their services to other libraries. OSS also provides several layers of insurance against product termination. With OSS: i) you have the source code for the product without going to court or pressing for a release of escrow; ii) you can obtain support from numerous sources including your own IT staff, commercial vendors, or hired consultants; and iii) the products are developed through community, not company product managers, meaning you'll see products that stay more current with technology trends and thus remain viable.
"Being open is more important than just open source." Being open is far more than just using OSS. It's about an approach to customer needs with regard to costs and to the future direction of products. When you're open, the community directs the future, not the company.
"Customers can have a co-existence strategy with open source." Those that advocate either pure proprietary or pure open source solutions are not being realistic. Both solutions will co-exist well into the future.
"There are a myriad of licenses." This is true, as each license meets a different need. When adopting OSS, the license should be examined for suitability for your library. Just because a product says it is open source, that does not mean you can do anything you want with it. Licenses impose obligations and because there are different types of open source licenses, there are different types of obligations to be observed and met. For instance, many open source licenses have no imposed fees as long as the library using it is a non-for-profit or educational library. However, if you're a for-profit business, fees could be involved. As with any software product, read the license and know what you're agreeing to before you start using the product.
What Can Go Wrong with Open Source?
In our work, we've seen the following major problem areas with OSS implementations. These are, in part, because people try to apply their experiences with proprietary software without understanding that open source is different.
- Support is important. One of the keys to a successful open source implementation is to understand that maintenance is needed and that your staff may or may not be able to do this by themselves. You can hire outside firms that specialize in supporting open source and the number of firms supporting library applications is growing. If, however, you wish to get support from the community of users that developed and support the software, you need to remember: i) that they do this as their time permits; and ii) to broaden the likelihood of prompt support, do not use a unique platform configuration.
- Not contributing back. Open source succeeds when users contribute back to the product. This can be through contributing code, contributing money, writing documentation, hiring service/support companies to support your use and have them contribute back your changes, and talking about the application and how you use it at conferences.
- Not doing full evaluations or suitability analyses. Since open source is easily downloaded and used, it is possible to select the easiest application to load and start using it. This action skips the critically important analysis to ensure the functionality will meet user needs and that the product will scale to meet future needs. Do not skip doing a full total cost of ownership analysis on an application before you begin implementing it.
- Not staffing properly to support the application. We frequently see libraries add more applications to their information technology department's list of things to do, without providing the staff and resources to properly support the applications. This is short sighted and will ultimately lead everyone involved to think open source is not suitable, when in fact it is, if properly planned, supported and implemented.
We started this article with the question "is open source right for your library?" We've examined a wide variety of reasons why many libraries have and are moving in the direction of OSS. Those reasons focus on stretching budgets, regaining control and aligning end user needs and development agendas. As shown, there are many valid reasons for considering OSS.
We investigated some of the concerns you'll face should you decide to move your library in this direction. OSS isn't a perfect solution, but answers have been offered for the concerns. Finally, we've listed a few of the common mistakes we've seen libraries make in using OSS. Ultimately, as with any choice, you'll have to match your library's needs with the features and benefits to see if open source is right for your library.
Parts of this article were first presented at the ILS Symposium by Lincoln Trail Libraries System in September 2007 and other portions are from the author's blog.