Open Perspectives: VuFind

Open Perspectives: VuFind

In one form or another, I have been using and creating software for about thirty years. Needless to say, a lot has changed over the course of those decades, but one constant has been an appreciation for open source software. Like many in my generation, most of my early programming knowledge was gained by studying computer games and other programs published as source code listings in magazines and library books. As I gained experience, I enjoyed sharing my work when I could, and I was continually grateful for the valuable tools made freely available by others. Since 2009, a large part of my professional life has revolved around open source, as I have had the tremendous pleasure of joining an ever-evolving community of programmers from around the world to build and grow the VuFind project.

VuFind is an open source discovery layer, designed to act as a customizable user interface on top of a variety of searchable data sources. Whether you want to build your own Solr index from records that you control, or whether you wish to tap into an API like EBSCO Discovery Service and customize the look and feel, or whether you wish to mix and match results from multiple sources, VuFind gives you full control over your library’s search experience. It’s a perfect type of use case for open source: there are a lot of common needs and shared use cases, but there is also a strong desire for customization, configuration and responsiveness. The project tries hard to balance flexibility with predictability and to offer the best of both worlds.

Working in open source has strengthened my belief that the true purpose of software is to empower people to solve problems. By working together, we can find better solutions to our common challenges, and by sharing those solutions openly, we can help to combat, at least in a small way, some of the tremendous inequity in the world. While putting it this way sounds very idealistic, my appreciation of open source is also reinforced from an entirely pragmatic place.

My job is to implement software solutions for Falvey Library at Villanova University. Other developers who are now members of the VuFind community do similar work at other institutions. In theory, we could all build locally-tailored applications, thinking only of our own institutions. In the short term, this might even be easier, potentially eliminating some variables from the problem at hand. However, in the long term, the collaborative, open source approach has proved to be much more valuable. The first time I went home from work with an unsolved problem and arrived the next day to find that it had been solved on the other side of the world while I slept, I knew that we were on to something… but around-the-clock development and support is just one of several benefits of collaboration.

By comparing needs across many institutions, we have built software that is flexible and configurable. Rather than solving the same problems many times in our own silos, we have found shared solutions that work for all of us, freeing up time and resources to continually improve what we have built and to tackle larger problems. Through more than a decade of development, we have built up a substantial toolkit for solving discovery-related problems, we have pooled our knowledge and inspired each other to invent tools and features we might never have thought of in isolation – sometimes you don’t even know you need something until you see somebody else benefiting from it. As a direct result of the work we invested in making our shared software approachable, we are now able to be extremely responsive to local needs since our software is easy to change and configure in response to an ever-changing environment.

For all the benefits of open source that I have spoken of, it also has some well-known drawbacks, the most obvious being the fact that utilizing it requires specialized staff and technology resources. Even if an institution can afford these things, it may not be willing to navigate the challenges of hiring developers (who are often in high demand and short supply) or to take on the perceived risk of maintaining its own applications (which becomes ever more nerve-wracking in the current age of ransomware and other threats). It is hardly surprising that many administrators choose to outsource software management to commercial vendors, even though this can result in reduced agility, fewer opportunities for customization, significant ongoing costs, and increased dependence on third-party organizations.

Of course, there is really no simple binary choice of open source vs. commercial, because in reality, many institutions employ a blend of both. It is a question of strategy to decide which approach is most appropriate to meet each need. Ultimately, though, I think it may be time to move the conversation on from the idea of “open software” vs. “closed software” and instead start to think about the idea of “software as a commodity” vs. “software as a service.” In other words, is software a thing that we buy and sell, or is software simply a part of the process of achieving other, broader goals? As I said earlier, my feeling is that software is best viewed as a means to an end, and focusing too much on the software as a product can hold us back regardless of whether we are selling that software or building it for free.

On the commercial end of the spectrum, software commoditization contributes to the familiar scenario where a user “buys” some software, but then all requests for improvements to the software go into an “enhancement queue” which never gets resolved. The vendor benefits by making more profit from the sunk cost they already invested in developing their software, but the customer has no perceived benefit and no recourse. On the open source side of the equation, an equally familiar scenario sees a developer-heavy community building what they believe to be a valuable commodity, but then being disappointed that few people appreciate it because external factors like lack of documentation, training and support make it effectively unusable for many organizations.

If we instead focus on the ends rather than the means, we end up with a healthier ecosystem: institutions can hire their own developers to meet their local needs, or they can purchase services from commercial organizations. All of these participants can potentially collaborate on building software in the open while also reaping benefits from the process. Well-resourced institutions can be more self-sufficient while also contributing to the public good. Commercial firms can focus on strengths like customer support, documentation/training and business continuity while getting out of the resource-intensive arms race to develop essentially the same applications as their competition. Our tools would become more robust and future-proof by being reviewed, supported and understood by a much larger pool of developers.

Of course, not everyone would agree that this model leads to a software Utopia, but I think it is worth a try, and apparently I am not alone, as commercial organizations seem to be taking open source ever more seriously, and open source communities seem to be thinking harder about sustainability and accessibility. EBSCO’s role in the development of the FOLIO ILS, and the formation of the Open Library Foundation to support library-related open source, is one interesting example of this. With the VuFind project recently becoming a new member of the Foundation, I am excited to be a part of this movement, and I look forward to exploring new ways of enabling people to take advantage of what we have built and ensuring its ongoing openness.

Photo by Matt Duncan on Unsplash