Meta Interchange

As has been noted all over, Anne McCaffrey has left us.

How can one mark the passage of an author? For me, a stranger to her, there’s really only one way: she lives on in her books, and so shall I reread. My wife calls for all who love Pern to read Dragonflight again in memory and honor, but for my part, I will travel to the stars with Helva as she serenades the void.

My local library uses OverDrive, so this evening I went ahead and tried to check out a couple ebooks for my Kindle (well, Kindle app). The steps required were pretty simple: library website to OverDrive catalog to title to checkout page. After I checked it out, I got dropped into Amazon’s website, where I finished by specifying which Kindle app to send the book to.

Of course, Amazon then gave me plenty of opportunity to buy more Kindle books:

One thing that’s not on that page is a link back to the library. It would be nice for the library to be acknowledged, although of course there could be privacy implications if OverDrive is sending Amazon enough information that they could construct such a link.

But suppose I were to purchase one of Amazon’s recommendations. Who benefits? Amazon, obviously. Who else? Is anybody collecting referral fees? And if somebody is collecting referral fees, can the library who paid OverDrive to lend the book that inspired the recommendations in the first place get a piece of the action? What about libraries who have signed themselves up as Amazon affiliates?

There’s a lot to discuss about the announcement, including concerns about patron privacy, Amazon’s DRM policies, and whether and how this will benefit libraries in the long run (in the short run, it at least means that librarians don’t have to answer the question of why they can’t lend books to patrons’ Kindles). But one thing seems pretty clear to me: libraries are about to see their OverDrive hold queues lengthen significantly, which will mean pressure to send more money to OverDrive to meet patron demand. But that doesn’t mean that the libraries can just stop buying physical books, so how is a library to deal with a potentially significant shift in their acquisitions budget?

Bringing this full circle back to the title of this post: can libraries get a piece of the action? Should they?

“It’s just politics.”

This is a common enough phrase, and the usual implication of it is dismissive: if it’s just politics, it’s not about anything really important. It’s grandstanding, it’s just more sound and fury, it’s a sausage factory. At best, it’s the domain of the politicians; let them worry about it. There’s a long post in me about how the attitude behind “it’s just politics” contributes to poor participation in democracy and bad policymaking.

This is not that post.

The inspiration for the post before you was somebody making a comment to more or less that effect the other day in regards to the past and ongoing controversy regarding Koha, its licensing, its trademarks, and its forks. My position on the matter should come as no surprise. If you want Koha, go to http://koha-community.org/. If you’re a librarian using it, please contribute back where you can and participate in the Koha community. If you’re a vendor supporting, implementing, or hacking it, know that it is not just yours, you should give back, obey both the letter and the spirit of the GPL, be a good community member, and don’t worry: you can do all that and still make money! Look Ma! No monopoly!

But dragging myself back on topic, one thing to clear up first: this post is not about the comment that inspired it. I am going after a generality here, not any particular throwaway comment.

What can “it’s just politics” mean when talking about a dispute concerning an open source project and its licensing? Quite a few things:

1. (Re)opening this can of worms is going to derail any discussion of the software itself for weeks. This can be a very real concern: disputes about the license or the direction of the project can take years to resolve, can become very acrimonious, and frankly can be terribly boring. I, for one, personally don’t find license disputes inherently interesting, and I strongly suspect that most participants in F/OSS projects don’t either. But bitter experience has shown me that sometimes it is necessary to participate anyway and not leave it just to the language lawyers. What can make resolving disputes even more difficult is that email and IRC as communication media have weaknesses that can exacerbate conflict.
2. Less talk, more code! What doesn’t get done if you’ve just spent an hour fisking the latest volley in the GPL2+ vs. AGPL3 debate? There’s an opportunity cost — that hour wasn’t spent writing some code, or testing, or proofreading the latest documentation edits. That opportunity cost can compound — if you don’t get the kudos for the results of that fisking and miss the warm feeling you get seeing a longstanding bug get closed because of your patch, you may end up disengaging.
3. Can’t we all get along? It can be very unpleasant being in the middle of an important dispute. While I do think that the Koha community has come out of this stronger than ever, I also mourn the opportunities for human connection and friendships that have been permanently sundered as a result of the conflict.
4. Newbie here. What is going on?!? It can be very disorienting checking out the mailing list of a F/OSS project you’re considering using only to find that everybody apparently hates each other. It can be even worse if you find yourself making an innocent statement that gets interpreted as firmly putting yourself in one camp or another. Tying this back to the previous point, is the Koha community stronger? Yes. Has it also developed a few shibboleths that cause project regulars to sometimes come down a little too hard on new members of the community? Unfortunately, yes.
5. From the point of view of an external observer, it’s hard to make sense of what’s going on. It’s all too easy to lose the thread of what’s is being disputed, and the definitive histories of the war tend to come out only after the last bodies have been buried. On the other hand, particularly if you’re an external observer who has some external or self-imposed reason to make judgements about the dispute, do your research: a snap conclusion will almost certainly be the wrong one, or at least lack important nuance.
6. The noise is getting in the way of figuring out if this software is useful. Fair enough — and if you’re a librarian evaluating ILSs, obviously a key part of your decision should be based on the answer to the following question: will a given ILS solve my problem, either now or in the the realistically foreseeable future. But read on, since that isn’t the only question to be answered.

