Or: What “web-scale” innovation looks like
From the comments at: http://blog.okfn.org/2010/11/29/open-bibliographic-data-how-should-the-ecosystem-work/
Jennifer Younger, chair of the Catholic Research Resources Alliance (CRRA) Board of Directors, president of OCLC Global Council, and co-chair of the OCLC Record Use Policy Council, writes (excerpted):
…At the same time, I feel it’s important to point out that I don’t see OCLC’s new record use policy as a barrier to the aggregation and sharing of data on the Catholic portal, even if our contributors gave us linked data, which they are not doing nor have they asked to do so, or if we decided to provide the portal as linked data. I’m confident we could work out a way of doing this in the context of the WorldCat rights and responsibilities described in the record use policy…
Jennifer, thanks for your comments.
The need to ‘work out a way of doing this’ with OCLC appears to many of us on-the-ground library software developers to be a barrier to collaboration and sharing in a way that I’ve come to think OCLC honestly doesn’t understand. So let me try to explain a bit.
I, like most library software developers (and certainly not unique to libraries either) am awfully busy, and working on many things at once. Sometimes I’m working on something, and I think, gee, with just a bit of extra effort, I could share this with other library developers (or the world in general). Maybe by putting my code in a public repository; maybe by providing a public API to my service; maybe by sharing my data. (That last one of sharing data is often implemented by an API; and the second one of an API often will involve sharing data if it is to be useful).
I’m not really sure if this is going to be useful to others or not, but it’s worth a bit of extra effort just in case. The effort will be less if I do it when I’m in the middle of the project then if I try to go back and do it later. Throw enough of those things out there, some of them will ‘stick’ and wind up useful to others, some of them won’t. Some of them that do ‘stick’ will find synergy with similar things someone else has done and synergistically build into more than the sum of its’ parts — this how a lot of collaborative open innovation on the internet happens.
But it’s just worth a BIT of extra effort, I’ve got way too many things to do to make a big project out of sharing something that just MIGHT be useful.
Your suggestion that if you really want to share something you can find a ‘way to work it out’ basically means: 1) I’ve got to get my boss involved, probably. 2) We’ve got to have a discussion with OCLC, which 3) First involves finding the right person at OCLC to talk to, and 4) Then involves having a bunch of conversations, possibly leading up to 5) Signing some contract or agreement with OCLC, which probably will mean getting my boss’s boss involved, and possibly even the next higher up boss. And that agreement may require 6) Additional development time to make sure it’s done the way OCLC wants.
This is a real barrier, even if the end result may indeed usually be OCLC agreeing that the sharing is acceptable. It’s enough of a barrier that many things simply won’t be shared, we won’t be throwing everything out there to see what ‘sticks’ anymore, we’re only willing to go through that effort with things we’re pretty darn sure will be awfully useful (and our bosses and bosses’ bosses will agree are worth putting institutional resources into sharing too). But we don’t always know in advance what those things are, we’re often wrong predicting it — ‘web scale’ innovation (to borrow a phrasal adjective) doesn’t happen with that kind of pre-planning, it happens from throwing a bunch of things out there in an agile way and seeing what happens to it.
Now, it may very well be that OCLC’s business interests and ongoing, long-term viability mean that it’s just not possible to provide for an environment supporting that kind of agile sharing and innovation. I suppose that’s a decision for OCLC to make. But I don’t think OCLC neccesarily realizes the trade-off being made here — we developers aren’t unhappy with the record use policy restrictions just out of spite, or because we want to ruin OCLC’s sustainability or viability (most of want no such thing). We’re unhappy because it really is a barrier to innovation, because many things we’d like to do will end up remaining undone.
(And when I say “I suppose that’s a decision for OCLC to make”, really, as a member cooperative, that’s a decision for OCLC’s members to make, and I’m not sure the administrators at OCLC member institutions realize the trade-off either.)