Conclusion and Lessons Learned

tracker

Last updated September 27, 2014.

Any ILS project is complicated, so you may not want your first OSS project to be an ILS. Consider gaining experience with implementing other OSS solutions in your library first.

Installing OSS can be difficult, and there will be, in all likelihood, politics involved in the decision, especially with software as mission-critical to a library as an ILS. The best way to deal with the politics is to be truthful and not oversell the promises. However, having confidence in your team and the idea that any problem can and will be solved is a great sales pitch. Of course you have to back it up (see above).

Installing a new ILS and adding features via software development is even more complicated than an ILS project.

Frontline staff must realize that there will be problems and that they need a communication channel with management to express their concerns about problems with the software. A process should be in place for reporting problems, such as a bug tracking program like Mantis or Bugzilla, and everyone should be aware of the proper procedures to follow.

Upper management has to support an OSS ILS and understand that problems will occur that do not necessarily occur with a closed source solution. CCFLS believes that advantages of OSS far outweigh the negatives. The process of getting support for OSS can be very different than with proprietary software, particularly if you are supporting the software yourself rather than paying for commercial support. With a proprietary ILS, you typically contact technical support for assistance. There is also generally only one channel for getting support-- the company producing the software. If you are unhappy with the support you're receiving for that product, you don't have many alternatives. With OSS, there are a variety of ways to get support. Particularly with Koha, there is online documentation, mailing lists, IRC channels (where the developers commonly hang out), etc., in addition to commercial support from a number of vendors. If you’re unhappy with the support you’re receiving from one company, you are free to choose another. You also have the ability to view and/or modify the source code so that as long as you are capable of doing so, you can directly dig into your ILS to see what is going on.

Changing the code in an OSS ILS is not terribly difficult; just realize that if you change the program once, you will have to reintegrate your code every time you upgrade. So, upgrades will take longer and require a developer. Of course if you can get your changes incorporated into the main code base of the program or write them in such a way as to isolate them from the main code base (e.g. a plugin), you do not have to reintegrate your custom code every time there is an upgrade.

You need to budget time and money to support the OSS ILS community. When selecting an OSS ILS, you are not just picking software, but also becoming a member of a community. When considering an OSS ILS, you need to evaluate the community and understand how it works, meets, makes decisions and handles updates. As a member of a community, an OSS library has a responsibility to participate by volunteering and potentially contributing funds for documentation, future features and enhancements. Of course, you should consider sharing code you have developed internally and meeting with participating libraries and software developers. Though you do not have to pay for support directly, there are a number of indirect costs that need to be considered when selecting an OSS ILS, as noted above.