‘The battle of the library systems’
On 28 November Senate House closed early for the University of London Foundation Day, our annual celebration of our grant of royal charter on 28 November 1836. As the library closed down I made the short journey to Cilip HQ to attend the “Battle of the Library Systems” event organized by Bic.
This event was a panel debate between two sets of speakers in favour of Open Source software (OSS) and proprietary software. I was speaking in the Open Source “blue corner” alongside Dave Parkes of Staffordshire University and Nick Dimant of PTFS Europe. Sadly, Mark Hughes of Swansea University was ill and unable to attend and speak as planned. In solidarity the open team shared between us presenting Mark’s slides.
The house motion was:
Open source is about distributed innovation and will become the dominant way of producing software.
This is a quote from Talis – slightly modified from the original – from the Jisc and Sconul LMS study (Sero Consulting, 2008).
I will say a little about the arguments I made in favour of the house motion and what I thought were some strengths and weaknesses with the proprietary team’s arguments. Mick Fortune summed up as a guest speaker and I’d recommend reading his blog post ‘BIC Battles – Open Source or Proprietary?‘.
I opened by explaining our situation. Senate House Libraries and the colleges that make up the Bloomsbury Colleges group recently made a decision in principle to select Kuali Open Library Environment (Ole) as our next library management system. We have chosen an OSS system which will be run on a shared services model by the University of London.
Why is Open Source software a good fit for higher education?
I explained I prefer the older term Free Software to Open Source as it’s conceptually broader. Thinking in terms of one dimension – software development with access to the source code – sidelines the underpinning philosophy of community, sharing, and respecting software users’ freedom.
The audience was mainly academic libraries and I argued that our industry, higher education, has a culture of sharing and collaboration and librarianship is collaborative as profession. The same point was made by the proprietary software panel, but I go further and argue this therefore makes the software a good fit for us.
Kuali Ole is a library services platform being developed collaboratively by universities and their software development partners specifically to meet the needs of academic research-focused libraries. Ole is an enterprise-level system that we intend to use for business-critical services within our consortium. It will be cloud-hosted and managed collaboratively to provide a stable and trustworthy service – about as far as you can get from the idea of a keen systems librarian installing a Linux distribution on an old server and deciding to ‘give an Open Source LMS a whirl’.
I argued the key differences with Ole are that:
- It is a true library services platform rather than a traditional library management system
- As it is collaboratively-developed OSS we have the possibility of developing the software to meet our needs
It is the Free or Open Source licensing that is important here, as it effectively provides a strong position of sharing by default to the development model used in the foundation. Effectively, sharing and collaboration is baked in to the product and the processes used to develop it.
Proprietary software suppliers and Open Source software
Among the strongest arguments in favour of OSS for library systems is the range and variety of OSS used by proprietary suppliers themselves. Examples are most prevalent in next-generation discovery engines where Apache Solr and Lucene are used extensively, but in other library systems Postgres, Apache Tomcat, and of course the Apache http server are used widely.
I think proprietary supplies use OSS because it represents best-of-breed software that is stable and well-supported, and importantly flexible and free to use. It is licensed in a way that allows development and may be used for any purpose. This is why I emphasised freedom or liberty initially: while proprietary software suppliers enjoy the benefits of OSS themselves they’re not so keen on passing those freedoms onto us, libraries that buy their software and support services.
Suppliers’ use of OSS was acknowledged by the proprietary team. Jim Burton of Axiell mentioned extensive use of OSS throughout the company with an estimate of something like 500 different pieces used in their processes – though I expect this includes things like development tools and that the amount of OSS in their finished products is much less.
It is difficult for software suppliers selling systems based on Open Source to argue against Open Source. In using it in your own products you are vouching for it – and also undermining your arguments against it. For me this ubiquity in use and development is a compelling argument in favour of Open Source becoming the dominant way of producing software in the future.
Choosing software pragmatically
Jim made what I felt was the best argument against OSS for a complete library system directly relevant to my own experience in higher education. That was that the license is of secondary concern if the software does what you want and meets your needs. That software has an Open Source license doesn’t mean it’ll be a good fit for a given specification – relevant in a software ecosystem with relatively few complete OSS library systems as options.
I take from this that in practice our assessment process should lead us to choose pragmatically based on need rather than buying something because ‘it has a badge’. For many libraries that choice would mean proprietary software as best fit to a specification: perhaps an LMS with open and standards-compliant APIs allowing development work, perhaps cloud-hosted, perhaps with developer communities, perhaps itself built from OSS?
I argued as a software development method Open Source and open collaborative development methods make sense in our increasingly complex and networked world. I borrowed a term from David Weinberger here, that that nowadays knowledge has become “too big to know” (Weinberger, 2012) particularly evident in higher education with the complexity and sheer scale of research data.
It is a distributed and networked development approach that has created successful projects such as the Debian GNU/Linux distribution, and indeed the Linux kernel itself. One reason for the success of these projects is networked expertise: the ability to surface skills and knowledge from a globally-distributed community of developers. To apply this to library systems software I argued suppliers building systems based on a closed approach cannot respond to our changing needs as one based on networked expertise with ‘peaks’ of local knowledge that best understand our own situation and requirements can do.
The proprietary team emphasized software suppliers’ wish to listen to their customers. I don’t doubt their honesty in this at all. I think engaging customers and encouraging more open development such as developer communities very welcome. However, I argue any single vendor lacks the depth and breadth of knowledge that we have collectively in our own institutions and the scale that can be brought to bear by networked collaborative development. For this reason, the future is necessarily an open one.
Weinberger, D. (2012) Too big to know. New York, NY: Basic Books.
Sero Consulting Ltd (2008). JISC & SCONUL library management systems study. Available at: http://www.sconul.ac.uk/news/lms_report/lmsstudy/ (Accessed: 1 December 2012).
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.