structure of open source community

So my husband (a software engineer) and I talk a lot about this library stuff, duh, and it’s useful for exposing underlying assumptions that differ between these two fields of information geekery…

One of the things I’ve been thinking about is the structure of open source development communities. I’ve run Linux (albeit no more) and a lot of my friends are the kinds of codemonkeys who will merrily write a script when the world doesn’t do something they want it to do. I’m used to thinking of open-source development as people encountering things that are personally bothersome and fixing those themselves, when the software in question is something computer geeks use — Linux, Apache, funky lightweight apps to do whatever, et cetera.

But the assumptions in my head about how Koha and Evergreen and OPALS are developed are, I realize, different. I think of integrated library system development and I think of a small number of coders — from library consortia, academe, and ILS support companies — contributing to the codebase; I think of the vast majority of (potential) users as simply not having the ability to do that. In other words, I think of there being some latency and information loss in the communication between user and developer in a way there’s not with, say, Linux (where user and developer are the same person). In fact I imagine it must go both ways — that developers are not necessarily embedded in a library context (e.g. if they work for support companies) and therefore may not be heavy users of the system, and may not be developing that sort of intuition for the workflow imposed by the system.

Am I right? Am I wrong? Because I really have no idea, and it’s fun to use the blog as a way to learn things. (Thank you to all my lovely commenters who have pitched in on this. 🙂

It seems to me the nature of an open source development community, and the possibilities for the software, must be interestingly different depending on how greatly the user and developer communities overlap, but I do not really know how (aside from the suddenly crucially central role of support companies in the low-overlap case). Certainly, though, the idea that if software is broken or stupid you cannot just write something to fix it is a paradigm shift for software engineers, but not for librarians, which does complicate some of these conversations.

I even really like citrus fruits! And yet.

So apparently LibLime (a support vendor for Koha, a major open-source ILS) has done a bait and switch — people who signed up for Koha support are in fact getting a vendor-specific, only-sorta-open version of the software.

I’ve been having unkind words about LibLime percolating in my head for a week which I’ve been not posting here, because I try not to be an unkind-words sort of person. But I no longer feel restraint about that.

So here’s my experience with LibLime:

They deleted my, and all my classmates’, final projects (Koha demos which they were hosting). The day before they were due.

A miscommunication was involved, and it can’t be said to be entirely Koha’s fault. The demos had been, properly, on a deletion list. But they also deleted them without notifying their client in advance. Or…noticing that there had been a tremendous amount of activity on these sites. Or, indeed, noticing that they had had support transactions on those sites within the last few weeks.

(This was ironic as part of my group’s conclusions about Koha is that you shouldn’t run it unless you personally are very comfortable with a Linux command line, or have a close and trusting relationship with an IT department or hosting company. So much for that plan…)

In addition, the demo sites they gave us were missing some very important functionality, and they couldn’t figure out how to fix it. I figured out how to fix it. Let’s keep in mind here that I’d never worked with Koha before this term, and the documentation…well, isn’t ideal, let’s say. I couldn’t implement (or verify) my solution because I didn’t have access to a command line, but I could use the knowledge to figure out a hack I could implement from the front end which got it working well enough for our purposes.

So for those playing along at home: yes, that means the person totally inexperienced with the software and without access to the command line diagnosed and fixed the problem before the person who gets paid to do that.

LibLime…oh, LibLime. I want there to be inspiring, kick-ass open-source support companies for the library world. I want open source to be able to offer both market and conceptual challenges to traditional software. I want the library world to have the agility that open source offers to try new tools and new paradigms. None of that is going to happen without quality support. That support, alas, is not you.

(via Jessamyn West; Nicole Engard, the author of the bait-and-switch post linked, is also a regular on the thought-provoking Library 2.0 Gang podcast with all sorts of library-luminary names)