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.
Posted on this day, other years:
- Reflections in a Golden LIAL - 2011
- Aye, Me Beauties -- I can see Russia from my poop deck, arrrrr! - 2008
- Set Piece - 2006
- Meditation in Brief(s) - 2005
This is a very good point.
Now, I may be prejudiced because I’m a developer — AND I’m also a librarian. So one thing I think we in library land need is more librarian-developers. (And I don’t necessarily just mean ‘MLIS degreed’, I think you can be a librarian-developer without having an MLIS).
But also, something I’ve been thinking is:
users are to the library as a whole
as: the library as a whole is to the systems dept and developers
as: the library is to it’s vendors
(Put that analogy on your GRE!)
In the sense that: We librarians as a whole are responsible for understanding user’s needs and using our professional expertise to figure out clever feasible ways of meeting them. We can NOT simply let the users tell us exacty what they want and then do it without thinking — becuase they don’t know (even if they sometimes think they do — there is LOTS of discussion in non-library contexts about how what users SAY they want isn’t always what will make them most happy.)
It’s an abandonment of our professional responsibility to try and do that. Similarly, vendors can’t simply expect customers to spell out what they want in precise detail and then do it. That’s an abandonment of the vendor’s responsibility to figure out what the customers are actually trying to do and need, and figure out clever feasible ways of providing it.
SO. Similarly, in these kind of open source collaborations, we need discussions involving librarian-developers and non-developer librarians, in which the needs and goals are figured out — and then the developers need to figure out the best way to accomplish those goals, as feasible.
That’s how we get good products.
[And I’d add, in case it wasn’t obvious, I think most of our traditional library sector proprietary software vendors HAVE abandoned that responsibiilty — which is how we have ended up with hacky unsustainable software that isn’t actually capable of doing what we need — but does EXACTLY what hundreds of customers told the vendor they wanted over a decades long history. )
I agree with you 100%!
[…] https://freerangelibrarian.com/2009/09/18/it-takes-a-village-koha-and-open-source-leadership/ a few seconds ago from web […]
[…] highlights the role that Open Source software must play in the future of librarianship, It Takes a Village: Koha and open source leadership […]
[…] Free Range Librarian › It Takes a Village: Koha and open source leadership "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." (tags: bibliotheken) […]
[…] Takes a Village: Koha and open source leadership [web link]Free Range Librarian (18/Sep/2009)“…experiment and an honest acknowledgment that […]
I too agree 100% that vendors must responsibly “figure out what the customers are actually trying to do and need, and figure out clever feasible ways of providing it” just as librarians should do for library users. In my earlier life working for a library automation vendor, we often encountered cases where Library A would say “This feature must always do X!” and Library B would say “This feature must never do X!” (same feature, same X). It is never as simple as “just listen to us librarians and do what we say”.
After much discussion, “the developers need to figure out the best way to accomplish those goals, as feasible.
That’s how we get good products.”
Yes.
[…] thought about this on and off ever since the RFP was but a twinkle in my eye, but Karen Schneider’s post about the shift from the “librarian-centric†to “developer-centric†model brought it back […]