Introduction

Staffordshire University changed its library management system (LMS) in 2011 from SirsiDynix Horizon to Koha. This has been both a technical and cultural change for the Library. The University decided to opt to move from on-site hosting to off-site with support provided by a vendor, PTFS-Europe. Koha is also an open source (OS) LMS, unlike Horizon, which means that both technical and feature developments, as well as quality assurance, are driven by the Koha OS community, then implemented by PTFS. Koha has a web interface and is less modular than some proprietary LMSs with more integration between acquisitions, cataloguing and circulation workflows.1 The following provides an overview of the integrated support model that has evolved during Koha’s six-year tenure at Staffordshire, which is comprised of the Library, the University’s IT department, PTFS and the Koha community.

Open source trend and the development of Koha

It has been argued2, 3, 4 that the trend towards the adoption of OS LMSs would be slow because libraries cannot afford the specialist support that open source software (OSS) requires and, with no commercial incentive to move away from proprietary software, the market would remain niche. However, with the changes that have occurred within higher education (HE) over the last ten years – the raising of tuition fees, the lifting of the cap on recruitment and the reduction of governmental spending – many universities have had to reconsider the delivery and support of many of their large business systems as they face challenging economic times. Over the last five years we have seen the OSS market gradually moving from the predicted niche market to its integration within universities’ technical service infrastructure. From repositories such as EPrints to OSS web content platforms like WordPress and Drupal, OSS solutions are increasingly seen as a viable alternative to proprietary systems, especially if systems are vendor supported and hosted off campus. For example, at Staffordshire University, as well as Koha, it has WordPress and the EPrints repository as part of its OS systems profile.

According to Breeding, the cost and innovative development of OS products, together with matured functionality that is comparable to proprietary products, has seen its continued integration into mainstream service delivery.5 In 2017 EBSCO launched FOLIO (the Future of Libraries Is Open), an OS modular library services platform where customers can choose individual ‘specialized’ apps or all apps to form a ‘cohesive platform’. Breeding claims that this approach opens up the development of library services to a wider community, providing opportunities for the implementation of bespoke services flexible enough to meet an organization’s needs, which characterizes the OS production model. Breeding argues that this is a bold move for EBSCO, contributing ‘energy and resources to a product it does not own, influencing but not controlling’. The OS business model, Breeding states, is based on fees for services not software, as evidenced by the companies that provide these products, like PYFS, Koha’s service provider.6

To a certain extent, the development of Koha was economically driven. Koha was developed in 2000 within the public library sector in New Zealand by the Horowhenua Library Trust, which was dissatisfied with the LMS options available because they were either expensive or did not meet their needs. The Trust also wanted a web-based system, and worked with Katipo Communications to develop the LMS. It was recommended that the software be released under a GNU General Public License, a free software licence which permits users to run, share and modify the software to ensure sustainability and to encourage other organizations to adopt it.7 The outcome was Koha, a web-based system with an SQL (structured query language) database back-end. (The name Koha comes from the Maori term for gift or donation.) Cataloguing data are stored in MARC records and accessibly via Z39.50 or search-retrievable URL. It has a configurable interface and includes all the expected features of an LMS: acquisitions, cataloguing, patron management, serials management and reporting.8 Koha is now used worldwide in all library sectors including public libraries which have chosen Koha as a solution in response to financial constraints from local austerity measures.

Koha community

An active community of developers, vendors and librarians now support Koha.9 The involvement of vendors has enabled ambitions for OS to become a reality for the library, taking the OS LMS out of the exclusive LMS market into the mainstream. Staffordshire University’s vendor PTFS became involved in the delivery of Koha in 2010 after acquiring LibLime, one of the earliest vendors. PTFS were founded in 2007 to implement and support Koha and Evergreen OS LMSs. As well as hosting, PTFS provides implementation services, including installation, configuration, data conversion, software development and training and support.10 PTFS customers are international, representative of public, HE and specialist libraries. Staffordshire was one of the first universities to adopt Koha for the management of its entire library collections, where other organizations have chosen to implement in departments. HE customers remain in the minority, but Staffordshire is in good company with the University of Hertfordshire, the University of the Arts London and, more recently, Loughborough University implementing Koha.

Development of Koha support framework at Staffordshire

It should be acknowledged that moving to a supported OS integrated LMS from a modular on-site hosted proprietary system, as experienced at Staffordshire, requires both a cultural and technological shift. The move can be challenging and disruptive for those who are happy with existing workflows, some of which may not easily map to a new system. Furthermore, with an off-site hosted solution, the vendor becomes an integrated part of the support framework, contributing to some of the activities that a systems librarian would traditionally provide.

