 |
| source |
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.
No comments:
Post a Comment