On Saturday 13th October I attended the ‘big’ Library Camp 2012 unconference (libcampuk12) at the Signing Tree Conference Centre, Birmingham.
Liz Jolly and I pitched a session on the use of Free and Open Source software in libraries, with a particular focus on discussing the cultural changes or cultural shift needed to develop and sustain the use of in libraries, a typically risk-averse environment. This idea came out of a #uklibchat discussion on Open Source software back in July – thanks to Adrienne Cooper for organizing that.
This session was prepared and facilitated jointly. However when I write “I”, “me”, etc. below I am talking about my own views and experience.
Introduction
In the session asked we use Open Source and Free Software as interchangeable terms that are close enough in meaning that Library Campers could use either term. I realize, and accept, there are objections to doing this. I will refer to FOSS meaning “free and open source software” below.
I explained that Open Source is a pragmatic model of software development where you are allowed access to the source code of the software, however it – and moreover the older concept of Free Software – are underpinned by a philosophy based around respecting users’ freedom and fostering community. Drawing on this we wanted to open with the “four freedoms” in the Free Software Definition (Free Software Foundation, 2012) and how they tie into our professional culture. This list is written by a computer scientist, so famously it starts from zero!
- The freedom to run the program, for any purpose (freedom 0).
- The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1).
- The freedom to redistribute copies so you can help your neighbour (freedom 2).
- The freedom to distribute copies of your modified versions to others (freedom 3).
We argued that in higher education and librarianship in particular, these freedoms are broadly aligned to our own professional culture. Universities have a culture of sharing both internally and externally, and also between those working in the same disciplines across institutions. Furthermore, both within and without higher education, librarianship is a particularly collaborative profession.
However, in the broader cultures of higher education we face various problems. In some ways the Four Freedoms are in opposition to the broader organizational culture we work in. We identify points of tension for universities and libraries as collaborative organizations working within power structures that do not necessarily agree with or support a collaborative approach. This is especially the case in our current political and financial climate, where increased competition between institutions will to an extent mitigate against a collaborative culture.
We wondered if perhaps this is mainly a problem within perceived “competitor” institutions, I asked if anyone finds themselves discussing things more openly with colleagues in sectors or institutions that you don’t consider a “threat” or competitor to your own?
FOSS and the culture of libraries and education
Culturally, one starting point is looking at where we still find institutional resistance to FOSS. By this I mean beyond myths like FOSS implying that you have to “build it yourself”, or that “you need to employ programmers”, rather I mean resistance to FOSS as a concept itself. I have seen some of this in my career in further and higher education, but I would say nowadays I think this attitude is dying off. Personally I find myself anticipating resistance to FOSS that simply doesn’t materialize – or in many cases I actually find enthusiastic approval for FOSS.
I am sure our experiences here vary widely – certainly buy-in from senior managers is essential and having one particularly pro- or anti-FOSS manager can make a huge difference either way. Several participants contributed here with examples from their own public sector experience where projects already in development had been scuppered when they were found to be using FOSS, and explained further that they did still spend time knocking down some very old-fashioned arguments about FOSS versus closed source such as needing to “have someone to sue when it all goes wrong”.
There was general agreement that certain sectors are worse at this than others, with libraries in local government and the NHS picked out as particularly difficult: public libraries having to accept whatever systems their authority decides on with limited or no change, and the NHS wanting to play especially safe.
One contradiction in higher education is we have a very long history of using FOSS for the services that underpin our systems (the concept of Free Software was born in higher education, when Richard Stallman was at MIT (Stallman, 2010) but a reluctance to actually use FOSS for campus-wide and departmental systems. What do we mean by this? At a basic level FOSS gives us the building blocks such as web and database servers, programming and scripting languages that we need to create software and services. Few of our IT and systems colleague would object to for example using a FOSS Web server or content management system – but notice how few FOSS library management systems are deployed in the UK, for example.
As a cultural aspect of this we would ask if library and education managers have enough in-depth knowledge of principles of technology, including FOSS, and how it can benefit their organisation to successfully govern projects and to engage with wider community? In universities there is an approach to promoting managers on academic excellence rather than strategic management ability, but these would be the people chairing project boards.
One example here is Moodle, a FOSS virtual learning environment – some argue that while the use of Moodle in higher education is growing, there is a relative lack of engagement with the community – possibly because of the aspect of knowledge culture in higher education of a fear of “exposure”, of not knowing? Oddly, we note that universities can prove not the best learning communities as we don’t like to admit when don’t know things! We also noted at a higher level a culture of “not invented here” exists in UK higher education (most obviously in nationally-funded projects) where we fail to learn from what others have done elsewhere. Or worse in some cases actively dismiss experience elsewhere because it is not our own idea.
How we buy software, and the “library mindset”
At this point I apologized to my fellow Library Campers for I was going to talk about… project management.
I argue the prevailing approach to software procurement and management in libraries works against FOSS. By this, I mean the approach to procurement or ‘invitation to tender’ that includes implicit assumptions that we are purchasing products from a software supplier or “vendor”. That said, we can actually specify and purchase FOSS in this way – what we are doing is buying the same support from a vendor but the product itself is FOSS. In the public sector, that support might require a tendering process over a certain threshold amount. Luke O’Sullivan pointed out here there is a procurement framework for purchasing FOSS systems available at the LibTechRFP wiki.
We noted that very few actually do this. A recent example is Staffordshire University where Dave Parkes and colleagues worked hard to research and justify choosing the Koha Open Source ILS, supported by PTFS Europe (Johnson, 2010). From a systems point of view it’s notable that Koha is quite a traditional LMS, and can go up against other similar systems using the full UK LMS Core Specification.
I would argue systems like the LMS and resource discovery are really about enterprise information, by this we mean they are among our key systems enabling learning and teaching, research, and other business activities in our universities. These systems are therefore business critical and should be viewed as such. However in universities this typically has never been the case. The LMS tends to be seen as a system that is “just there”, in the library – something that doesn’t need too much attention from IT or the broader university.
This ties in with an approach to user acceptance and testing that does not really exist in higher education, but should as the risks are that spreading around bad data between library and other systems in your university can cost you real money. We argued that librarians should look at software projects from a viewpoint of a “testing mentality”: what is it doing? What effect does it have on other parts of the system and on our other data? Librarians as information professionals should have a role to play here. This is not technical, but about information. More broadly Kate Lomax mentioned there’s a lot you can do to contribute without being a developer or a techie – for example documentation.
I argue these points about how we’ve viewed our previous systems and how we procure them has created something of a “library mindset” in our culture. I feel that as library workers we’ve been complicit in this, and worse in library systems and IT we often take the safe option which can limit our outlook and willingness to risk new things. This is even while we’re very happy using FOSS on own our own computers, or as some participants mentioned “sneaking in” FOSS programs behind the back of unwilling IT departments.
What changes everything in our view are FOSS products in library management systems, discovery, finance, student management, and virtual learning environments that are now becoming mature and mainstream.
Several mainstream examples are:
- Moodle in use at the University of London Bloomsbury colleges as a shared service.
- EPrints was mentioned in the session – this is widely used in higher education repositories with commercial support and consultancy services available (including from my own IT department, ULCC).
Conclusion
As a kind of coda we explained that issues around governance, testing methodology, documentation, change management and so on applies to so-called closed-source software just as much as it does to FOSS, and we’d say good project management and software development practice applies regardless of development model use.
As a FOSS developer, Luke emphasized the importance of governance, testing and providing a stable service alongside development. He explained that FOSS is incredibly exciting because you can work with the source code to make changes to suit your local needs – but you risk getting totally carried away. Culturally this represents a real change for library workers not used to this flexibility, so there’s a danger of too much demand on programming time if the assumption is anything about the system can be altered to meet local needs.
The strategic issues here for FOSS projects are around effective management in terms of inclusivity, collaboration and transparency, project governance frameworks, quality and risk management, procurement policies, and change management. These are not specific to an FOSS approach but we argue, essential for such an approach to be successful and specifically to address the traditional weaknesses found in FOSS projects.
Acknowledgement
My thanks to Sharon Penfold, Project Manager at the Bloomsbury LMS for helpful discussion on this subject around procurement, data, testing, and project management.
References
Free Software Foundation (2012) ‘What is Free Software?’ Available at: http://www.gnu.org/philosophy/free-sw.html
Johnson, P. (2010) ‘Staffordshire University chooses Koha for its new library system’. Available at: https://web.archive.org/web/20160320053630/http://blogs.staffs.ac.uk/informationlandscape/2010/12/10/staffordshire-university-chooses-koha-for-its-new-library-system/
Stallman, R.M. (2010) ‘The GNU project’. Available at: http://www.gnu.org/gnu/thegnuproject.html
Great to hear that this was inspired by a #uklibchat session…if anyone is interested in the discussion we had this is now available on our blog as a summary:
http://uklibchat.wordpress.com/2012/10/15/summary-24th-july-2012-open-source-and-open-license-content/
Thanks for posting this summary here, and of course for taking the time to write it up. I promise it wasn’t yet the site when I checked it before publishing this blog post.