Free Software in Libraries, success stories and their impact on the library today

Today I was privileged to present to the 6th International Congress of Technological Innovation, Innovatics 2016, organized by Duoc UC Libraries, Library of Santiago, and University of Chile Libraries. The conference was simultaneously translated in English and Spanish. To aid the translators, I wrote out the text of my presentation for them to review. Below is the text as it was intended to be presented; I did diverge in a few places mostly based on what others said earlier in the conference.

Evolution of Open Source in Libraries

Thank you for the opportunity to talk with you today. My name is Peter Murray, and I’ve been involved in open source projects in libraries for at least 20 years. After receiving my undergraduate degree in computer science, I went to work for my university library as they were bringing up their first library automation system. This was early in the days of information retrieval on the internet, and I adapted the Gopher program to offer a front end to the library’s resources. Gopher came from the University of Minnesota in the United States, and they released their code on the internet for free. There wasn’t a notion of organized open source at the time – it was just free software that anyone could download and adapt. There wasn’t a sense of community around the software, and the tools to share changes with each other were very rudimentary. Stretching back to the 1950s and 1960s, this was the era of “free software”.

During the mid-1990s I worked for Case Western Reserve University in Cleveland, Ohio. I was part of a team that saw the early possibilities of the World Wide Web and aggressively pursued them. We worked to reorganize the library services onto the web and to try to add personalization to the library’s website using a new programming language called Personal Home Page. We know it today as PHP. It was also at this time that the phrase “open source” was coined. “Open source” meant more than just the having the source code available. It also a recognition that organizations had a business case for structuring a community around the source code. In this case, it was release of the Netscape browser code that was the spark that ignited the use of the “open source” phrase.

In the early 2000s I worked for the University of Connecticut. During this time, we saw the formation of open source projects in libraries. Two projects that are still successful today are the DSpace and the Fedora repository projects. These two projects started with grants from foundations to create software that allowed academic libraries to efficiently and durably store the growing amount of digital files being produced by scholars. Both projects followed paths where the software was created for the needs of their parent organizations. It was seen as valuable by other organizations, and new developers were added as contributors to the project.

Also in the early 2000s the Koha integrated library system started to build its community. The core code was written by a small team of developers for a public library in New Zealand in the last few months of 1999 to solve a year-2000 issue with their existing integrated library system. Within a year, Koha publicly released its code, created a community of users on SourceForge – a website popular in the 2000s for hosting code, mailing lists, documentation, and bug reports. The tools for managing the activity of open source communities were just starting to be formed. There is a direct line between SourceForge – the most popular open source community of its time – and GitHub – arguably the most important source code hosting community today.

In the late 2000s I was working for a consortium of academic libraries in Ohio called OhioLINK. In this part of my career, I was with an organization that began actively using library open source software to deliver services to our users. Up until this point, I had – like many organizations – made use of open source tools – the HTTPd web server from Apache, MySQL as a database, PHP and Perl as programming languages, and so forth. Now we saw library-specific open source make headway into front-line library services. And now that our libraries were relying on this software for services to our patrons, we began looking for supporting organizations. DSpace and Fedora each created foundations to hold the source code intellectual property and hire staff to help guide the software. The DSpace and Fedora foundations then merged to become DuraSpace. Foundations are important because the become a focal point of governance around the software and a place where money could be sent to ensure the ongoing health of the open source project.

In the early 2010s I went to work for a larger library consortium called LYRASIS. LYRASIS has about 1,400 member libraries across much of the United States. I went to work at LYRASIS on a project funded by the Andrew W. Mellon Foundation on helping libraries make decisions about using open source software. The most visible part of the project was the FOSS4LIB.org website. It hosts decision support tools, case studies, and a repository of library-oriented open source software. We proposed the project to the Mellon Foundation because LYRASIS member libraries were asking questions about how they could make use of open source software themselves. Throughout the 2000s it was the libraries with developers that were creating and contributing to open source projects. Libraries without developers were using open source through service provider companies, and now they wanted to know more about what it meant to get involved in open source communities. FOSS4LIB.org was one place where library professionals could learn about open source.

The early 2010s also saw growth in service providers for open source software in libraries. The best example of that is this list of service providers for the Koha integrated library system. As we let this scroll through the continents, I hope this gives you a sense that large, well-supported, multinational projects are alive and well in the library field. Koha is the most impressive example of a large service provider community. Other communities, such as DSpace, also have worldwide support for the software. What is not represented here is the number of library consortia that have started supporting open source software for their members. Where it makes sense for libraries to pool their resources to support a shared installation of an open source system, those libraries can reap the benefits of open source.

