Commercially available library software that is actually used by libraries is much more than just a cataloging/look-up system to replace those old 3*5 cards.

You need an acquisitions module that has the ability to do electronic ordering and approval plan processing.

The search and report capabilities on the staff interface for these things is amazing. I can collect a list of all item records belonging to location X and created within [ range of dates ] that are attached to bibliographic records for [ material type ] within a [ call number range ], sort the records according to my criteria, then output selected fields from either the bib. or the item, or both, in the order I choose to the device of my choice (including print to e-mail or fax) and I haven't even begun to make the system sweat. Yes, this is a fairly straight forward thing to do (selecting records based on data spread across multiple related/linked records) in SQL but, you also need a front end that the end user can comprehend.

If you're going to code it, it will need to be able to interact with all of the prevailing vendors... Ebsco, Baker & Taylor, Basil Blackwell, Swets & Zeitlinger, Matthews, etc... You will want tech contacts from each of these vendors to fine tune the ordering/receiving/approval interfaces.

Finally, the amount of fiscal reporting done in libraries can boggle your mind. You would never suspect that something so seemingly simple could be so complicated. If you don't have the ability to generate financial reports you might as well go back to index cards and hand written ledgers.
"Spoooooooon!"

Second is that half of the pieces that go into a big library management system (including the catalog part) are really generic business systems: EDI, invoicing, accounting, etc., but they haven't been abstracted out of the realm of our systems vendors. So the level of standards followed there is minimal so those modules generally don't interoperate with our trading partners (i.e. internal payment systems and external suppliers). Lots of redundant keying and more crappy systems to maintain there, all of which is typically deeply and proprietarily tied into the catalog data.

All that said -- and to our vendors' credit they are tending to get better these days -- we've been sharing catalog data like hackers are sharing code for over 100 years. We've been doing it online for about 35 years, but the way we do it now is pretty much the same way we've been doing it for those 35 years. i.e. largely dependent on one of two .orgs/vendors to be a clearinghouse for sharing catalog data. But those folks disappear if they can't sell the data back to us after we create it for them. So nobody running a library wants them to disappear. Especially because we've got to handle one-of-a-kind rare items in big research libraries as well as unusual local items in public libraries and so on.

Imho the solution is to first outsource all the standard business stuff to vendors+free software that can do the same job with existing standards-based tools. Then abstract away as much as possible of the catalog data into free references sources shared and maintained by the library community (think: you could run your own amazon.com recommendations site, etc.). This is what we're trying to do (shameless plug alert) with the jake project for journals. Same thing applies for books, although there are probably >=100M records to normalize.

If we can get that done, then anybody could hack up a gtk+ front end to the free, shared catalog, and pick and choose the items you have yourselves. It would work sorta like dict.org or jake. Just imagine how much easier it will be to search for ebooks in gnutella once this is done... :)

While most people would tend to think this is a fairly simple endeavor, it's not. Our consortium runs a library automation system on top of VMS on an Alpha cluster. It happens to be one of the best systems out there as far as high availability is concerned. However, it still doesn't take user's needs (Ref. librarians and patrons) into account.

If something like this is going to work, you have to anticipate what your users are going to be asking for. A simple cataloging system could probably be done with MySQL or Postgres, but it will lack any of the functionality that is in existing library catalog products.

In addition to the MARC records, you would eventually need to maintain a patron database, an acquisitions database, a record maintenance interface, circulation records and policies, etc... AND it would all have to be easy to use for a non-technical person. Even the system we use is not "easy" for the average user, it's jst reliable.

Personally, I would love to see an open source and/or free software catalog system that outshines systems like Dynix and DRA. Especially if it brings user interfaces into the year 2000. (There is plenty of talk about new client server interfaces, but nothing has come to fruition as of yet.)

I think the biggest challenge a project like this would face is that programmers are not librarians and vice-versa. They come from very separate worlds and have very little understanding about what the other discipline finds important in an automation system.

Peace,
D.B.

Don't complain about my web page. It's mine. ALL MINE.