Lies, Damned Lies, and Library Automation Software


What’s on my mind today? I’ll tell you: it’s the War against Evergreen.

What’s that Jason? Surely you’re kidding?

No, I’m not.

Another title could be Open Source vs. the Used Car Salesmen. We’ve seen this before with Linux vs. Windows; but I’ve never expected to experience such a thing first hand. It really upsets me. We’re passionate about our software, we’re a meritocracy with development, but we get distracted by people coming to us after having been fed with misinformation. We’ll pit technology vs technology any day (and win or lose, we adapt and ultimately win), but should we really have to deal with Jedi mind tricks?

The war started internally when Evergreen was just an idea. We had to fight for it. We won that battle; but then came the Sith. :)

One prominent incident happened about 2 years ago, while Evergreen was in heavy development, when a non-US library consortium contacted us and told us what a particular vendor was telling them:

  1. That we were having problems with development and were running behind schedule (*cough* we were ahead of schedule *cough*)
  2. That one of our biggest problems was that we would always be a step behind their company/product (stair climbing the Tower of Babel for kicks and giggles? some folks are playing catch-up to us and pretending otherwise!)
  3. That “open source development would lead us down a path to disaster, leading to a third-rate, third-world system” (riiiight…)

What was up with that? Evergreen wasn’t even in Alpha yet and a vendor was worried about us enough to spread Fear, Uncertainty, and Doubt, commonly known as FUD. Did they skip the part where they were supposed to ignore us? We confronted the vendor and they denied everything. :)

More recently, a vendor told a client that Evergreen can’t do holds. Um. What? That’s one of the main features in use by PINES… heck, it’s one of the main purposes of PINES: the sharing of materials amongst libraries. Evergreen, in fact, has a better holds system than the vendor in question: our hold targeting is randomized when selecting materials at certain geographic ranges (say, statewide), instead of simply selecting the last copy added to the database. What a novel idea!

Here’s some Evergreen FUD related to databases:

  • Evergreen really uses MySQL and not Postgres
  • Relational databases can’t handle MARC, and thus Evergreen does not support MARC
  • Evergreen can’t handle formats besides MARC
  • Evergreen can’t search the entire MARC record, only subsets of it

All false (and some even contradictory!). Evergreen uses Postgres in a replicated environment, can handle all sorts of bibliographic formats, can maintain a fulltext index on any of them in their entirety and in subsets. I’m not sure that all of these were started maliciously, but at least some of it originated from people who should know better *wags finger*.

Here’s another place brimming with FUD. One particularly good bit:

  • Evergreen isn’t really “open”, “grass roots”, or they.. uhhh.. don’t play nice

I suspect this is coming more from a Koha vs. Evergreen angle, because certainly none of the proprietary vendors are open by any open source definition. Evergreen, and I assume Koha, were open source from the very beginning, with the primary hope of becoming sustainable through a community of volunteers. I believe Koha has succeeded with this goal, and I believe Evergreen is succeeding with it (our community really started forming after Evergreen proved itself with PINES). However, no two open source projects are exactly alike, and there are wide variations in how gift cultures and meritocracies organize and manage themselves. The ground rules the original developers try to model are the same as the Postgres project. We humbly await your patch, and that includes patches to our culture and community, because we are what you make us.

Here’s more on a blog post:

  • used by 1 library system (a little disingenuous to compare 1 system to 500 libraries, when that 1 system is composed of 265 libraries)
  • designed for top-down control, ie. a single decision is made by the administrators for the entire system (that’s the situation we jumped ship from)

I guess it’s a matter of perspective. The proprietary vendors have thousands of installations, but are people really happy with them? As for top-down control, it’s more like control at whatever point in an organization hierarchy it makes sense to, and that’s regardless of whether we’re talking about statistical codes for patrons, statistical codes for items, surveys, shelving locations, call numbers, templates, or what have you. If we’re missing something, it’s easy to address, because the infrastructure is sound. If anything, you can say Evergreen was designed with a public library bias, yet we’re discovering that adding academic features is easy. If there’s something you want to see, let us know!

Here’s some more FUD from an email we happened to come across:

  • Evergreen is only useful for huge installations
  • It’s too complicated for all but the biggest libraries to deploy

I find this very amusing. We have “individuals” in our “non-open” community deploying test environments of Evergreen, and creating vmware images to share with others that make the process even easier. We have vendors willing to do it for you. And it’s only complicated where it needs to be! :D

