The Case for OSS at CCFLS

tracker

Last updated September 27, 2014.

The IT department and library administration felt very strongly that it was important to use an OSS ILS. The traditional philosophy librarians have followed concerning the acquisition of ILS software was to purchase off-the-shelf software and fit it into our operations the best way we could. From the perspective of the 1980s, using a circulation system from a third-party closed-source vendor was a smart solution. Programming was difficult, computer hardware was very expensive, support for hardware in a rural city was next to impossible, and there really was only one very large computer to support and manage.

From today's perspective, using third-party closed-source vendors to provide libraries with ILS software is no longer the only solution. Software can be easily written in modern computer languages, and it can be run on inexpensive hardware that is easily supported by individuals who can be trained at local colleges, universities or tech schools. This means that libraries can have individuals on staff that can write or alter OSS to fit their unique needs.

Because of the flexibility of OSS platforms – tools such as LAMP (aka Linux/Apache/MySQL/Perl and/or PHP) form the building blocks for multiple useful services for libraries, like ILS, websites, public computers, web filtering and more – CCFLS has chosen to prioritize hiring capable staff that can integrate OSS tools into library use rather than expending funds on often expensive commercial solutions. Additionally, funds not spent on commercial software and licensing have instead been expended to purchase better hardware and hire staff capable of supporting OSS solutions.

We have three basic reasons why the CCFLS continues to invest in and use OSS:

  1. We didn’t want others to dictate when we must purchase new equipment. OSS hardware requirements are often much lower than those of proprietary software, meaning that hardware we purchase can have a much longer useful life and can often be repurposed for other projects. We also build our own hardware which is much more economical and usually allows us to buy more powerful hardware than we otherwise could afford. Finally, since a vendor isn’t dictating to us when our hardware must be upgraded, we are in control of the upgrade cycle, which makes planning and budgeting more accurate.
  2. We were tired of having to work around software. Proprietary ILS often requires altering policies to fit the program’s functionality. We wanted to be able to change the ILS to fit our policies. We also wanted to be able to develop new features and have full access to our data, something which was far less likely to be possible with a proprietary ILS. Additionally, with OSS you have access to the full version from the start, allowing you to test it with your own data without having to make a purchase.
  3. Using OSS gives us the option of not having to pay for software, licensing or support. Though the right to run OSS is cost-free, it is not necessarily cheap. Library staff still have to spend time and energy learning, configuring, documenting and testing the applications. We have found that over the total life of a project, OSS is considerably cheaper than proprietary solutions. OSS solutions help make our IT budget go further.

CCFLS realizes using OSS is considered risky in that the individuals who develop OSS solutions may leave their institution and take their knowledge with them, thus orphaning the project. Jonathan Rochkind's excellent article “A Primer in Risk” (Library Journal November 15, 2008) describes this issue in great detail. Since we have been doing OSS over many years CCFLS has developed an institutional knowledge that allows staff to leave while allowing the project to continue.

Overall, we have found that OSS works well, is reliable and is, when calculated over the total life of a project, a low-cost solution.