Why so negative?

Why is it that when open source is mentioned some people (librarians/techies/programmers/etc) get mean? I have not had a chance to read Software and Collaboration in Higher Education: A Study of Open Source Software by Paul N. Couran (Principal Investigator) and Rebecca J. Griffith – but after reading some comments I will be making time today.

Over at The Medium is the Message, Eric asks Are OPAC Vendors Days Numbered? He states:

I suspect the the combination of open source and the reluctance of vendors to keep their systems up to date will result result in the demise of significant number of commerical library vendors in the next five years. The poor performance and outdated products of commercial OPAC products is due largely to the disconnect between developers in software firms and their customers. This should be an advantage to library developers, and the timing to look at open source networks/incubators is ripe.

To which commenter bcarson responds:

I have worked in five different public, academic and medical libraries and with five different library systems. (Innovative, NOTIS, Dynix, some Mac-based system whose name is the one thing I can’t remember about it, and a homegrown system that was easily the worst of the lot).

What ever happened to “if at first you don’t succeed try, try again”?

First – homegrown (to me) means built in-house. If you don’t have a programmer in-house that cares about libraries and what the librarians want and need – you’re going to get a substandard application. Our library has applications built by outside programmers and applications written by me – and if I do say so myself, the time I spend researching our librarians needs far outweighs the time the outsiders spent. This is why you want a librarian or library supporter to write your code – not a computer programmer who thinks he/she knows what’s best despite the cries of the staff.

Second – just because you tried one “homegrown” application does not mean that all open source options are bad! Open source is just now coming into its own – it’s growing in support – which means it’s growing in user base – which means you have a much large community to help support and upgrade your application. And with some/most open source applications – it costs you nothing but time to give it a try before bashing it.

Another commenter, Darla Grediagin, mentions that she and her library are switching to Koha.

I will be able to stop giving money away to a company for support every year and use that money to add the bells and whistles that I want to my system. The only problem with the additions I make, Hmmm…. I have to share them with others. Wow, what is one of the major components of a librarian — we share. I think open source will be a great way to go.

She too is met with a skeptical (and rather rude) commenter (on her blog post – not her comment).

It just makes me angry when people dismiss open source because it’s free or because it’s not supported by a big company. As far as I’m concerned big companies are great – but they’re full of faceless people who don’t know me or my library. If I can develop (and support) something for my library or any other library and then am given the opportunity to share that code with other libraries to make their lives easier – I’m all for it!

I agree with Darla – sharing is a major part of being a librarian – and open source is all about sharing – see the connection??


  1. IMHO, anyone in the library community who isn’t open to alternatives just doesn’t understand how serious the problem is (with our current ILS systems).

    While it is entirely fair to say that open source alternatives have yet to mature, require significant risk taking in many settings, and come with their own problems, there is a certain foundational building block that is crucially missing with OSS; namely, VENDOR LOCKDOWN.

    I don’t know how widespread this is, but I’ve also detected a bit of “I want a Innovative or SirsiDynix, etc. on my resume [b/c that’s what “everyone is using”] not an OSS solution that nobody heard of…”

    Critics of OSS could argue that the vendors have indeed pulled through on their customers wishes (witness the “IUG enhancement request” process for example they might say), but this again misses a critical marketplace fact. Suppose the aggregate of customer demands is indeed for tweaks to the existing system (not true IMO), then arguably the vendors are “doing a great job.”

    But what supporters of this view miss is the overly restrictive and out-of-date architecture issues surronding how new features and functionality are engineered and packaged for their customers and how seriously these restrictions are hampering our current and future roles in the communities in which we work.

    You want data integration and interconnectivity — sure you can have it! Just buy yet another overpriced, clunky product from your vendor since they’ve done their best to make sure you can’t work with anyone else’s technology!!

  2. Ouch. That’s the first time I’ve ever been called “mean” with respect to open source projects. (I’ve printed this off and I’ll show it to my supervisor the next time she calls me “wide-eyed.”)

    My characterization of the “homegrown system” was intended to be a characterization of the “homegrown system” and not a characterization of open source in general — especially considering that the “homegrown system” was not even open source.

    Likewise, when I characterized the report’s authors as careless with respect to terminology, I intended only to characterize the report’s authors as careless with respect to terminology.

    I agree absolutely with your first point:
    1a. “If you don’t have a programmer in-house that cares about libraries and what the librarians want and need – you’re going to get a substandard application.”

    This was exactly the problem with the “homegrown system.” This catalog was used in a hospital library. The catalog was built by programmers who didn’t care much about the library, barely talked to the library director, never followed up, and responded to complaints by saying, “We’ve finished that project.” We were never allowed access to the code; in fact when I was asked, I was told to stick to my job description.

    1b. “Our library has applications built by outside programmers and applications written by me – and if I do say so myself, the time I spend researching our librarians needs far outweighs the time the outsiders spent.”

    Same here. When we chose a new vendor for my current library, we chose a vendor because no open-source options existed for what we needed, and we didn’t have the staff to bring something up to speed. Now I spend a good deal of my time writing, borrowing, and sharing scripts that do things the vendor’s system won’t do.

    1c. “This is why you want a librarian or library supporter to write your code – not a computer programmer who thinks he/she knows what’s best despite the cries of the staff.”

    Exactly my point. And the paragraph that Eric posted indicated that the report’s authors were neither librarians nor library supporters. Having read the report now, I haven’t changed my mind.

    If you perceive some meanness when open-source projects are mentioned, maybe this the cause: librarians are constantly inundated with advice from outsiders, some who have not set foot in a library since their undergraduate days; others who never even had undergraduate days; and still others who believe that being able to locate a book on the shelf or place a hold online makes them masters of all things library.

    And some of these people hold administrative positions at the Library of Congress. But that’s another cause for meanness on another day.

  3. Thank you so much for clarifying! Considering the context I assumed that you were considering your “homegrown” solution the same as open source – which I know it is not.

    I admit I didn’t find time to read the report – but I will do so this week.

    I was just a little annoyed at the negative sounding comments on both blogs – glad you’re a supporter of open source & not one of the negative people!!

  4. Sometimes when I think of the library-vendor relationship, I’m reminded of what the TV detective Monk says when he asks people to do things for him; “If you do it, I won’t have to.” When we sign with an ILS vendor, a whole flock of issues can be quickly reduced to a line on a budget. I’ve worked with top decision-makers (“above” the library in the budget hierarchy) who positively ache to have someone make the problem of all this technology simply go away.

    As I see it, the most important short-term effect of having viable open source ILS software across the whole range of the library market (small libraries to large consortiums) is not that everyone will choose them and vendors will “go away”– it’s that it will drastically change the economics of the business. How much does it really cost to make the problem go away? Now we’ll be able to tell.

    It can help us as librarians gain at least a little more leverage over this process. If we’re lucky, we can promote innovation and customer service to help libraries stay in the game as the information market changes around us.

  5. Roger, I can’t tell if you’re for or against open source – but I do agree with your point that the purpose of supporting open source isn’t so that the vendors “go away” – I think it’s so that the vendors sit up and pay attention – if we have another viable option then the vendors will have to look at their practices & make a change in order to stay in the game.

    Vendors are always going to be a necessary evil because having an open source ILS (or any application for that matter) is not feasible for some libraries – particularly libraries without someone in-house to help with support.

  6. I’m very much in favor of open source software. My point was that even if you think you’d never trust your library to software created outside a corporation, just having OS competition in a market changes it, and changes it in a way that should be good for us all.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>