Now here in the mid-2010s I’m working for a small, privately-held software development company called Index Data. Index Data got its start 20 years ago when its two founders left the National Library of Denmark to create software tools that they saw libraries needed. Index Data’s open source Z39.50 toolkit is widely used in commercial and open source library systems, as is its MasterKey metasearch framework. The project I’m working on now is called FOLIO, an acronym for the English phrase “Future of Libraries is Open”. I’ll be talking more about FOLIO this afternoon, but by way of introduction I want to say now that the FOLIO project is a community of library professionals and an open source project that is rethinking the role of the integrated library system in library services.

Revisit the Theme

With that brief review of the evolution of open source software in libraries, let’s return to the topic of this talk – Free Software in Libraries: Success Stories and Their Impact on Today’s Libraries. As you might have guessed, open source software can have a significant impact on how services are delivered to our patrons. In fact, open source software – in its best form – is significantly different from buying software from a supplier. On the one hand, when you buy software from a supplier you are at the mercy of that supplier for implementing new features and for fixing bugs in the software. You also have an organization that you can hold accountable. On the other hand, open source software is as much about the community surrounding the software as it is the code itself. And to be a part of the community means that you have rights and responsibilities. I’d like to start first with rights.

Rights

The rights that come along with open source are, I think, somewhat well understood. These are encoded in the open source licenses that projects adopt. You have the right to view, adapt, and redistribute the source code. You can use the software for any purpose you desire, even for purposes not originally intended by the author. And the one that comes most to mind, you have the right to run the software without making payment to someone else. Let’s look at these rights.

Use

In the open source license, the creator of the software is giving you permission to use the software without needing to contact the author. This right cannot be revoked, so you have the assurance that the creator cannot suddenly interrupt your use, even if you decide to use the software for something the creator didn’t intend. This also means that you can bring together software from different sources and create a system that meets the needs of your users.

Copy

You have the right to make a copy of the software. You can copy the software for your own use or to give to a friend or colleague. You can create backup copies and run the software in as many places as you need. Most importantly, you have this right without having to pay a royalty or fee to the creator. One example of this is the Fenway Libraries Online in the Boston Massachusetts area. Ten libraries within the Fenway consortium needed a system to manage their electronic resource licenses and entitlements. After an exhaustive search for a system that met their requirements, they selected the CORAL project originally built at the University of Notre Dame. There is a case study on Fenway’s adoption of CORAL on the FOSS4LIB.org website.

Inspect

A key aspect of open source is the openness of the code itself. You can look at the source code and figure out how it works. This is especially crucial if you want to move away from the system to something else; you can figure out, for instance, how the data is stored in a database and write programs that will translate that data from one system to another. Have you ever needed to migrate from one system to another? Even if you didn’t have to do the data migration yourself, can you see where it would be helpful to have a view of the data structures?

Modify

Hand-in-hand with the right to inspect open source code is the right to modify it to suit your needs. In almost all cases, the modifications to the code use the same open source license as the original work. What is interesting about modifications, though, is that sometimes the open source license may specify conditions for sharing modifications.

Fork

Ultimately, if the open source project you are using is moving in a different direction, you have the right to take the source code and start in your own direction. Much like a fork in the road, users of the open source project decide which branch of the fork to take. Forks can sometimes remain relatively close together, which makes it somewhat easy to move back and forth between them. Over time, though, forks usually diverge and go separate ways, or one will turn out not to be the one chosen by many, and it will die off. With this right to fork the code, it is ultimately the community that decides the best direction for the software. There was an example a few years ago within the Koha community where one service provider wanted to control the process of creating and releasing the Koha software in ways that a broader cross-section of the community didn’t appreciate. That segment of the community took the code and re-formed new community structures around it.

Responsibilities

These rights – Use, Copy, Inspect, Modify, and Fork – form the basis of the open source license statement that is a part of the package. Some form of each of these rights are spelled out in the statement. What is left unsaid is the responsibilities of users of the open source software. These responsibilities are not specified in the open source license that accompanies the software, but they do form the core values of the community that grows around the development and enhancing of the project. Each community is different, just like each software package has its own features and quirks, but they generally have some or all of the following characteristics. And depending on each adopter's needs and capacity, there will be varying levels of commitments each organization can make to these responsibilities. As you work with open source code, I encourage you to keep these responsibilities in mind.

