When you pay someone to provide you with the software you need, you enter into an agreement with them. “If you install this software and provide us with tech support,” you say, “we will pay you for the software and for a support contract.”
However, those agreements also come with baggage. When you buy a solution, you’re lashing yourself to the vendor’s development cycle and you’re trusting that the software they provide you (both in the short term and over the length of the contract) will meet your patrons’ needs. You’re also betting that when you need to add a new product or service to your repertoire, that piece of software will either do what you need or will integrate well with another piece of software that does what you need.
Relying on vendors for your software is a decent short-term strategy, since it lets you get up and running quickly and provides a dedicated support channel when things go wrong. Over the long term, though, it causes stagnation: if your patrons want or need something new, you can’t provide it to them without waiting on your vendor, shelling out more money for another product… or both. And if your vendor discontinues a product or even just decides that what your patrons need isn’t in their interests, you’re left out in the cold.
For example, I know of a library whose content management system is not only no longer developed by the vendor, but hasn’t even been *supported* by them for several years. That library hasn’t upgraded or switched to a new platform, because doing so would require them to negotiate a new contract with a new vendor. With money so tight these days, many libraries (including my own employer) are seeing dramatic reductions in funding; as a result, that library system is stuck with a dead-end content management system for the foreseeable future.
**Libraries need more coders.** I’m not talking about “that guy in the office who knows HTML”, but *real, honest-to-goodness coders*, who can build a custom solution for your library from scratch. There’s no reason your library can’t have [a search system that includes your research databases](http://bitsandbooks.com/2009/11/the-smart-firehose/ “‘The Smart Firehose’ at Bits and Books”) or build its own app for the iPad. Building your own solution means you can innovate at your own pace and you can meet your patrons’ specific needs.
In fact, programming should really be a track in library school, because **programming skills allow people to build their own solutions**, which is a big part of what libraries need to stay relevant in the age of the iPhone. Lots of Library Science programs teach students HTML (a nice start and certainly better than nothing), but librarians are supposed to be experts at dealing with information, so why aren’t library school students being taught to do interesting and useful things with that information in a digital setting? Why aren’t library school students being taught how to write a web app in Rails, how to do version control with Git and how to get an open-source project off the ground?
The emergence in the last few years of the mobile information market has been staggering. Ever since the iPhone, iPad and Android revolutionized the way we view our mobile devices, there’s been a tsunami of development in this market. Everyone’s rushing to build apps and mobile-friendly versions of their websites. Libraries are a natural fit for this world, since we curate large amounts of quality info and we are seen as trustworthy by the public at large.
Libraries can’t wait a year or two for their vendor to deliver an iPhone app or a mobile website. The future is here – *right now* – and any library that isn’t trying to deliver its services to patrons wherever they are (especially on their mobiles) is merely contributing to the view that they are merely relics of a bygone era.