Before Staffordshire University decided to move to Koha in 2011, change had already begun with respect to how the LMS was being supported. There had been the reorganization and streamlining of cataloguing and acquisitions functions in response to changes in the information discovery landscape. The Library had moved to ordering shelf-ready books, shortening Dewey class numbers to enable easier location for users, and downloading records from the British Library. Day-to-day acquisition, cataloguing and patron administration activities were now being carried out by library assistants, based in the Customer Services and Resources Management team. In 2011 the Library was part of Information Services, and the management of the life cycle, discovery and circulation of items was represented by an integrative cross-team approach. The Information Services’ Resources Manager managed the IT licences and the team that was responsible for purchasing, managing acquisitions and cataloguing. The Library’s Site Operations Manager managed patron administration and circulation. Staffordshire had already changed the job role title of Systems Librarian to Information Landscape Librarian as it was thought that this more adequately described the varied responsibilities of this role which had gone beyond the support of the LMS to supporting e-resource discovery, access and authentication, as well as managing open access publishing.

Payne11 has argued that an organization does not need technical knowledge of OS as the host will deal with any technical issues. Poulter,12 citing Morgan,13 has also claimed that librarians are not programmers and there is no reason why they should develop skills in this area. However, the role of the Information Landscape Librarian should not be underestimated in the LMS configuration and translating of Staffordshire’s workflow needs to PTFS during the implementation of Koha. Like a systems librarian, the Information Landscape Librarian also had to develop an expert knowledge of all the modules within Koha and disseminate this knowledge to colleagues across the team as part of the implementation. However, it can be argued that the cross-service shared responsibility for the LMS, which had already been established previous to implementation of Koha, aligned well with Koha’s set-up and enabled a smoother implementation and integration into the library service.

OS systems can also facilitate a move away from a siloed approach to the day-to-day support that proprietary systems can enforce. This movement from a siloed approach to support had already begun to develop pre-Koha, and after its implementation, Staffordshire extended its collaborative model by taking advantage of the expertise available from within the Information Services IT team, PTFS and the OS community. Initially, the core technical support was shared between PTFS and the Information Landscape Librarian. The Information Landscape Librarian played a central role in troubleshooting and articulating technical issues to PTFS, as well as creating and writing reports. Eventually, Staffordshire’s IT Business Applications team became part of the support framework, overseeing upgrades and reporting issues to PTFS out of hours. This was after persuading the University to raise the profile of the LMS so that it had parity of importance with other business-critical systems, such as the student information system, virtual learning environment and financial and human resources systems. Encouraging this change was quite a challenge but was achieved by articulating how the availability of LMS impacts on the student experience, particularly with respect to accessing services 24/7.

Some of Staffordshire’s experiences similarly align with SOAS University of London (SOAS)’s implementation of its OS LMS, Kuali OLE. Barron states this implementation required a collaborative approach with IT and Information Services pool their technical and library skills. SOAS had found that their previous system, Millennium, was driving their processes and procedures and it was becoming challenging to make changes according to their University’s needs. As observed at Staffordshire, Barron states that an open source system requires the involvement of end users in its development, so that their requirements can be met; it is ‘the shape of things to come’. The change was a challenge for some staff at SOAS, who found it difficult to adjust to a new approach to working. However, as evidenced at Staffordshire, user engagement was an important aspect of SOAS’s implementation.14

Relationship with the open source vendor

The institutional relationship with the OS vendor is a significant aspect of support for an OS LMS. Singh’s research on OS LMSs found that many librarians were happy with the support that they received from their vendor.15 However, the relationship with an OS vendor was found to be slightly different from that with a proprietary vendor. This is possibly because the implementing organizations are smaller and there is an inherent collaborative approach to providing support for OS solutions which relies on the OS community. It could be argued that the challenge is in maintaining the close relationship with the vendor once the LMS has been implemented. For example, post implementation at Staffordshire, it took some time to agree the communication protocol that suited the University and PTFS. Eventually it was decided that Staffordshire and PTFS would have monthly conference calls to track the outstanding issues post implementation, to investigate feature requests and prepare for upgrades. At first, these conference calls were attended by the Information Landscape Librarian, the Site Librarian and the Resources Manager. However, after Staffordshire established the criticality of the LMS, a representative from the IT’s Business Applications team was included within the meeting. Google Docs was used to record meeting actions, and PTFS provided the software for the conference calls, thus allowing desktop sharing if required. In addition to this, expectations were placed upon PTFS with respect to keeping Staffordshire up to date with issue resolutions and solutions for unforeseen problems, an area of importance identified in Singh’s research.16 Meetings became less frequent as Koha stabilized, issues were resolved, and the PTFS-Europe user community developed.

Evolving day-to-day support for Koha – a collaborative approach