Participate

The first responsibility is to participate in the community. This can be as simple to joining web forums or mailing lists to get plugged into what the community is doing and how it goes about doing it. By joining and lurking for a while, you can get familiar with the community norms and find out what roles others are playing. The larger automation companies in libraries typically have users groups, and joining the community of an open source group is usually no different than that of a proprietary company. One of the key aspects of open source projects is how welcoming it is to new participants. The Evergreen community has what I think is a great web page for encouraging libraries to try out the software, read the documentation, and get involved in the community.

Report Bugs

Library software has bugs – the systems we use are just too complicated to account for every possible variation as the software is developed and tested. If you find something that doesn't work, report it! Find the bug reporting process and create a good, comprehensive description of your problem. Chances are you are not the only one seeing the problem, and your report can help others triangulate the issue. This is an area where open source is, I think, distinctly different from proprietary software. With proprietary systems, the list of bugs is hidden from the customers. You may not know if you are the only one seeing a problem or if the issue is in common with many other libraries. In open source projects, the bug list is open, and you can see if you are one among many people seeing the issue. In most open source projects, bug reports also include a running description of how the issue is being addressed – so you can see when to anticipate a fix coming in the software. As an aside for open source projects in the audience: make it easy for new community members to find and use your bug reporting process. This is typically a low barrier of entry into the community, and a positive experience in reporting a bug and getting an answer will encourage that new community member to stick around and help more. We'll talk about triaging bug reports in a minute.

Financially Support

Thinking back to our open source software rights, we know we can use the software without paying a license fee. That doesn't mean, though, that open source is free to write and maintain. Some of the most grown up software projects are backed by foundations or community homes, and these organizations hire developers and outreach staff, fund user group meetings, and do other things that grow the software and the community surrounding it. If your organization's operations are relying on a piece of open source, use some of your budget savings from paying for a vendor's proprietary system to contribute to the organization that is supporting the software. DuraSpace is a success story here. Since its founding, it has attracted memberships from libraries all around the world. Libraries don’t have to pay to use the DSpace or Fedora software. Those that do pay recognize that their membership dues are going to fund community and technical managers as well as server infrastructure that everyone counts on to keep the projects running smoothly.

Help

As staff become more familiar with the open source system, they can share that expertise with others around them. This is not only personally rewarding, but it also improves the reputation of your organization. A healthy and growing open source community will have new adopters coming in all the time, and your experience can help someone else get started too. EIFL, an acronym for the English “Electronic Information for Libraries”, is a not-for-profit organization that works to enable access to knowledge in 47 countries in Africa, Asia, and Europe. One of their programs is to help libraries in developing countries adopt and use open source software for their own institutions. They gather groups of new users and match them with experienced users so they can all learn about a new open source software package at about the same pace. Through this mentoring program, these libraries now have capabilities that they previously didn’t have or couldn’t afford.

Triage

A few slides earlier, I encouraged new adopters to report bugs. That can quickly overwhelm a bug tracking system with issues that are not really issues, issues that have been solved and the code is waiting for the next release, issues where there is a workaround in a frequently asked questions document, and issues that are real bugs where more detail is needed for the developers to solve the problem. As a community member triaging bugs, you look for new reports that match your experience and where you can add more detail or point the submitter to a known solution or workaround. Sometimes this points to a need for better documentation (discussed in the next slide); other times it needs a fix or an enhancement to the software, and the report moves on to the development group. Another note for projects: provide a clear way for reported issues to move through the system. This can be as informal as a shared understanding in the community, or as formal as a state diagram published as part of the project's documentation that describes how an issue is tagged and moved through various queues until it reaches some resolution.

Documentation

Open source software is often criticized -- rightly so -- for poor documentation. It is often the last thing created as part of the development process, and is sometimes created by developers who feel more comfortable using a writing voice full of jargon rather than a voice that is clear, concise, and targeted to end-users. Contributing to documentation is a perfect place for expert users but inexperienced coders to make the deepest impact on a project. You don't need to understand how the code was written, you just need to describe clearly how the software is used. Documentation can come in the form of user manuals, frequently-asked-questions lists, and requests to the developers to add help language or change the display of feature to make its use clearer.

Translate

