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.
andromeda yelton 
Chris works in yet another area of information geekery; he is the support/development person, working for companies full of users. (Some of these users are also coders of lesser ability, which makes for interesting situations occasionally. “I employ people who can reasonably list the same things on their resumes that you have on yours. Why can’t they do what you’re promising me?”)
My dad is the non-CS guy who nonetheless has become his library department’s computer expert, simply because they discovered that when they sent him to training sessions, he came back knowing everything the session was supposed to teach, remembered it well, could build on it through judicious experimentation, and could pass it on to others in the department, which made him really weird in their experience.
My impressions from being around these two men is much as you describe: There are a small number of coders (like Chris) who exist outside the user context, and an important job skill for them to have is communicating with users to find out what the user context is like, what the user truly needs, how to design a user interface that will work well for the users, etc. Then there are a large number of users (like my dad and his colleagues) who are not writing code, who can often tell you about their frustrations with their current software in great detail, and (in my dad’s case) with plenty of cogent examples and good reasoning behind their gripes, who can sometimes even say what the software ought to be able to do or behave like, but who do not have the ability to actually change the software at all. (Add library administrators and politicians into the mix, and you can keep my dad talking all night, which is really rare for him.)
I have had some similar frustrations with open-source software. At this stage in my life, I am not interested in spending time on making my computer work; I want it to be a dependable tool, not a fun, nifty, time-sucking gadget. The price tag to open-source software is appealing, but the lack of support designed for individuals and the fact that you usually have to decide among a multitude of updates and add-ons when installing is generally enough to send me for the generic commercially-available software, where I may be annoyed at the lack of options, but at least I’m not overwhelmed by too many decisions to be made.
Newt
LikeLike
I feel like I ought to defend open source software as useful, necessary, and morally good and therefore worth sticking with… but I can’t. So much of it is so terrible. Free and open source software developers reliably forget that the code is not the software, it is only part of the software. They spend so much of their time on polishing code (making it something that is worth using) and very little time on installation, documentation, and interface, let alone offering support as you say.
And that appealing price tag often has the appalling effect of driving other software out of the market — which may be why you are annoyed by the lack of options.
LikeLike
Yeah, the state of the documentation for Koha made me sad.
I don’t think, though, that I’m seeing the driving-out effect in re library software; open source is a *tiny* percent of market share (albeit conceptually very important), up against some long-established competitors with a lot of installed sites. And there seems to be high awareness that purchase price != total cost of ownership.
“not the software, only part of the software” is a nice frame.
LikeLike
(Support, interestingly, is basically mandatory in the library software world — in part because it’s something people are used to getting from proprietary software vendors, in part because people don’t necessarily have the technical skills to do support in-house. This also must have interesting effects on the shape of the development community, and definitely factors into people’s price calculations.)
LikeLike
Remind me what exactly Chris develops?
I’m curious what kinds of communication channels/strategies his employer has developed for ensuring that information gets from users to him, and from him and/or users to developers in a non-support capacity (if applicable). Any ideas there?
And yeah, your last paragraph is why I tossed Debian and got a Mac. All the command-line access, none of the requirement that I use it (unless I want to).
LikeLike
Chris designs and develops means for businesses to access the information they have stored in databases. Data warehousing and business intelligence are the buzzwords in his industry; I’m not sure if you would have heard either one.
Chris would also be quick to point out that he’s not actually a programmer anymore; rather than “writing code,” he uses specialized software to manipulate databases, extract data from them, and display the information in various ways that help users make decisions. To the average person, the difference is completely immaterial, and the distinction actually confusing, but it might be relevant (and understood) in this discussion.
Chris often meets with clients directly to discuss their needs, how they want things displayed, etc. At this point, he and his company have been doing this for long enough that they can often predict some of what will be useful, which is helpful in making sales presentations and starting the discussion. Discussing what the client needs/wants is the best reason for sending Chris out of town; it seems to work best face-to-face. Actually doing the work on-site is pretty pointless, and sometimes counterproductive; clients who insist on this are annoying, both because they tend to want to micromanage and because it requires developers to spend more time away from their families. But face-to-face meetings periodically throughout the process do seem to help fine-tune what the client wants, etc. The results of these various meetings get translated into specifications, designs, etc., for internal communication.
Most of the work Chris does is client-specific. Conversations with my dad lead me to believe that library software usually comes mostly pre-done, designed for the generic library system, with varying levels of personalization available depending on the vender and how much you’re willing to pay them. I know much less about how that process works.
Newt
LikeLike
John, you can’t assume that all open source is good – just like not all proprietary software is good. But you can’t assume that it’s all bad either – when I teach open source for librarians I make it very clear that your evaluation of open source software should be no different from your evaluation of proprietary software.
Andromeda, we talked about the Koha documentation already on this blog. As documentation manager – and someone who works nearly full time on the manual I find it pretty annoying to have a non-Koha user constantly bashing my work – when those using Koha are extremely grateful and appreciative of the manual and how it has helped them.
On the issue of the post – I think the fact that the library open source products out there have a smaller programmer base is a good thing. In your question above about the communication issues – how is that any different than when you use a proprietary product? Do the developers at Microsoft know how you want to use Word? Do the developers at proprietary ILSes use the software they’re developing on a day to day basis? At least in the open source arena you know the names of the primary developers and how to contact them – and you’d be surprised how few of these developers have no library experience – most of them started in the library world in one way or another and so have a feel for how libraries are run and how they work.
I think that the fact that these software products have mailing lists and chat rooms open to developers and users alike show that everyone is willing to work together to better the product – even if the developers are no longer sitting in a library setting day-to-day (although many are).
Don’t know if that answered your question, but I sure hope so. The problem as I see it is that everyone seems to think that open source proponents are saying that all open source is great – and we’re not – we’re saying that all software should be open source 🙂 but that’s another rant for another day.
LikeLike
I admit I didn’t want to call out the documentation lest you were reading this, but the fact is it consistently failed to have the answers to the questions I was asking. Maybe it is strong in the parts that active users find themselves using a lot (I’d be surprised if it’s not, as a participatory project), but from my perspective as a learner, and given the particular problems our install had, neither I nor my classmates found it adequate. Perhaps someday I will be in a position to improve it :).
In what way do you think a smaller programmer base is a positive?
As for the communication issues — I don’t think it’s different from when people use proprietary software (and insofar as people developing such software don’t know about its use, actual and desired, that’s a problem) — what I’m wondering about is the difference between how the open source development community works for ILSes and how it works for things like Linux (where I’m more familiar with the latter because I know a lot of software engineers, many of whom have made at least the occasional contribution to some open source project or other). Certainly in the conversation I was thinking about, my software-engineer husband assumed there would be much more overlap between users and developers of open-source ILSes than I assumed there would be, so I’m curious about both what the community is actually shaped like, and how the community and process differ from more-familiar-to-me open source communities and processes if my assumption is correct.
LikeLike
The smaller programmer base means a more intimate community – like I said you know the names of and the contact info for every developer and they will all help you in any way possible (in my experience).
I apologize for misunderstanding the question. I don’t actually know the exact make up of the community working on Koha but I do think your husband is right, there is a lot of overlap (more than Linux – I’m not sure because I’m not a member of that community).
LikeLike
See, this is interesting to me in that the received wisdom I hear about open source development, from the codemonkeys in my life, is that a huge development community is an asset, because it means mroe eyes on the code, more chances to catch bugs, more capacity for development.
(And part of what I’m trying to do with this blog is untangle the very different assumptions about information and technology that I hear from my software friends and my library studies, so differences such as this are intriguing to me.)
Hm…
LikeLike
I can see that – and agree with that – but sometimes big is just as good as huge – or active and small is better than huge and non communicative … I think the problem is that you’re thinking too much in absolutes – “the documentation is a disappointment,” “good open source needs a huge community.”
The fact is – yes you couldn’t find what you needed in the documentation – but that’s just a small part of the whole – a huge community is no good if that community isn’t working together — and I have found at least in the Koha community the inanimateness makes it effective and strong. Just like I said not all open source is good … it all just depends on too many factors for absolutes …
In short – that rant means … there is no real answer to your question – as librarians we must evaluate all aspects of the software before making the decision.
LikeLike