At the end of 2016 the Library and Information Technology Services split at Staffordshire, with IT Services becoming Digital Services. The job title of Information Landscape Librarian also changed, to Research and Digital Resources Librarian, at the same time. However, despite the restructure, the collaborative approach that had been co-ordinated by the Information Landscape Librarian continued, with Digital Services still managing upgrades, network issues and out-of-hours support. The ongoing day-to-day technical support is provided by PTFS and calls are tracked and logged using GitHub, a reporting repository used by the OS community. As with other proprietary systems, there are still resource implications with respect to knowledge and ongoing support within the organization.17 This not only includes administrative support at Staffordshire, where the configuration and reporting is provided now by the newly titled Research and Digital Resources Librarian, but additional support from Customer Services with circulation and patron management. Support for Koha now sits within both the Library and Digital Services’ service levels, especially now the University has acknowledged that Koha is a business-critical system. The Library has also written scripts which have increased the number of ‘first fixes’ provided by the Digital Services helpdesk. An important aspect of the support framework is the Koha OS community, which collaboratively creates documentation, quality assures solutions for feature requests, and comes up with solutions for technical issues. Staffordshire support also interacts with the OS community to identify solutions to technical issues and feature enhancements. This collaborative community user-driven approach, Dimant18 argues, is one of the advantages of an OS LMS.

So, are there any disadvantages to adopting an OS LMS? According to Singh19 (referring to Cervone),20 one of the main disadvantages of an OS LMS is poor usability. Specifically, this refers to less user-friendly interfaces, lack of functionality and issues around security and general reliability. This is possibly why some institutions will not take the leap. Staffordshire has received very few criticisms from patron users about the interface. Most of the criticisms have related to the relevancy on the search results, which PTFS has continued to work on with the University, and some technical issues in the cataloguing module relating to authority files. Upgrade release notes can be complex, so some time and resources must be allocated to translate the implications for processes and workflows to colleagues, and to understand the impact on the system. However, the positive aspect of this activity is that those supporting and using the LMS develop a good knowledge of the upgrade features. PTFS do also provide extensive support documentation which can be used for training and creating bespoke support materials. Generally, after the outstanding technical issues were addressed post implementation, Koha has been an extremely stable system, and changes such as setting up new suppliers are relatively straightforward. One criticism would be that sometimes it is difficult obtaining the causal details of technical issues, but this can also be a challenge with proprietary systems.

Lessons learned

With the implementation of any new system, it is important to involve all end users of the system, regardless of level of activity. This will require those that are leading the project to be candid with respect to those processes which can be mapped and those that will need to be changed. This can be a challenge as some colleagues will adapt to change better than others. Explaining the concept of OS, and how OS systems are supported differently from proprietary systems, can assist with this. Library colleagues, and to some extent IT colleagues, may be unfamiliar with a collaborative support framework for supporting a business system that is inclusive of the vendor and a development community, and some time may need to be given to culturally adapt. Post implementation, efficiencies in support and triaging via the helpdesk service can be enabled by clearly identifying roles and responsibilities, particularly with respect to escalating technical issues. OS systems because of their support models, and to a certain extent their cost in comparison to proprietary systems, can push their support further down the list of University system priorities, so establishing the LMS as a business-critical system helps to raise both its profile and importance, especially within IT teams providing out-of-hours support. The implementation of an OS system can change the role of the traditional systems librarian or, in the case of Staffordshire, the Information Landscape Librarian (now the Research and Digital Resources Librarian), especially with respect to administrative and technical support if the LMS is hosted off site, as these activities will be shared with the vendor. However, Staffordshire still has to develop and run its own reports, make changes to the interface, troubleshoot and articulate upgrades, and having a nominated person to oversee the management of these activities, who has overall knowledge of the LMS, provides the necessary reassuring coherence for end users.

Conclusion

For Staffordshire, the implementation of Koha has been a positive experience, although it should not be underestimated that the movement to an OS solution that is hosted off site comes with both process and cultural challenges. As with the implementation of any new system, not all the processes and functionality could be completely mapped to Koha and some adjustments needed to be made. This was initially challenging for some colleagues, but PTFS worked closely with Staffordshire to create necessary workarounds. This collaborative integrated approach between Staffordshire and PTFS, which has continued, has helped to develop the confidence of those supporting the system daily. However, there are some elements of the support framework post implementation which could be distinctive to an externally hosted OS LMS that organizationally require some cultural and systematic changes. For example, although it is important to have an individual with responsibility for the LMS administrative support, which some universities call a systems librarian, the technical and problem-solving support is shared with the vendor, in this case PTFS, and OS user community, and these become an integrated part of the support framework. New features must be quality assured by the OS community before implementation, and despite the OS community providing support documentation for the LMS and upgrades, unlike proprietary systems, this often requires some finessing by the organization delivering the system to make it usable for both colleagues and patrons accessing the system. It should, however, be noted that it is quite challenging finding research on the support for OS systems within universities, and to a certain extent there are limited evidence-based studies of the support of LMSs in general, as a considerable amount of research focuses on the implementation process. It is apparent that further research needs to be undertaken to evaluate the support structures for OS LMSs, even in the US where OS LMS solutions have more widely infiltrated the market.