What follows is pure conjecture; I did not live through the time in question, I can only speculate based on biased evidence and anecdotal hearsay. This is a blog, after all, right? Feedback is welcome.
Where have all the flowers gone? /
Long time passing /
Where have all the flowers gone? /
Long time ago /
Where have all the flowers gone? /
Girls have picked them every one /
When will they ever learn? /
When will they ever learn?1
This is the story of library automation as I understand it. At one point, say the 1970s and early 1980s, libraries were at the forefront of information technology. After all, we had an application, call it a specialized inventory control problem if you will, that was ripe for automation. And our major research universities did just that — built grand systems that tracked the circulation and location of our books, then automated the process of copy cataloging, then acquiring items and tracking serials, and finally the “OPAC.” (Is that really true? — Did we do the end user part last?) These libraries had in-house programming teams than built these systems, then (again: “I think”) in the hacker tradition of the era gave away the code.
And that was okay for some, but for many there was the desire or demand for professional support. So the automation design and programming teams left the research universities to form companies that sold and supported software for our specialized inventory control problem, draining talent from in-house library organizations.
Where have all the coders gone? /
Long time passing /
Where have all the coders gone? /
Long time ago /
Where have all the coders gone? /
Left our libraries every one /
When will we ever learn? /
When will we ever learn?2
Those organizations have never recovered. Libraries are now reliant on vendors with legacy, specialized inventory control systems that themselves are struggling to reinvent what they are.
So here is the thesis: We must regain control over our own automation destiny.
The vendors, god love ‘em, are too far from our users. I believe they are aware of that; I know that I hit myself regularly with the “you- work- in- a- consortial- office- not- in- a- library” stick until it hurts just so that I never forget how distant I am. (Distance, by the way, is not always a bad thing since it does give you a perspective of being a service organization serving a service organization.) But don’t forget — the vendors, being commercial entities as well, move to a distinctly different rhythm and set of organizational values. And right now, if you subscribe to Clayton Christensen’s theory of disruptive innovation, they are chasing each other higher and higher up the sustainable innovation line and have surpassed the requirements of the vast majority of their users.
If you are an aspiring student of Christensen’s work with a lot of energy (as I have been accused of having, accurately so probably) then your next question is “What will be the disruptive technology?” followed closely by “Where is the elasticity in this supply chain?”
Ourselves. After decades of rebuilding, there is a growing wealth of talent in our own libraries. The distribution of this talent, however, is different from days of yore. It is not concentrated in the research libraries, and likely never will be again. It is in all of our organizations, in little bits here and there. What will be the blueprint for working together? The philosophies and tools of the open source community. If “real world” individuals and small teams can come together to build great software — Linux, Apache Httpd, Mozilla Firefox, Open Office — what’s to stop us from doing the same?
And you know what? We get to start over. We get to build on the knowledge of our specialized inventory control systems and maybe realize that they aren’t all that different from generalized inventory control systems used in today’s businesses. So maybe we can take one and adapt it to our needs. And maybe we can take a few pages from the electronic booksellers’ handbook, along with a whole ocean of Onyx metadata, and change how our public interfaces operate. (We have lots more to learn from booksellers too, but that is an essay for another time.) And while we’re at it, lets look at Service Oriented Architectures and Java Server Faces and Ruby on Rails and RSS and AJAX and all of those other “Web 2.0″ technologies that are making systems more interactive and usable (when applied the right way). Let’s not strap then onto legacy applications — let’s design with them and their successors in mind.
Where have all the OPACs gone? /
Long time passing /
Where have all the OPACs gone? /
Long time ago /
Where have all the OPACs gone? /
Replaced by us, every one /
When will we take it on? /
When will we take it on?3
Footnotes
- Words and music by Pete Seeger [↩]
- Apologies to Pete Seeger [↩]
- Ibid. Am I allowed to put a hopeful ending on a war protest song? [↩]
2 Comments
Gosh, Jester, I feel like I’m late in coming to the party!
Congrats on putting out some thought provoking commentary. Allow me to correct a couple of points in your history (call it revisionist history if you will). And, yes, we did the end user part last! In fact, I would argue that we still continue in some cases to do that, but that’s another story.
All the programming talent did not leave libraries and go into business for themselves. Certainly some did…although one could argue reasonably well that the transfer of talent was limited to a small number of cases that actually became commercially viable at that time. In other cases, talent from outside of the library world brought resources to bear on the challenges inside of the library world.
In looking back over a history, any history actually, it is too easy to spot themes or structures that may or may not have been at play during the given period. In this case, I think that many individuals, both from within and without the library community were looking for ways to apply the computational power of semi-early modern computing to some very real data management and physical management issues troubling the typical library. As is frequently the case, people at organizations with relatively more resources were up to bat first. We have to remember that in that period computing remained a highly specialized and expensive endeavor.
Yes, as Christensen, whom you quote elsewhere, notes, the 70’s were the decade that included the introduction of the minicomputer. An interesting aside, even by the late 70’s and early 80’s many minis were not all the “mini” nor were they inexpensive!
As for the giving away of code, yes that happened in some cases, but what was given away was also highly particular to a specific library and came with no support or implementation guidance. (Gee, is that any different today? One wonders!) One could argue that this outcome is what led to the commercial viability of the typical library ILS vendor.
There is, however, I believe, a deeper issue, call it the elephant in the living room that no one can discuss. Perhaps in that period of time it was necessary to develop, seek out, or purchase highly speciaized technology aimed solely at the library market…mainly because there wasn’t a COTS option for software that would run on multiple platforms and be adapted to circumstances. It is not productive to fault our fore fathers/mothers in libraryland for what happened in this regard. BUT it laid a foundation of thinking that remains a huge burden today. That is: that all library applications are specialized.
At one time yes, but questionably so today or in the past decade or so. <
Thanks for initiating a discussion a discussion on Christensen.
Actually, what Christensen suggests is -if I remember that right- to do the new, potentially disruptive stuff, but outside the organization. Then maybe later when there is no real market for the old way, the spin-off structure can integrate the old one, while keeping alive both models. Well this is seen in market terms. To some extent, we can argue that even if a technology/or model is only useful to a handful of researchers, it may be very important to support it because it is the core of an institution’s value.
But that also reminds me of a talk at a workshop several years ago on costs of digitization. A speaker stated that her library had to do the old job + the new digitization/digital services one, that costs more money and you have to prioritize. The tension between a traditional conception of the library and a new activity made her wonder whether that was really her job to do that (the user community can be different). She suggested that maybe she should just concentrate on her primary mission and leave the other job to another structure that would have a more appropriate mission, resources and organization. Well, the “all digital” structure model, like CDL or OhioLink (?) could have been a way of doing that. Except that I heard D. Greenstein a year ago stating that libraries and museums had to be in the business of resisting Google’s competition and something like finding niche markets. I could not really find here that an “all digital” library model had any different position than a traditional one. The digital library programs have led to a modification in human resources -I heard a University stating 1 librarian for 3 CS for example. Additionally, new LIS students include a number of students with a CS background and sometimes have a pretty good CS training. All this should make it possible to significantly modify the potential contributions of the library community to less specialized types of applications????
theoretically, “all digital library organizations” should have a different type of staff (like digital library programs) and potentially develop a different culture (less legacy issue here)?
4 Trackbacks
The Library Blogs I Read
Here’s my quick and dirty list of the library blogs I read on a regular basis. I just added Peter Murray’s Disruptive Library Technology Jester, which has to be my all-time favorite blog title, though his tagline is bit odd–Peter’s…
[...] While in UNC-CH for JCDL I’ve had occasion to rant with/at some people about the state of the integrated library system marketplace — including, of course, how we got into the spot we’re in and how we might get out of it (and those people were kind enough to engage in the rant). Along comes a series of posts from Casey Bisson and Nicole Engard ultimately pointing back to John Blyberg’s “ILS Customer Bill-of-Rights” that is singing the same tune. There still seems to be a desire for a solution from an existing vendor, and in fact that was part of counter-points brought up by some on the receiving end of the ILS-must-go rant. (Paraphrased: ‘No one can satisfy the need of a library like a library automation vendor’ and ‘As libraries we’re not strong enough to take on the task of building the next ILS ourselves.’) Yet there does seem to be this mounting pressure to get control again over our data and how we present it to patrons. ¶ [...]
[...] Tom Wilson, Director of Information Technology at the University of Maryland Libraries, LITA past president, and an all-around insightful LITA Top Technology Trendster, posted a commentary to the “Where have all the programmers gone?” post that deserves top billing [1]. Please read and digest it before coming back here. And it’s not late to the party at all, Tom — I believe it is only now just getting interesting. ¶ [...]
[...] here’s the point: I propose that it is further evidence that we need to take control of our destiny. Not to spell out a doom-and-gloom scenario, but there may be a “perfect storm” brewing [...]
Post a Comment