Free Puppies, by Flickr user calamity_hane
This Monday, 1:30-3:30 at WCC-146B, I am participating in yet another Ultimate Debate: “Open Source Software – Free Beer or Free Puppy?” The event features Marshall Breeding and Stephen Abram, and will be moderated by Roy Tennant. It has a hashtag of #ultdebate, and even John Berry will be there.
(Sidebar: Berry, how is it that four years is “enough” for our debate when you’ve been writing that column for hmmmm… how long? But no matter…)
The debate has the potential to be really dull or unusually interesting. When I was invited to this event, I was just transitioning from spending a little over a year in a development and support company for open source software toward my new role as university librarian, and Stephen Abram would soon be leaving his high-profile job at Sirsi-Dynix for a position at Gale.
I suspect some people expect me to renounce open source (get thee away, open code!), and others expect me to doggedly embrace it no matter what, like those annoying Apple cultics who would devour arsenic if it arrived in a rounded white plastic container with that familiar fruit emblazoned on its bottlecap.
At MPOW, I’ve been very busy with urgent priorities, from repairing bathroom exhaust fans and tearing out unneeded shelving to rebuilding relations with campus departments and on to creating Team MPOW — a 100% tech-literate, forward-thinking, entrepreneurial squad of library miracle workers.
My library management system… well, it works, which means I can stay focused on other stuff, and its contract is really, really long. That doesn’t mean we have no other choices–there’s always a buy-out, or even a walk-away option–but I am frying all those other fish. (The issues with long ILS contracts I will save for another post someday.)
To me it boils down to who we are as a profession–not just now, but historically. I think companies that produce proprietary library software assume that libraries such as mine wouldn’t benefit from open source software because we would never be able to use OSS without paying for support services and we’d be very unlikely to engage with the development community to any great extent. But I think that’s like assuming that people who don’t use libraries don’t benefit from library service. We, LibraryLand, benefit from our hive mind, particularly in such a sharing profession.
The fundamental problem with the proprietary software model is not one of evil ownership or grasping vendors. I’ve seen both of those occur in the open source software community. The problem with proprietary library management software–from a high-level perspective, profession-wide–is that it makes us stupid. It deprofessionalizes who we are and disengages us from tool creation.
Conversely, every librarian who engages in tool creation to any degree improves the state of librarianship for all of us. This has been true since some guy in a toga put holes in a wall to store the papyrus, and it was true in the 19th century when we agreed as a profession on the size of catalog cards (which led to our early adoption of standards and network-level records), and it is true in the open source community today.
If you think that’s not the case, compare the discussion lists for proprietary products with open source products. I do that every day. For E
One of the facts in life is that library administrators take the jobs they take (and this is my fourth head-of-the-whatever library job, not to be confused with my various military MFWIC positions) based on many, many things… and the integrated library system they will inherit is rarely if ever one of them. I just don’t know anyone who says, “Someday, if I’m lucky, I’m going to lead a triple-I library.”
(There’s ample room for a joke right there…)
I have inherited a library with great staff, serving a progressive institution committed to many great values, and it happens to be a Sirsi library. In fact, it’s going to be a Sirsi library for a while. A long while. And I’m not going anywhere for a long while, either, because the goals I have for this job require I stay here for at least five to seven years.
Stephen Abram, in his, um, “white paper” on open source, has put me in a double bind. Unlike open source, where competing vendors can and do arise to offer better services — as is ably proven by the rise of Bywater Solutions and other Koha vendors following the egregious misbehaving of Liblime — as a traditional proprietary-software customer, my choice of vendor is Sirsi or… Sirsi. I can piss them off and undermine this library’s ability to do its job, or I can build and maintain good relations with the many fine people who work there, and by encouraging the best possible support from Sirsi, help improve our library’s services.
We have a lot of challenges at My Place Of Work. Over half our print collection is still in a card catalog. (Yes. That’s right. And I keep finding warrens stuffed with more uncataloged stuff.) Our small mid-1950s facility is crammed to the gills with materials, many of which were selected in a pre-librarian era of this library, and our heavily-used computers haven’t had a computer “refresh” in about 8 years. Most of the furniture predates even Mad Men (though I do have really cool chairs in my office, which I plan to redo on the cheap in Mod style).
But we have a lot of assets, too. We have great staff, and yes, there aren’t enough of them, but show me the library that has enough staff, and I’ll show you a place I don’t want to work. We participate (”we” being one amazing librarian) in a marvelous faculty development program that is helping this library better integrate itself into academic activities. We have a pretty good database selection for a library this size, and it will get bigger. We belong to the absolutely fabu SCELC consortium, which has great leadership and great membership and super services.
And we have something that’s hard to explain or define, but it’s the sense that things will prevail. That may be because I am kind of dumb. I remember when I returned to California the LAST time, and the first bit of news I had was “welcome to California, by the way, we’re cutting your budget 40%.” I am stupid enough that I didn’t see this as a cue to fold my tent and go elsewhere, but instead kept improving services (to make a more compelling pitch for funding) and finding alternate revenue streams, where I was allowed to do so. From what was shared with me after the fact, the project I managed apparently outlived many attempts to kill it.
My stupidity will help me at MPOW as well. I am happily optimistic that the day I turn in my keys, I will look back and see how far we have come, and that will be a far way indeed.
(Of course we need more staff! I’ll take ‘em! But if I read one more library “strategic plan” that begins by complaining about staffing, I’m going to explode. Don’t start your “plan” by telling me what you don’t have — tell me what you do well, and what you can be!)
Finally, though thi
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.
