Some of the keynote speeches I have seen were inspiring. Others were thinly disguised sales pitches. The worst were simply boring. However, a couple evoked record-scratch moments for me -- and those are the ones I remember best.
Earlier this year, Catherine Devlin of 18F spoke at the conference of the Evergreen open source ILS project. 18F is a group within the U.S. Federal government that aims to solves technology problems in collaboration with other government agencies. Among 18F's principles is a commitment to open technology, including the use and development of open source software, and a commitment to working in the open. Devlin's talk about openness and how to encourage government agencies to adopt open software meshed well with values and practices that the Evergreen project strives for.
Devlin's thesis went well beyond the technology. She suggested that the key contribution of open source will ultimately not be the technology, but a way of working: building things, be they software or laws, in the open where anyone can suggest improvements. Viewed with humility, criticism becomes a gift; moreso when inclusion is actively sought. Openly communicating about building something while it is being built can lead to better results. As Devlin has put it,
Imagine a world where laws are edited and commented [upon] online — where lobbyists must make public pull requests, and any one of us can file public bug reports.
Compelling, no? (For more on Devlin’s keynote, look at Tanya Schlusser's summary of a previous one.)
I promised a record-scratch moment. During her Evergreen keynote, Devlin said something to the effect that for her, the open source process extended not just to technology and managing collaborative projects, but also to herself. She's accepting pull requests for herself -- i.e., requests to change her habits and interactions with other people. One thing to emphasize about the metaphor is that a pull request doesn't just ask for a change: it gives precise instructions on how to do it.
This is radical openness and radical transparency. I have worked in free and open source software projects in libraries for over a decade and advocate for free software principles -- and yet I recoiled at the notion of announcing that anybody was free to file pull requests on… me. Wow.
Let's unpack my reaction. On the one hand, I believe that open source is a good ethical fit with several key library values. If libraries are to promote access to information and entertainment to as many people as possible, our tools should be openly available and developed. If we want to protect the privacy of our patrons, being able to directly inspect every aspect of the technology we use is crucial.
There are also pragmatic reasons for librarydom (and I'm using the collective term advisedly) to embrace open source. For one thing, credible development and use of open source software by libraries can counterbalance the power of proprietary software and content providers who seek to extract as much economic rent as they can from closed systems. Furthermore, since very few libraries field large teams of developers, working in the open provides a way for libraries to collaborate.
Openness and transparency are also virtues in other aspects of library management. A department or a director who develops policies in the open and invites critique and collaboration can be much more effective than an organization full of silos.
However, it is hard to adopt a stance of being open by default. Thinking about the notion of accepting pull requests on one's own person can help highlight some of the pitfalls.
Who gets to make the pull requests? On the one hand, one should be able to accept critique, especially if one has positional power, privilege, or both. Humility is often mentioned as an open source ideal for exactly that reason. On the other hand, people are also entitled to maintain personal boundaries; a workplace where everybody is expected to quietly take criticism on every aspect of their work and personality would quickly turn abusive. Not all criticism is valid; the bug trackers of any large open source project are rife with irrelevant, picayune, or wrong-headed critiques. Nor can all valid criticism and suggestions be acted upon in a software project -- or in a library; time is not infinite and priorities must be set. A significant portion of the emotional labor in open source projects revolves around managing critique.
If you work in the open, your failures will also be open. In a healthy organization, failure should be expected and learned from. However, being free to fail is often a privilege reserved to, well, people who already have substantial privilege. Even if an organization is equitable about responding to failure, it can take a leap of faith to be willing to fail openly. Do you trust your library to let you fail?
An open by default stance can be useful -- but it can also be subverted. Consider 18F: an organization that aims to transform government IT by introducing open source thinking is one thing in the context of an administration that believes that government can be effective. In another context, though, a government department taking the leap of faith into openness could be swiftly punished by its destruction.
Libraries should be open. They should be as transparent as possible. However, openness is not enough; in fact, a poorly-conceived or unbalanced mandate to be open can backfire. Openness can only thrive with a foundation of trust, respect for boundaries, and inclusiveness.
I’m still working through my thoughts on this, but I know one thing for sure: want to promote openness in your library? Start by promoting trust.
Author bio: Galen Charlton is a developer and manager at the Equinox Open Library Initiative, where he spends his time helping libraries to use and improve the open source integrated library systems Koha and Evergreen. This is his second post for LtaYL. The first was “Constant Vigilance”. He can be found on Twitter as @gmcharlt.