I recently started lurking a librarian coder/hacker listserv (code4lib) and have taken some side-line interest in a Roy Tennant post about a library software manifesto. Essentially, he’s analyzing some of the shortcomings in his experiences between libraries and library software vendors. His library software manifesto breaks it down into consumer and vendor rights and responsibilities.

There are some good things in there, but there are also some “duh factors.” The biggest, for me, being outside of the ILS software arena, is why these points are library software dependent? Many of them: “I have a right to full documentation.” “I have a right to not involuntarily beta test.” “I have a responsibility to report bugs as completely as possible, etc.” are just good software business practices. I realize Roy is a librarian and a technologist, and I understand his audience is librarians, but I think this is an area where libraries need to consider what happens outside of their industry. How does this manifesto hold up against Microsoft updates? Or TiVo? Or Linux? Or so many Web 2.0 applications that are so prevalent these days? Are your needs really unique?

My un-experienced assumption is that libraries are one of those environments where the software is critical to the business function but it’s often purchased/not developed in house. (Also in this boat: PoS/restaurant management software, BBS providers, among others.) This dependence makes the library/ILS vendor relationship that much more tenuous, and libraries are having to compete with information sources that are much more flexible (in house, rapid, targeted development) like what’s done at Amazon, LibraryThing, etc. It almost sound more like my experience with backup software — where the core pieces are purchased from a vendor, but the processes and reports and such that wrap it are in-house. In that respect, I agree that these tools are simply repositories for MY DATA, and I should be able to access and use that data in as many ways as possible (they should not be blackholes for data, or extortion points to get the data out in a way that I need.) But the vendor is only going to get you so far, and eventually you’re going to have to develop on your own some or all of it.

Other points seem petty, and that kind of minutia can really grind down a software product. (This, from talking with Steve, seems pretty common in the library sphere.) You only need read only access to the database if your API functions aren’t good enough to mine the data you need. I don’t know how my TSM database works, but I can “hit” most of it through available tools. Or perhaps people feel jaded by the RFP process — something designed to help flush out available options and make decisions based on key points like those mentioned in his manifesto (if those criteria are important to your organization.)

Another big point is that if you don’t know what you want (which is not uncommon or necessarily a bad thing — many projects I do start out as exploratory efforts to even see what can be done,) you cannot expect a vendor to provide it. The better you define your core processes and requirements (musts, shoulds, wishlists,) the stronger your case will be.

Anyway, I still need to stew on it a while, but thought I’d get a post out there. I’m sinking into a philosophy of agile IT — flexible tools, fast responses, solid services — maybe I should write up that in a manifesto.