Previous Post where is my easy button?
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.
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.
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.
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.
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).
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.
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.
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.
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).
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.
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.