Remember, Evergreen was intended to be open source from the project’s very inception, so the intent was always that other libraries would use it. Wherever possible, we abstracted and made things flexible. One of our mantras is that software should not dictate policy, and since policy is prone to change, the software must be easily adaptable. We even hired developers from outside the library industry to give us a different perspective. We weren’t perfect; there’s domain knowledge that we lack (and that the community is addressing), but the foundation we built is solid. Hopefully I won’t feel the need to say more on this topic, and I admit to being a bit exasperated. Please forgive me if you made it this far. :-)

I guess the best sanity check for possible misinformation is for people to come straight to the source–code and community. We’re here, we’re in #openils-evergreen on freenode IRC, and we’re on the OPEN-ILS-GENERAL and OPEN-ILS-DEV mailing lists (http://open-ils.org/listserv.html).

Thanks for everything folks!

– Jason


6 thoughts on “Lies, Damned Lies, and Library Automation Software

  • chris

    Interesting post, Koha suffers much the same sort of FUD.

    With people saying things like “Its only for tiny libraries”. “Their is no commercial support”, “It doesn’t support standards”, “Only used by small libraries”. This list goes on.
    If people want I can dig up the emails and blog posts and link them in, just ask.

    Like Jason says, the best thing is to join the community and look at the code.

  • George Duimovich

    Good rant Jason – I can sympathize as an observer from afar.

    You forgot one other major FUD angle: that open source in general or EG in particular doesn’t have a business model to rely upon! This is a remarkably odd one because what’s interesting about open source is how flexible it is to a wide variety of business models! You want to make money with OSS – lots of successful business models to do that !! [e.g. OSS underpins most of the successful web 2.0 companies, (and anyone heard of a company called Google?) etc.]…

    Or if instead you want to just share high quality software with a community of users and developers – there’s plenty of enterprising business models to do just that too – it’s not easy, but it’s done successfully all over the place. And that’s what companies like Equinox are there for, and unlike the prop. vendors, Equinox actually has to compete for your support and maintenance business, since anyone can enter that marketplace.

  • Scott Garrison

    Not to mention that Ex Libris’ new discovery tool Primo is built on Lucene (and individual institutions are already building their own Primoish/Endecaish things on Lucene too–let’s hope they can open source those).

    What cracks me up most is the ‘relational databases can’t handle MARC’–tell that to SirsiDynix and Ex Libris. C’mon, Innovative, grow up.

  • Michelle

    Thanks for clarifying these issues. I went to the ALA presentation on Georgia Pines’ use of Evergreen, and it was fantastic! It increased my excitement about open source ILS, and I will continue to pay attention to this project.

    PS I believe you’re right about vendors giving misleading information because they are scared…which means that they recognize that this is a promising project that has already delivered and will probably improve at an exponential rate (at least compared to the commercial versions!).

  • Bess

    Nice rant, Jason. Try to take comfort in the fact that the vendors wouldn’t be spreading FUD if they weren’t terrified. A better ILS? That we can support ourselves? That we don’t have to pay huge licensing fees for? It’s only a matter of time before it becomes evident to many libraries that they are being taken for a ride by their vendors. Of course the vendors are trying to postpone this realization for as long as they can.

    My favorite argument against open source ILS is one I recently heard from a vendor: “We have over 300 developers! No library could ever compete with that!” Well, no single library could ever compete with that, but in an established thriving open source community you have WAY more than 300 developers. In fact, no vendor could ever hope to compete with it.

    For Scott: Blacklight is the Primoish/Endecaish OPAC front end that we’re building at UVA, and it is definitely open source.

  • Andrea

    Hi Jason! I also saw your team’s ALA presentation, and I was blown away by how clean and user-friendly your patron interface is. And blown away by everything else too. I am now trying to convince my director to ditch the dead Horizon product line and just jump to Evergreen.

    Just to clarify one of the FUDs (at the risk of being labelled a finickly cataloger):

    MARC, while it can operate in the relational model, in fact DOES NOT play well with the relational model, and it kinda never has. MARC was never intended as a structured database language but was created as a text transmission protocol, and it was created in the 1960s before the advent of relational database theory. I think (may be wrong) it actually takes more from heirarchical theories.

    There are many redundancies in MARC that a (normalized) database wouldn’t contain, and there are many internal MARC structural elements that a lot of ILSs don’t support and that are outside of a relational model.

    So, in short, one of the key problems with all relational ILSs is that MARC was never intended to work in that model, and was retroactively hammered into a relational model …

    The question on my (cataloger) mind is, “Is MARC hindering truly dynamic products?” and I’m interested in what the more techie folks have to say about that.

    Anyway keep on rockin’, don’t let the big guys get you down. They’re just scared, and jealous, and rightly so.

    (i.e., I have been told that Horizon has over 500 legacy tables that its current release DOES NOT EVEN USE. mmmm, junky.)

    Go Evergreen!

Comments are closed.