LibNiblets Tiny nuggets from Scot's corner of libraryland.

CAT | Technology

My friend Kathy Lussier in the southeast region of Massachusetts asked me to pull together something about the new OverDrive public beta of their Media Console software for Android devices. I took a stab at a video, with less than optimal results. I mean, the video came out okay. But the demo, not so much.

Ironically, the presentation Kathy was doing was going on today at the exact same time I was meeting with Steve Potash, the CEO of OverDrive! Apparently, the 1.0 version of the software is set to be released soon, so wouldn’t that be a lovely win-win for all if I could post a new happy review in a couple weeks?

, , , , , Hide

Nov/09

17

Please wave at me

I finally got my Google Wave acceptance. And yes, I’ve already given out all eight of my invitations. (Do you need a gmail one?)

If you’ve got Google Wave, please add me as scolford@googlewave.com

, Hide

Stephen Abram (cc by-nc-sa 2.0, The Shifted Librarian)

Stephen Abram (cc by-nc-sa 2.0, The Shifted Librarian)

I’ve been meaning to start a professional blog for a while, but laziness has prevented me from actually, you know, posting anything. Yesterday, however, I stumbled upon a post by the awesome Jessamyn West about a document that Stephen Abram, Vice President of Innovation for SirsiDynix, authored and has been disseminated to a few of the company’s customers.

The document is simply an editorial about Open Source ILSs versus proprietary products. Naturally, Abrams, representing SirsiDynix, portrays OSS efforts in this area as nascent, insecure, expensive, and inferior alternatives to proprietary platforms such as … well, as SirsiDynix products. This immediately set off a flurry of blog posts and Twitter updates slamming the paper as a Fear, Uncertainty, and Doubt (FUD) strategy and taking Abram to task over the lack of accurate citation.

Abram has responded to the reaction with a plea for respectful discourse and claiming personal attacks on him and his family. I haven’t seen any below-the-belt attacks, actually, so I’m not sure where that’s coming from. But Abram is taking the time to respond to each individual comment made on his response. This actually looks like an effort to have the last word, but regardless, at least he’s reading them.

What concerns me most about Abram’s white paper, position paper, or FUD propaganda (whichever you choose to call it), is not so much the damning analysis of open source efforts in the world of ILS applications without any numbers, citations, or verifiable facts. I’ve grown to expect that from a private company disseminating literature meant to recruit new customers or keep current ones.

My concern lies in the misrepresentation of SirsiDynix products as superior to all open ILS alternatives on all accounts. Abram writes of SirsiDynix’s 20-year-old history of providing APIs for its customers use. I think he’s referring to Sirsi products like Unicorn, which my library have never used. Instead, we are a Horizon library and no such APIs have been available to us, unless you count a Z39.50 server, a useless NCIP server, and an additional licensed, clunky SIP 2.0 server that didn’t handle ESIP standard responses. (We recently licensed a new ESIP server from SirsiDynix, but it took many calls to many staff as there seemed to be conflicting knowledge about whether such an add-on was even available.)

Without API support, we’ve spent years reporting bugs to Dynix/SirsiDynix, many of which I was told were not bugs at all, but expected functionality. Example: If telephone notification is selected as the default notification method for a location, but a patron has no telephone number in their record (therefore receiving mail or email notices instead), the OPAC informs such patrons that they will receive notification by phone. Simply not true. I was told to fill out an “enhancement request” to change this behavior. And we all know which enhancement requests float to the top in that process — the ones that affect the greatest number of customers, not the most critical issues that may affect a minority of customers. In my experience, enhancements that survive are piddly interface tweaks driven not by user experience, but by library worker satisfaction, the likes of which Abram attributes to OSS development on page 10, paragraph 3 of the controversial document:

“… these projects do not have a compelling vision of what the end result will be and appear to be driven by library workers’ desires rather than institutional strategies or end-user needs. As such, they are tying up resources in an open source ILS effort at a time when budgets are constricted and other priorities are much more important and strategic.”

But in my experience, community development encourages just the opposite. Indeed, I see individual developers working on critical shortcomings and contributing them back for the good of all users. One developer can permanently fix what hundreds of proprietary customers have held together with the spit-string of batch scripts, database triggers, and custom stylesheets. I’ve spent years creating many of these complicated workarounds for Horizon software, frustrated in the knowledge that potentially hundreds of others were doing similar work. Talk about Total Cost of Ownership! I’m well aware of the very real “free kittens” warning and am always sure to include it in my writings on F/OSS. But what about the care and feeding necessary for a very expensive purebred kitten prone to disease and genetic health problems? The customization challenges Abram attributes to OSS ILSs are just as significant a problem in proprietary environments, so… caveat emptor to all.

Some folks may be tempted to dismiss my arguments regarding Horizon, since SirsiDynix seems to have realized the hopelessness of continued development of the troubled application they aquired from Dynix. That thorny situation, however, opens a whole new topic that Abram doesn’t address in his document.

Customers are essentially slaves of the proprietary vendors they use. We are now in the very difficult position of running an ILS that has not lived up to the promises we’ve heard from our vendor over many years. We’re forced with a choice between migrating to another system if we want to provide the level of service we should be providing to our customers. Meanwhile, we’re paying hefty maintenance fees to a large company as we search for an appropriate solution.

Can Abram explain to me how this would be different if we were on an open source ILS that didn’t live up to our expectations right now? I can. We could investigate migration options while paying substanitally smaller maintenance fees, or none at all if we so choose. We could also be reallocate those funds to support continued development on our OSS ILS and help our neighbors in the process. Taking control of one’s own services seems eminently preferable to stamping feet and pointing fingers at an unresponsive vendor.

, , , , Hide

Find it!

Theme Design by devolux.org