‘Tis a far, far better thing I code.
I mentioned last week that there is a disparity between libraries that code (or have coders) and those that don’t. Since then, several people have examined whether a resident developer is a prerequisite when shepherding your organization into the library 2.0 world:
Travis Ennis writes:
Not all libraries have the good fortune to have these kinds of people on their staff, so what kinds of communities will emerge to develop and share these applications?
Lib 2.0 writes:
Let me also say that it is not merely the existence of coders or big budgets which separate the haves and the have not’s. There has to be a fundamental attitude and a willingness to change, so when your hacker comes up with some crazy idea, there are a whole bunch of people who are excited about making it work, willing to promote it and test it and document it and train people about it. Just hiring someone who can program, no matter how brilliant, is only a small part of it.
As you might imagine, I’ve got some opinions on the matter. Before I can address the question of coders in the library, however, I need to revisit my thoughts on vendors, and how better to do that than to respond to Talis’s Richard Wallis. Richard wrote a response to my “Road Ahead” post in which he talks about “Orchestrated Library Services” as a framework of tools to enable non-technical staff to produce a constellation of integrated services via the presentation layer. In my post, I stated that there was a disparity between libraries with coders and libraries without coders. Richard writes:
So what is the solution to this technical apartheid – a coder for every library? With today’s technology, where an understanding of SQL, database schemas, and programming languages is required, probably yes but that is impractical on anything but a small scale.
First, I don’t consider the disparity between the have-coder’s and have-no-coder’s an apartheid–it’s a resource problem. The solution to which is to either hire interested coders, or find someone in your organization who has an interest in coding and foster their desire. I’d beseech libraries not to agree with Richard when he says that having developers on staff is “impractical on anything but a small scale.” Yes, in a Library 1.0 world, an emphatic NO in an L2 environment (btw, I tag/categorize my posts with “Library 2.0″ for the technorati’s and use the shorthand L2 because it seems to not overwork the term). For medium-to-large size libraries, having a developer on staff is just part of the L2 face and shouldn’t just be considered a luxury. We need to accept that, and get used to it because it’s just part of a larger strategy by which libraries take back the creative development process. I’ll say it until I’m red in the face: if we want to be pertinent, the curent model needs to change. The model that we should be adopting looks more like a meta-coop in which libraries work together via a developer’s network using a set of platform independent, standards-based tools to create open-source projects, programs, and snippets. That is the real Utopian vision.
But, what if configuring and orchestrating web services became as easy as it now to produce a web page? And, what if the web service based library services supported by library system components became as ubiquitous and standard as say HTML is now? And, what if the tools to do the orchestration became as easy to use as say MS FrontPage [no recommendation as a tool, just an example]. Would, in that situation, the librarian orchestrating his/her Library’s service to its customers need to be a coder? No more than they would, to be able to put a Word macro together today.
I see a couple problems with this idea.
First, in order to make such a tool usable to the average user, it would have to be severely limited in scope. To incentivise librarians to use the tool, it’d have to be somewhat simple and intuitive. It would be a major challenge to create a simple, easy-to-use tool that can “orchestrate” services at any great level of complexity.
Second, the services we’re talking about are far more complex than html. You can’t even compare html to web services/APIs. HTML is a very simple language that is parsed and presented. When you start introducing complex data sets, you’ve increased complexity by an order of magnitude. There is very little you can do to simplify the process at that point, especially when it comes to debugging and pinpointing the data you need inside a data set.
Third, it’s one more third-party, proprietary tool to learn. Library staff struggle enough with the actual administrative interface of an ILS, giving them another tool to learn is not going to make them very happy. It’s much better to make business logic ubiquitous and present it using developer lexicon.
Fourth, it adds an extra layer to the development model we’re asking for. This seems like an unnecessary “middleman” when it comes to development.
Finally, like I’ve said before, there is no way for vendors to anticipate every need of every customer. Are vendors going to develop software to integrate and manage patrons’ wireless devices? Are vendors going to develop an integrated game tournament system? Will they write a module for every CMS on the market so that it can be integrated into the ILS, or will they just write their own CMSs and expect us to use them?
Vendors need to stop assuming that they know what we want better than we do. For instance, find me a single library coder who does not want read-only SQL access. We’re telling you want we want. If you want to know what will drive a library coder to coffee in the morning, it’s the spectre of non-technical staff believing that they can hack together a “Library 2.0″ site on their own because they’ve been sold a bill of goods that tells them they can.
This leads into another topic I touched on in my post when I pointed at our own institutions as barriers to change. This is a component of Library 2.0 that vendors should not be addressing because to do so would be placing undue influence on fundamental policy shifts that need to take place inside our institutions. Yes, libraries are experiencing internal struggles as these changes unfold, but these are struggles that vendors have no right to be a part of.
Not only have us vendors got to get our act together in delivering the Library 2.0 technology in a way that fosters and enables the emergence of new processes and new ways of interaction between libraries, between libraries and associated institutions & commercial services, and between libraries and the consumers of their services; but the librarians in, at least a significant proportion of, those libraries must be ready to take their services in to the Library 2.0 world and most importantly understand why they should.
That’s part of our struggle, yes. But as I wrote in a previous post, L2 as a concept is still in it’s infancy. It’d be irresponsible for vendors to ramp up their marketing engines with a sight toward L2–especially since L2 is such a nebulous group of ideas. Yes, libraries have people who still want the card catalog back, yes we have non-technical people making technical decisions, we certainly don’t have a mandate to start implementing all these wonderful changes. All of this needs to be worked out, and while that is happening the best thing for vendors to do is reevaluate their client relationships, take Occam’s razor to their software, and work with library developers to come up with a standard framework of open standards and vendor interoperability.
I wanted to revisit the vendor issue from a different angle because it provides a context within which to consider the purpose of coders in libraries. Maybe a non-techie will disagree with me on all this, but I believe that it should not be the non-techies’ job to make technical decisions. All of this brings me inexorably toward the million dollar question: should all libraries have a coder on staff?
If you look at a product like WordPress (much simpler than an ILS, granted, but the model scales), you’ll see that you don’t need to be a programmer to use it. Anyone, with a little time, can install WordPress and start blogging. But many of the really great WordPress sites are those that have been heavily customized and there are a large number of “contribs” (contributed code in the form of plug-ins) that made WordPress such a hit. In the current L2 landscape, you won’t need a coder to have a good online presence, but you will need one if you want a great online presence.
Ultimately, MLS programs are going to have to start offering CS electives and eventually requirements. The profession itself is changing with the industry. Databases and networks, increasingly, are information’s domain and if we want to be part of the vanguard, and if we want to call ourselves the stewards of that information, we darn well better know how to work with it. So to answer my own question, I’d say that libraries should strongly consider having a coder on staff. In five years, there’s no question, you will have a coder on staff or you will be considered quaint.
Let me just give a few examples of how coders are influencing the work going on at AADL:
I released my php xmlopac class for III, and Casey Bisson contributed two very useful functions. Casey’s contribution inspired me to make public a bit of code to access and cache amazon images. This, in turn, caught Chris Deweese’s attention who is now working on an ASP derivative.
I received an email yesterday from Ed Vielmetti who just wrote an AADL search module for duckytool using the RSS feeds I implemented last month. He’s requested microformat output from our catalog to extend his tool, and I think it’s a great idea.
DaveyP just announced his plans to work on patron catalog tagging–a project I’ve got my sights on for AADL. He’s going after it with the energy of a terrier and has an idea for a cooperative database of tags. He’s sharing his code, too.
Do you notice a pattern? Often times one bit of work spawns another, and so on. This type of collaboration is only going to proliferate. Make it a mantle-piece of library 2.0. This stuff is happening in the coder’s workshop, it will do your institution well to take notice. It’ll do you even better to take part.
About this entry
You’re currently reading “‘Tis a far, far better thing I code.,” an entry on blyberg.net
- 12.20.05 / 12pm