τεχνοσοφια

Issue five of the code4lib journal is out. This issue looks to be just as good as the past four issues, but I'd like to highlight one article in particular: the column by Kansas State's Web Development Librarian, Dale Askey: We Love Open Source Software. No, You Can't Have Our Code.

Librarians are among the strongest proponents of open source software. Paradoxically, libraries are also among the least likely to actively contribute their code to open source projects. This article identifies and discusses six main reasons this dichotomy exists and offers ways to get around them.

If you're at a library doing open source software, or if you think you're doing open source software, or if you're considering jumping into the fray, you would do yourself, your institution, your users, and the open source community (whatever the heck that is) a great, great service by reading this column. Srsly.

I've worked in academic libraries where open source was given lip service the likes of which Jimmie Walker would envy and yet, well, show me the code already!

See, here's the thing, if you're doing open source, or think you're doing open source, it is necessary that you release code to the public under an open source license. The public includes your institution, your partner institutions, all of academia, random hackers in East Kaboomistan, and everyone else; if you make code available to partners only, that's not open source; that's multi-institutional closed source. It's a walled garden with teleportation devices leading to other walled gardens. And we're tired of hearing about your damned azaleas. We want to see them, and take cuts from them, and grow our own, and contribute some back to you.

Releasing code is necessary to claim you're doing open source, yes, but it is not sufficient. There is some value in just throwing code over the wall. Sure, once the code is out there you've satisfied a definition or two and you can go off and pat yourself on the back and do the happy Ewok dance and maybe some more grant funds will come your way. But if you want to add value to your involvement in open source, and add value to user-facing services built upon open source software, and add value for the vast community of open source developers champing at the bit to get at your code and make it better and work with you towards crafting a shiny, happy world, for goodness' sake, Mr. Gorbachev, tear down that wall. Stop the madness; no more "just fork it because it wasn't invented here." Take commits from the world. There's the value in open source.

Do we get this? I hope we get this. None of this is new. Some of us in libraries have been banging the open source drum for nearly a decade, some even longer. The rhythm is a well known one, but the drum quite apparently needs yet more beating. And louder beating. Thank you, Dale, for keeping the beat. Now, if only this rhythm section had a bassist.

Sometimes I find it useful to keep long-running processes in a session of screen.  And sometimes I launch one of said processes outside of screen, and then I yell something like "doh!" or an expletive, because, as I said, I do find screen useful.  Depending on how far the process has gotten, whether it was the sort of operation that would not run happily again, or how much cleanup a second run would require, I either kill the process and restart it or I suspend it with Ctrl+z and send it to the background with bg % so that it doesn't die when I log off.  The latter is a decent option.  But, darn it, I like screen.

Well, perhaps I'm the last to know, but there's this neat little tool called retty that allows you to attach running processes to your terminal.  I installed it in Ubuntu Hardy the typical way (sudo apt-get install retty).  So, the next time I screw up, I'll Ctrl+z, bg it, and then screen retty {PID}.  Voila!

Thanks for the nod, Winona. Hopefully you folks will get some good use out of the XQuery-based OAI-PMH data provider I've been working on.

I just want to clarify that only one small bit of the code is specific to X-Hive, and that's a call to an extension that gets last-modified dates from the X-Hive service. We do not reliably store this information in the metadata itself, and so I needed to go this route. Some folks do store this in MODS or elsewhere in descriptive or administrative metadata. It should be a two-line change to short-circuit this behavior (xhive-exts:last-update() is only invoked in two places, I believe).

I'm currently working on adding EAD support, modularizing things a bit more, and streamlining configuration. resumptionTokens will come after that, I hope.

I'll be interested to hear more of UVM's implementation and how I can make this thing more useful to others.

A couple of interesting stories regarding open source library projects have come out during the past few days.

First, Carl Grant, the former CEO of VTLS, is forming a new company devoted to providing and building services for open source software. The name of the company is CARe Affiliates, and they have already struck a deal with open source software provider Index Data (creators of Zebra, YAZ, YAZ Proxy, Metaproxy, Keystone, and so forth). I have worked just a bit with Carl and he seems to be a stand-up guy. Best of luck, Carl.

Second, the Mellon Foundation has approached the GPLS with great interest in the open source ILS, Evergreen. Where this is going is yet to be seen, but it's something to keep an eye on. It could be a fantastic opportunity for libraries that are frustrated with their current ILS and have the resources to commit development time. (With an assumption that the former set is vastly larger than the latter set.) This could be very exciting.

Those who still doubt that open source in libraries is a legitimate movement must find it more and more difficult to justify their arguments.

The unAPI plug-in for WordPress has moved to the following location: http://www.lackoftalent.org/michael/blog/unapi-wordpress-plug-in/