Translation is also something that an experienced user can do to support a project. One sign of a mature open source project is that the developers have taken the time to extract the strings of field labels, help text, and user messages into a language file so that these strings can be translated into another language. Translating doesn't mean being able to write code; it just means being able to take these strings and convert them into another language. If you find an open source package that has all of the functionality you need but the native language of the system is not the native language of your users, providing translations can be a great way to make the software more useful to you while also opening up a whole new group of organizations that can use the project as well.

Test

This is getting a little more complicated, but if you are running the software locally and can set up a test environment, as release candidates for new software come from the developers, try them out. Run a copy of your data and your workflows through the release candidate to make sure that nothing breaks and new features work as advertised. Some projects will create downloadable "virtual machines" or put the release candidate version of the software on a sandbox for everyone to test, and that lowers the barrier for testing to just about anyone.

Request

How feature requests are made are another distinguishing characteristic between open source and proprietary systems. All proprietary systems have some way of registering feature requests and various processes for working through them. In an open source community, there is a lot more transparency about what is being worked on. All of the bug reports and feature requests are listed for everyone to see and comment on. There might even be a formal voting mechanism that guides developers on what to work on next. Volunteer developers from different organizations with similar needs can more easily find each other and tackle a problem together. Developers hired by the software's foundation or community home have a better understanding of what activity will have the biggest impact for the users. This all starts, though, with you making your requests and commenting on the requests of others.

Challenge

Healthy projects need forward tension to keep moving, and one way to do that is with eyes-wide-open constructive criticism. It is easy and common for communities to get bogged down in doing things the same way when it might make sense to try a different technique or adopt a different tool. It is also, unfortunately, common for communities to become insular and to become unwelcoming to new people or people unlike themselves. Open source works best when a wide variety of people are all driving towards the same goal. Be aware, though that the good will within communities can be destroyed by unkind and insulting behavior. Just as meetings have adopted codes of conduct, I think it is appropriate for project communities to develop codes of conduct and to have action and enforcement mechanisms in place to step in when needed. This can be tough -- in the cultural heritage field, participants in open source are typically volunteers, and it can be difficult to confront or offend a popular or prolific volunteer. The long-term health of the community requires it, though.

Code

Only at the very last do we get to coding. The software can't exist without developers, but it is too easy to put the developers first and forget the other pillars that the community relies on -- bug reporters and triage volunteers, documentation writers and translators, software testers and community helpers. If you are a developer, try fixing a bug. Pick something that is small but annoying -- something that scratches your own itch but that the more mainstream developers don't have time to tackle. A heads-up to open source project leaders: create a mentorship pathway for new developers to join the project, and provide a mechanism to list "easy" bugs that would be useful for developers new to a project to work on.

Public Libraries

Throughout the presentation I’ve mentioned academic libraries and library organizations that are making use of open source now. Open source adoption is not limited to academic libraries, though, and I wanted to mention the work of the Meadville Public Library in rural Pennsylvania of the United States. There is a case study on the FOSS4LIB.org website where they describe their library and how they came to choose the Koha integrated library system. The Meadville Public Library has a small staff and an even smaller technology budget. When they decided to migrate to a new system in the mid-2000s, they realized they had a choice to pay the commercial software licensing fees to a traditional library vendor or to put that money towards building skills in the staff to host a system locally. The case study describes their decision-making process, including site visits, fiscal analysis, and even joining a “hackfest” developer event in France to help build new functionality that their installation would need. I invite you to read through the case study to learn about their path to open source software. This library uses open source almost exclusively throughout their systems – from their desktop computers and word processing software to their servers.

Conclusion

Making use of open source software is more often about the journey than the destination. In the end, our libraries need systems that enable patrons to find the information they are seeking and to solve the problems that they face. If nothing else, open source software in libraries is a different path for meeting those needs. Open source software, though, can be more. It can be about engaging the library and its staff in the process of designing, building, and maintaining those systems. It can be about the peer-to-peer exchange of ideas with colleagues from other institutions and from service providers on ways to address our patrons’ needs. And sometimes open source software can be about reducing the total cost of ownership as compared with solutions from proprietary software providers. Libraries across the world have successfully adopted open source software. There have been a few unsuccessful projects as well. From each of these successful and unsuccessful projects, we learn a little more about the process and grow a little more as a profession. I encourage you if you haven’t done so already, to learn about how open source software can help in reaching your library’s goals.

Thank you for your attention, and I am happy to take questions, observations, or to hear about your stories of using open source software.