Working for a vendor, it’s been hard for me to figure out how to personally respond to the recent Liblime brouhaha. What is a “personal” response in a world where our private/public lives are so blurred? But I feel this event personally, because it touches on so many things I have written and talked about over the years — including the very survival of librarianship.
For those of you not steeped in all things open source, this brouhaha may not even be on your radar scope.
It boils down to this: a company, Liblime, long associated with Koha open-source library software, has chosen to develop some custom, non-open-source code for a customer.
As I understand it, the effect of this decision on the Koha project is to “fork” the code — that is, there will now be two flavors of Koha: the free-and-open version, and the version that has the custom code. Liblime is within its legal rights to do this, but Liblime’s actions have dismayed many members of the Koha community.
Liblime has also suffered some staff attrition. Nicole Engard, for example, has resurfaced doing Koha work for another Koha support company. But that, in a sense, “proves” the health of the open source model, where at least on paper, no project is beholden to any one vendor. Fortunately for Koha, it is still bigger than Liblime.
Yet lessons-learned abound. This kerfuffle not only represents a systemic change for Koha-the-software, but has surfaced a constitutional crisis for the project itself.
Like a lot of software projects, Koha’s movement toward coherent self-government has lagged behind its software development and adoption, and this has left the project in a position where no one legally-recognized entity can say to Liblime, “No, you can’t do that.” Koha has a nascent user group, and has been talking about a foundation, but it hasn’t got to a place where Koha belongs to Koha, with a clearly-defined legal entity.
I think that’s what Marshall Breeding was getting at, in part, when he stated, somewhat awkwardly, that the Koha project has “a very developer-focused perspective” that would be improved by more participation and engagement from the librarians whose libraries use Koha — that is, the broader community.
In Marshall’s view, open source projects should be librarian-centric; “libraries should manage the governance of the software, while establishing conditions that encourage participation by vendors that provide services to the community of libraries that rely on the software.”
I’ve heard this theorizing from other sources. Why, all those developers need is for the librarian grownups to provide “adult supervision.” (Actual words heard verbatim.) They’ll take over those projects (also heard in the field) and make them effective through their excellent project management skills. Etc.
Unfortunately, project management expertise is in short supply in LibraryLand, and it isn’t usually valued like other skills. That’s evident from the facts: to date, there are few if any examples of successful librarian-centric open source software projects, with actual working code used in live production environments. (Someone suggested yesterday that the Notis project would be worth examining, as an example of strong software leadership early in LibraryLand’s history.)
Librarians do bring terrific skills to the table. We have a strong service orientation. We are practical. We understand what these products must do, and we have a firm grasp on timelines and calendars. We also have an appreciation for order, governance, and transparency. But we simply don’t (yet) have the core competencies to do what we did one hundred years ago — design, build, and manage our own tools. We lost our way several decades ago, and we need to acknowledge that we can’t get out of this forest on our own.
There are some large, airy, well-funded LibraryLand schemes that remind me of the joke about the Unitarian who was headed to heaven, until he saw the sign, “This way to a discussion about heaven.” There are some small test pilots here and there. Then there is also the warning example of Vufind, which in a year-long leadership vacuum spawned enough forks for a dinner party, and is now just shakily reassembling itself.
The reality is that neither model works on its own: not the code-focused project where one vendor can cause a major breach, and not the library-centric project endlessly spinning its wheels in a thousand thousand thousand committee meetings. We need one another; we benefit and learn from one another.
Evergreen would never have gone live as real-world production software if librarians in Georgia hadn’t participated in its design (and if, in the ying-yang of good process, developers hadn’t then locked themselves in rooms and coded like crazy). Now, just after its third birthday, Evergreen’s community — perhaps shaken by events ensuing in Kohaland — is having a healthy and upbeat conversation about formalizing its governance.
It truly takes a village — in many senses of that phrase. The health of an open source project, particularly for software developed for people who are not developers, depends on true diversity in participation — developers, librarians, sage administrators, brash young folks willing to experiment — and an honest acknowledgment that healthy project leadership will be inclusive of all these roles.
That means a lot of discussion and compromise, and yes, a few committee meetings. It means that a slice of the effort of any project will be devoted to building and governing that village, and that everyone is in agreement that this is necessary work. But I think real events unfolding right now have demonstrated once again what every major open source project outside of LibraryLand already knows: there is no other way.