The outcome of a big dispute in a F/OSS project can be positive, but there’s no question that it can be tremendously messy and painful. But just like in the realm of the elephants, donkeys, and greens, politics informs policy. And policy consequences matter. And there’s no royal road to success:

• Software doesn’t write itself. People are always involved, and unless you’ve just fired-and-forgotten some code into the wild, any F/OSS project worth thinking about involves more than just one person.
• The invisible hand is still here. The economics of a F/OSS project may not be based on cash money (though there’s a place for both money and passion), but the fundamental economic problem of resource allocation and human motivation is inescapable.
• Communities don’t build themselves, and they certainly don’t maintain themselves without effort. In the case of library-related F/OSS projects, there are special considerations: both the library profession and F/OSS hackerdom value sharing. However, there are significant differences in the ways that libraries and hackers tend to communicate and collaborate, and those differences can’t be negotiated without a lot of communication.
• Regardless of whether you fall more on the “F” side or the “OS” side of the divide in the acronym, F/OSS works for a combination of baldly pragmatic and ethical reasons. But as the very structure of the “F/OSS” acronym implies, there’s are many disagreements and differences of emphasis among F/OSS contributors and users.

What’s missing from these bullet points? The One True Path to Open Source Success. Why is it missing? Because it doesn’t exist: free software has been around long enough that there’s a good body of recommendations on how to do it well, but there’s no consensus.

And if there’s no consensus, then what? It has to be found — or created — or not found, leading to a hopefully amicable parting of the ways. But that can’t happen without discussion, conflict, and resolution. While it certainly isn’t necessary for everybody to participate in every single debate, (constructive!) engagement with the discussion can be a valuable contribution in its own right. If you can help improve how the discussion takes place, even better.

If you or your institution has a stake in the outcome, participating is part of both the duty and promise of F/OSS for libraries: owning our tools, without which our collections will just gather dust.

Put another way, politics, in its broadest and most noble meaning, can’t be avoided, even if engaging means spending some time away from the code. You may as well embrace it.

By the way, I suspect that if you did get manage to get software to write itself, you still couldn’t escape politics. I doubt that an artificial intelligence creative enough to code can be built without incorporating a sufficient degree of complexity that it would be able to avoid all moments of indecision. AI politics may well end up looking rather bizarre to humans, but they’d still be faced with the basic political problem of resolving conflict and allocating resources.

I had a great time at the Evergreen conference this year. Some of the highlights for me are:

• I got to see a lot of friends, both old and new.
• We started signing the fiscal sponsorship agreement (PDF) with the Software Freedom Conservancy. After the document crosses the country and back and gets the last few signatures, Evergreen will officially become the latest member project of the SFC.
• We made great progress setting up for the project’s move from SVN to Git. (If you’re a developer, please weigh in now on the vote taking place on open-ils-dev.)
• I talked a lot.
• Every restaurant I ate at was good, without exception.
• I learned how to play Munchkin.
• My wife and I found a house to rent.
• I even managed to get some sleep one night.

Many thanks to the conference committee for organizing a wonderful event. I’ll close with this image from the presentation by Rogan Hamby and Shasta Brewer:

There are lot of good changes coming in Koha 3.4.0, which will be released tomorrow. Check out the current draft of the release notes. But this release of Koha includes some major architectural changes, and although the upgrade process is simple, it definitely pays to read the instructions first.  

