"We have one more talk left and we'll see how Eric Hellman manages to do the closing talk, and if he deserves the slot or not" was how Ed Corrado introduced me yesterday at the Code4Lib 2011 Conference. Thanks, Ed. A little pressure never hurt anyone. I suppose I had it coming. Here's the abstract I wrote for the talk:
You can view the talk yourself via the excellent streaming video archive from Indiana University. (My talk starts at 171:24) I was told that at times, there were as many as a thousand people viewing the live stream, and having a twitter and IRC backchannel allowed remote users to join in the snark: "not sure why people voted for this presentation" and the inexplicable: "This presentation is good, but I would have expected multiple Celtic fonts."
I gave a brief intro to the trends in ebook adoption, and went through an explanation of the economics of book lending that I wrote about last year. I urged everyone to break the wifi by downloading Eli Neiburger's "Libraries are screwed" talk. Then I suggested that Code4Lib participants were the people with the power, placement and passion to drive the changes that libraries will need to survive.
Last week, I sent an email to the Code4Lib list, asking for information about how many people were developing or maintaining software (broadly defined) in libraries, and what fraction of the library staff they represented. The results are displayed in this graph:
Notes on the graph: Red dots are from Code4Lib respondents; the blue dots are taken from a peer group survey made available to me by one respondent of the "technology staff" in a cohort of mid-sized US Universities. The determination was made by title alone, without knowledge of actual job responsibilities. My own survey of job titles in libraries suggests that many job title terms such as "technical services" encompass responsibilities ranging from zero to full time involvement in software, even when broadly defined. One Code4Lib respondent reported that he was the only developer in his library and had only just been hired; the peer group survey indicated 2 technical staff for the same library. To place the data on the same chart, I've arbitrarily divided the technical staffing for the peer-group survey by 3.
One thing to remark in this graph is that most developers in libraries are very dispersed. Although they're embedded in library operations, they're often the only person at the location that does any coding at all. Many of my respondents reported that only a fraction of their responsibilities involved coding. As a result they tend to seek a peer group outside their institution, for example, in the various Code4Lib forums.
One reason that such a group is nonetheless well placed to effect change in libraries is the changing nature of software development. Today, software development is more and more about the use and deployment of software modules and connecting to APIs. The presence at Code4Lib of several vendor representatives promoting their APIs: OCLC, SciVerse, SerialsSolutions, Mendeley is testament to the importance of putting powerful tools into the hand of people who can see what to do with them.
To do this, libraries need to recognize the importance of code. Developers in libraries need time and support to develop their skills and focus on developing new ways for libraries to deliver value. Although I suggest a focus on Spaces, People, and Communities, I don't really know the answer. I just know that a lot of experimentation is needed.
I worry about public libraries. They are the data points at the bottom of the graph. I fear that publics will not have the technical capacity to do anything differently from what they've always done, except less of it, because of budget cuts.
Notes: In my talk, I mention a talk from earlier in the morning about how libraries are using software to improve their spaces. The talk I was referring to was by Jason Casdan and Joyce Chapman at NCSU. I should also note that a recurring theme of the conference was that the one thing that people most needed from mobile apps was the opening hours of the library locations. That's worth thinking about.
Libraries have historically delivered value to society by facilitating the sharing of books. The library "brand" is built around the building and exploitation of their collections. These collections have been acquired and owned. As ebook readers become the preferred consumption platform for books, libraries are beginning to come to terms with the fact that they don't own their digital collections, and can't share books as they'd like to. Yet libraries continue to be valuable in many ways. In this transitional period, only one thing can save libraries from irrelevance and dissipation: Code.Talks were selected by vote of Code4Lib participants, which increased my motivation to do a good job.
You can view the talk yourself via the excellent streaming video archive from Indiana University. (My talk starts at 171:24) I was told that at times, there were as many as a thousand people viewing the live stream, and having a twitter and IRC backchannel allowed remote users to join in the snark: "not sure why people voted for this presentation" and the inexplicable: "This presentation is good, but I would have expected multiple Celtic fonts."
I gave a brief intro to the trends in ebook adoption, and went through an explanation of the economics of book lending that I wrote about last year. I urged everyone to break the wifi by downloading Eli Neiburger's "Libraries are screwed" talk. Then I suggested that Code4Lib participants were the people with the power, placement and passion to drive the changes that libraries will need to survive.
Last week, I sent an email to the Code4Lib list, asking for information about how many people were developing or maintaining software (broadly defined) in libraries, and what fraction of the library staff they represented. The results are displayed in this graph:
Notes on the graph: Red dots are from Code4Lib respondents; the blue dots are taken from a peer group survey made available to me by one respondent of the "technology staff" in a cohort of mid-sized US Universities. The determination was made by title alone, without knowledge of actual job responsibilities. My own survey of job titles in libraries suggests that many job title terms such as "technical services" encompass responsibilities ranging from zero to full time involvement in software, even when broadly defined. One Code4Lib respondent reported that he was the only developer in his library and had only just been hired; the peer group survey indicated 2 technical staff for the same library. To place the data on the same chart, I've arbitrarily divided the technical staffing for the peer-group survey by 3.
One thing to remark in this graph is that most developers in libraries are very dispersed. Although they're embedded in library operations, they're often the only person at the location that does any coding at all. Many of my respondents reported that only a fraction of their responsibilities involved coding. As a result they tend to seek a peer group outside their institution, for example, in the various Code4Lib forums.
One reason that such a group is nonetheless well placed to effect change in libraries is the changing nature of software development. Today, software development is more and more about the use and deployment of software modules and connecting to APIs. The presence at Code4Lib of several vendor representatives promoting their APIs: OCLC, SciVerse, SerialsSolutions, Mendeley is testament to the importance of putting powerful tools into the hand of people who can see what to do with them.
To do this, libraries need to recognize the importance of code. Developers in libraries need time and support to develop their skills and focus on developing new ways for libraries to deliver value. Although I suggest a focus on Spaces, People, and Communities, I don't really know the answer. I just know that a lot of experimentation is needed.
I worry about public libraries. They are the data points at the bottom of the graph. I fear that publics will not have the technical capacity to do anything differently from what they've always done, except less of it, because of budget cuts.
Beer4Lib |
This comment has been removed by the author.
ReplyDeleteEric, thanks for your terrific presentation and write-up. I appreciate the shout-out and I'm happy to hear that our project fits in with your well-reasoned vision for library spaces. At NCSU, we've got several other irons in the fire re: library spaces:
ReplyDeletehttp://www.lib.ncsu.edu/dli/projects/physicalspaces.html
By the way, one of the more popular parts of our mobile site is the webcam pointing at the coffee shop line. This was added as an afterthought, but it actually ends up meeting a need for our patrons.
I don't understand why libraries can't share ebooks. I'll agree that they don't really need to, ebooks are infinitely copyable so the physicality of the matter is erased. Local Laws might prevent your local library from sharing ebooks, but laws can be changed. Once everyone has all the ebooks they need, I will agree that the function of the library comes into question.
ReplyDeleteA common argument concerns how to get food into the writers mouth to enable the writer to continue to write. Not everyone is just going to write without the promise or at least the expectation of food so this is an argument worthy of consideration.
Perhaps libraries can become publishers?
Librarians as gatekeepers of knowledge, as it was, as it is, as it always will be.
There will always be a need for hardcopies no doubt about that. Libraries can become printers as well I suppose.
A librarian could write the code too, someone has to.