Where have all the programmers gone? Taking command of our destiny

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? ((Words and music by Pete Seeger))

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? ((Apologies to Pete Seeger))

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? ((Ibid. Am I allowed to put a hopeful ending on a war protest song?))

The text was modified to remove a link to http://www.theinnovationinsider.com/2006/01/are_librarians_and_educators_a.php on December 31st, 2010.