In particular, there are two upgrade steps that should not be missed:

Install Template::Toolkit

Koha 3.4.0 uses the Template::Toolkit Perl module instead of HTML::Template::Pro for the OPAC and staff interface templates.  Template::Toolkit must be installed before trying to run the web updater, as the web installer itself now uses TT.  If you run Koha on Debian or Ubuntu, run apt-get install libtemplate-perl. On other Linux and Unix platforms, install the packaged version of TT if available; if a packaged version isn’t available, run cpan Template.

Note that if you’re following the instructions, running ./koha_perl_deps.pl -u -m will catch the TT dependency requirement. Just don’t forget to actually install it.

Run scripts to update your bib records

Koha 3.4.0 will no longer store copies of the item record data as MARC fields in the bibliographic records. This resolves a long-standing performance issue where changing an item record (even just to change its status when it is checked out) required that Koha update the bibliographic record as well. However, this means that during upgrade it is necessary to touch all of the bib records in order to remove the item tags. To do this, run the following steps:

misc/maintenance/remove_items_from_biblioitems.pl --run
misc/migration_tools/rebuild_zebra.pl -b -r

This can take several hours on a large database, so plan accordingly.

At MPOW I search a lot of library catalogs (and usually I am indeed interested in the searching, not the finding per se). But what do you search for in a “foreign” library catalog?

In the postscript to this post, Jonathan Rochkind reveals that his “brainless test search” is typically “frogs”. Mine is “Amish”, which I picked up from one of my bosses years ago. It’s short, found in the catalogs of most English-language libraries (and in a surprising number of non-English catalogs), and doesn’t return thousands of hits. And apparently, every public library in the U.S. is required by law to hold a copy of Amish society by John Hostetler.

What’s your typical search when you want to test a library catalog?

Liz Rea of the North East Kansas Library System and I have started a new group blog, Library Hackers Unite!. It’s a blog by and for library sysadmins and programmers with a practical bent, and we aim to cover the gamut of library systems hackerdom.

Besides Liz and myself, Joe Atzberger and Ruth Bavousett write there as well. Want to join the crew or do a guest post? Drop Liz or me a line.

Ollie LOLcat by mlcastle

Jeffrey Beall, in his post about the results of a LITA survey on library standards, gleans the following:

More notable is the absence of Semantic Web standards from the answers to this particular question. Notice that SKOS, RDF, and SPARQL do not even appear in the “other” section of the survey response (see below).
…
The absence of Semantic Web standards among the several dozen responses to question 3 is very telling.

Telling what, though? Not necessarily very much. The survey question that Beall highlights is Are there particular library-oriented standards important to your work? That strikes me as a rather broad question. Important to one’s work now? In the future? In an ideal world where all metadata is easily slice-and-diceable by anybody?

If you’re a library technologist working with library data, MARC may well be the most important library standard to you right now — after all, it’s what we have for bibliographic metadata. What about the absence of Semantic Web standards? Well, linked data approaches are still experimental, but then, once upon a time, so was MARC. Suppose ALA had conducted a survey in 1967 (before the MARC pilot program had wrapped up) asking about important standards. The catalog card likely would have been identified as the most important technology for day-to-day work, while MARC would have been at the bottom of the list.

The survey is part of LITA’s efforts to become more active in the development of library information standards. If LITA is to achieve that, we need to not only look at and maintain the past, but more importantly, experiment for the future. I actually am not entirely certain what point Beall is trying to make, but if LITA were to focus on developing the MARC standard to the exclusion of experimenting with other ways of expressing bibliographic metadata, that would be a mistake.

Yesterday the Open Knowledge Foundation announced their principles of open bibliographic data. Following a definition of “bibliographic data” (though I don’t think that the distinction drawn between “core” and “secondary” data is useful here), the principles are

