Okay, struck out the apparently incorrect slur against fac-bac-opac in my previous post. I still have a different perspective than Karen on libraryland’s historical approach to open source, and how often libraries have forked vs maintained a common codebase.
(Certainly I inherited a bunch of forked versions of code from other institutions when I started here. And many people have asked for my code–to then fork it. Of course, it’s my fault for not having my code in a shared code repository. But anyway, the point isn’t fault, the point is that this takes a bit of work to do right.)
Whether libraries have by and large done it or not, the important point is that doing it right takes a bit more effort at first. It pays off down the line, but you’ve got to spend time working with other people, and you’ve got to spend time architecting localizable software, instead of just hacking away to get what you need today.
A library approaching open source for the first time needs to realize that ‘doing it right’ doesn’t necessarily come automatically, it takes attention. In my experience.
I actually just got around to reading it myself (yes, even though I’m an editor, I didn’t read this article until after it was published!), but Dale Askey’s great column in the newest Code4Lib Journal addresses some of these issues in passing.
This can be traced to how open source software moves through libraries. It begins with personal contact: Librarian X asks Programmer Y for some code. Flattered and temporarily overcoming their innate perfectionist side, Programmer Y happily complies. When something goes awry — inevitable due to the myriad system variables in play — Librarian X writes a “sorry to bother you, but” message. Being a nice person in a service-oriented organization, Programmer Y assists them, but may end up somewhat cranky about it since it detracts from their own work and yet does not add to their list of accomplishments.
[jrochkind would add: Or, Programmer X (And Z, and Z1, and Z2) fixes the bug that appeared due to their different environment themselves, without sending it back to Programmer Y, because they don’t want to bother her with it. And changes behavior to meet local needs, while they’re at it. ]
Sounds simple, but it often fails because of the innate culture of many libraries. Having become mired in the vendor-driven rut, we cannot find our way out. In that world, we are simply consumers of software. We pay our money and get a product. We provide feedback, ask for enhancements, but that is more or less the extent of our involvement in the development of the software.
With open source, one can choose simply to download the code, install it, and start using the software. That’s not likely to get one very far. There are versioning issues, customizations, security concerns, backup plans, bugs, and so on. What often happens with open source software in libraries is that non-technical librarians and staff begin to view their colleagues down the hall in the IT shop as the vendor, and simply continue reporting issues and asking for enhancements. What they fail to understand is that with open source, they have the ability and, I would argue, the responsibility to seek out their own solutions and participate in their implementation. They need not know all the technical details, but they should be able to articulate what they need, seek solutions from the community, and suggest how these would fit within their institution’s suite of services. They should assist with usability and documentation issues, which do not require programming skills.
Essentially, it’s at the point of shifting from being a consumer of software to being an active participant in the open source community that the misunderstanding hits its zenith. Most librarians do not understand the open source software model and fail to recognize that by using open source software, they are tacitly declaring their membership in the community
More fundamentally, libraries that wish to use open source software need to understand the staffing commitment they are making by going that route. Open source software requires programmers, interface designers, and system administrators. These people are often not librarians, although one frequently sees job ads asking for librarians who have such skills, as if library schools were actually cranking out such people in any quantity (they should be, and this failure will negatively impact libraries for decades). As such, we struggle as organizations to define the needs, properly prioritize them, and make progress on finding the right people with the right skills. We don’t commit to paying the salaries necessary to attract and retain enough experienced and talented people.
A related issue is the question of recognizing and rewarding staff contributions to the open source community. Libraries typically have no reward systems for putting something out there that helps others.
These are largely questions of leadership in libraries and the necessity of moving past the traditional roles and obligations of libraries and embracing radically different organizations than we currently have. Leaders must have a new vision of using large software packages, where the question isn’t simply open source vs. commercial, but, if one chooses open source, how to provide the resources necessary to make it successful. As Dan Chudnov pointed out in the conclusion to his chapter on open source software, in 2007, it is “impossible to run a library without software, but you can have a library without a building” (29). This insight should force us to significantly revise how we set priorities as organizations, but that shift has been slow to develop.