1. When publishing bibliographic data make an explicit and robust license statement.
2. Use a recognized waiver or license that is appropriate for data.
3. If you want your data to be effectively used and added to by others it should be open as defined by the Open Definition (http://opendefinition.org) — in particular non-commercial and other restrictive clauses should not be used.
4. Where possible, we recommend explicitly placing bibliographic data in the Public Domain via PDDL or CC0.

I have endorsed the principles and encourage others to do the same.

The principle discouraging data licenses that restrict commercial reuse is an important one. I can see why somebody who is considering releasing a set of bibliographic data into the wild might be tempted to use a license that forbids commercial use. After all, the vast majority of bibliographic records are created or improved by librarians working for non-profit or governmental entities. Although I don’t think anybody ever became rich beyond the dreams of avarice reselling library data, obviously there is some money to be made there, given the existence of commercial and quasi-commercial firms that deal with library metadata. Why should those firms be allowed to make money off the fruits of the labor of countless catalogers without direct financial recompense?

And … I can’t say that I entirely disagree. Libraries spend a lot of money creating metadata in a punishing economy; if some libraries can manage to get some money back to help keep catalogers and metadata specialists employed, so much the better. Until the advent of true artificial intelligence, there will always be an important role for the human creation and maintenance of metadata, though we also need to do a lot better with automating metadata production.

However, bibliographic data is most useful in the aggregate. A single bibliographic record, no matter how well crafted, has very little value. Put enough of them together to describe a library’s collection, and you start to get somewhere: you now have enough to make a catalog. Put a lot of metadata together, and you can do all kinds of interesting things.

It is in the aggregation of metadata where the licensing decisions that libraries make when releasing bibliographic data matter most. The less friction there is to commercial and non-commercial reuse of the data, the more the data will be used and improved.

Consider this: if I, in the course of my duties at a for-profit MPOW, find a file of records that I can do something useful with, I can get started doing that right away if I see a PDDL or CC0 license associated with it. If, instead, I see a no-commercial-use clause, I’ve hit a point of friction. I may choose to track down the contributor and negotiate a separate license, or, more likely, I’ll look for something else to work with. Unless you are the likes of the Library of Congress (i.e., your metadata can’t be ignored), using a non-commercial license when releasing your data simply means that it will be less likely to be used and improved. Worse, if a non-profit decides to aggregate PDDL/CC0 data and commercial-use-restricted data, it is even more difficult for commercial entities to touch the dataset at all — it’s one thing to track down one rights-holder, but dozens?

Metadata is for use. It is also for continual editing and improvement, as metadata is also imperfect and incomplete. A library information ecosystem that promotes easy access to metadata and easy sharing might manage to keep up and stay relevant.

Of course, if numerous commercial entities make use of open bibliographic data but never compensate the libraries who paid to create it in the first place, that would over time become a strong disincentive for libraries to release open data. Therefore, I would like to suggest a fifth point — maybe not so much a principle as a recommendation — to commercial entities who make use of open bibliographic data: consider treating all open data, even data in the public domain, as if there were a mild copyleft license attached to it. In other words: give back. If in the course of providing your service you are not only using open data but improving the records, release your improvements as open bibliographic data. Moreover, invest some time in releasing your improvements in a maximally useful way — putting a file of improved data on your webserver is a good start, but if there are ways to contribute back to shared bibliographic databases or a hypothetical peer-to-peer metadata exchange so that the improvements can be more easily reused, consider doing so.

I just realized something — I’ve never heard anybody refer to the LITA OSS IG as the “awww-zig”. Probably just as well.

Anyway, here’s my pitch for the meeting, which is today, 9 January 2011, at the San Diego Convention Center in room 31C. By design, the IGs in LITA are perhaps the wildest and wooliest part of ALA, being forums for like-minded librarians and library techies to discuss and work on cool toys and share ideas for the benefit of their libraries. The OSS IG is no exception; one of the best parts of our meetings is going around the table and having everybody present discuss what they’ve been up to with F/OSS. Think of it as Code4Lib where ties and jackets are allowed!

There is also a business meeting, which co-chair Daniel Lovins and I will keep as short as possible, but fortunately, there’s little in the way of administrivia to talk about. The main agenda item for the business meeting: what does the OSS IG group want to do next? To toss some ideas out:

• Find good speakers for a managed discussion for the meeting at the next Annual.
• Do a workshop or preconference. The migrating to open source systems preconference at ALA Annual last year was a success, so we know we can do it again.
• Organize a LITA webinar or web class.
• Post to the LITA blog.
• Do something neat on the LITA sandbox server.
• Or do something else entirely.

I look forward to seeing friends of F/OSS, the curious, and even the dubious for what will be a great discussion.