Slashdot Mirror


Librarians Stake Their Future on OSS

Systems Librarian writes "Linux.com is running a story entitled 'Librarians stake their future on open source'. It details a group of librarians at the Georgia Public Library Service that have developed an open source, enterprise-class library management system that may revolutionize the way large-scale libraries are run. The system is Evergreen. The element of this project that has the participants especially excited is the speed. Previously, if users wanted changes to their systems, they'd be put into an 'enhancement queue'. Now, some features are implemented overnight. From the article: 'In fact, the catalog has many features and innovations that are lacking in non-free systems. It does on-the-fly spellcheck and gives search suggestions and adds additional content, such as book covers, reviews, and excerpts. The Shelf Browser shows items ordered along a virtual shelf built out of the holdings of the entire system. Patrons can create bookbags, which are lists that contain a selected collection of annotated titles. Bookbags can be kept private or shared as a regular Web page or as Atom or RSS feeds.'" Linux.com and Slashdot are both owned by OSTG.

13 of 178 comments (clear)

  1. Re:Those Librarians must be gifted! by Timesprout · · Score: 2, Informative

    They didn't. They hired a couple of developers who have been working on building this system for several years now.

    --
    Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
    What truth?
    There is no dupe
  2. Look at the actual system! by Whiney+Mac+Fanboy · · Score: 4, Informative

    Evergreen is available online, have a look yourself: here

    (system seems a little slow already, hopefully this doesn't slashdot it).

    --
    There are shills on slashdot. Apparently, I'm one of them.
  3. A couple of answers from their FAQ by N7DR · · Score: 4, Informative

    I thought that these were interesting items in their FAQ:

            6. What license is this software going to be released under?
            We are releasing this software under the GPL.

            8. What core technologies are you utilizing?

                    * Database: Postgresql
                    * Logic/glue languages: C and Perl
                    * Webserver: Apache, mod_perl
                    * Server operating system: Linux
                    * Server hardware: x86-64
                    * Messaging core: Jabber
                    * Client side software: XUL

    I was especially happily surprised to see jabber there. I have long thought that jabber is vastly underrated and under-used.

    The entire FAQ is at:
        http://www.open-ils.org/faq.html

  4. Re:Postgresql as the database by Snover · · Score: 4, Informative

    For the eighty billionth time, MySQL runs and will continue to run fine on every distro, you just can't buy enterprise support from MySQL AB unless you are using Red Hat or SuSE .

    --

    [insert witty comment here]
  5. A few items out there like this by shoethelinuxlibraria · · Score: 4, Informative

    Also check out Koha, which is going to be launched at the Meadville Public Library in PA early next year, and has been in place in a few libraries throughout the world. It runs natively on Linux... I've gotten it to run on my home box (I am currently doing archives work for a local organization) and I think it holds its own against Horizon, III, Aleph and the big boys of integrated library systems.

    I wanted to try out Open-ILS/Evergreen, but had some issues getting it to run. Granted, I didn't try as hard as I did with Koha.

    In terms of Linux in libraries, there are a few devoted people (and the numbers are growing) pushing for it. I swear, it can not be beat in the public computing arena.

    An open ILS just makes sense. It is easily customized, cheaper in the long run, and really, all the ILS software is served through web pages now anyway. Why are libraries spending up to $10,000 a seat for this stuff? It's the learning curve. And FUD.

  6. I'm Pleased to See the Rollout Went Well by Master+of+Transhuman · · Score: 4, Informative

    I've been following this and other OSS ILS projects like Koha on and off for a while. I was working at City College of San Francisco on the student ID barcode project. That was mostly being driven by the CCSF Library. They hated the long lines every semester when students lined up to get their barcodes manually affixed to their ID cards so they could use the PCs in the library to check email and the like. My boss and I developed a way for the SCT Banner system to produce barcodes directly on student IDs.

    In the process, my boss and I were made aware that the Library was planning to dump their ancient Dynix ILS and switch to a new one. I tried making a case that they would be better off spending the $100,000 budgeted for the new system on developing an OSS one (paying me to do it, of course!) which would give them more control over the result. So I researched a lot of the OSS ILS projects going on. Evergreen seemed very promising.

    The CCSF Library ended up going with a proprietary system - and guess what? They got screwed at least partially. The company promised to integrate the library checkout counter portion of the system with the SCT Banner student database that CCSF uses. This was a requirement and the library put it in the contract. And sure enough, as soon as the money changed hands, the company reneged on the requirement (because integrating anything with Banner is not a trivial task). Some personnel from the CCSF ITS department had to devote considerable time to providing a work-around.

    So I'm glad Georgia managed to get Evergreen out and it seems to be working well, at least from the initial reports. They also managed to get it working fairly quickly as large OSS projects go. I think they were only at it for a couple years. And ILS's are not trivial projects. There are library industry technical standards that have to be adhered to and the end user usability issues are enormous. The acquisitions side tends to be complex (especially on the magazine subscription side), and the MARC record standard is not a simple thing to translate into a relational database schema.

    --
    Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
  7. it's data entry and physical work, not software by SuperBanana · · Score: 3, Informative

    It always annoyed me when public money was spent on proprietary software, especially when there already are free solutions that are more secure and full featured.

    This is irrelevant. There WAS no free, more secure, or full featured solution for library management.

    Nevermind that most of the cost, at least initially and for the first few years, is NOT the software. About a decade ago when my school went to a computerized system, the cost was mostly in labor.

    • The entire card catalog was boxed up and shipped to a company for either data entry or OCR, I don't recall
    • Every single book was pulled, barcoded, and had an anti-theft strip (which could be deactivated) inserted into the binding

    I don't recall how they managed to link barcodes to books; whether each book was pre-assigned a specific barcode, or barcodes were applied and the system brought into sync via hand entry.

    This process took MONTHS and the work of several librarians and the expensive data-entry company.

    I can imagine scenarios where you could get 2 dozen volunteers and go shelf by shelf through a library and catalog the collection, but it'd still be a massive undertaking, even for a small library such as one in a high school.

    Your only hope is aggressive use of laptops on wireless with barcode scanners, and an ISBN lookup database you can pull, quickly verify the basics, and toss the book on the shelf again (in the proper order.)

  8. 25 years ago... by John+Hasler · · Score: 2, Informative

    My wife (a retired library science professor) wanted to do this 25 years ago. No one was interested.

    --
    Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
  9. Re:Scalability by Anonymous Coward · · Score: 1, Informative

    The system currently supports over 250 libraries and over 8 million books. I'd say so. ;)

  10. Evergreen by Anonymous Coward · · Score: 1, Informative

    The software used at the library is Evergreen.

    http://en.wikipedia.org/wiki/Evergreen_(software)

  11. Re:Postgresql as the database by swillden · · Score: 2, Informative

    MySQL runs and will continue to run fine on every distro, you just can't buy enterprise support from MySQL AB unless you are using Red Hat or SuSE

    WRONG! The update added to the summary of the slashdot article that first spread the erroneous meme that you were reinforcing (and which was further distorted into the even more erroneous notion that you were "correcting"):

    MySQL AB's Director of Architecture (and former Slash programmer) Brian Aker corrects an apparent miscommunication in a blog post: "we are just starting to roll out [Enterprise] binaries... We don't build binaries for Debian in part because the Debian community does a good job themselves... If you call MySQL and you have support we support you if you are running Debian (the same with Suse, RHEL, Fedora, Ubuntu and others)... someone in Sales was left with the wrong information"

    Bottom line: You can buy and receive enterprise support from MySQL AB, even if you're not using Red Hat or SUSE.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  12. Million is a rather small number for RDBMS by Anonymous Coward · · Score: 1, Informative

    A million artifacts in the circulation database is not a large number for any modern relation database management system like postgresql or mysql. Evergreen uses postgresql and can handle that. A lot of the proprietary databases sellers do however try to create a fair amount of fear uncertainty and doubt in that regards. So that aspect of scalability is a non-issue.

    A more relevant question is what kind of user load can it handle. I've seen proprietary integrated library systems which take about two minutes to answer a query when there are more than a half dozen users at the same time. Yeah. And that system was the latest and greatest and cost big bucks, too.

  13. Vendor lock-in vs. good customer service by DenialS · · Score: 3, Informative
    I'm a systems librarian, so I claim to know of what I speak.
    Most of it shouldn't even need to be converted. It should be in MARC Bibliographic format, which is generally fairly easy to transfer between databases.

    This is true, as far as the bibliographic information goes. There are lots of open-source packages for working with MARC records, like pymarc (Python) or File_MARC (PHP). But the rest of the system is proprietary: holdings records, (which copies do you hold, in which locations, and where is that copy currently - loaned out, lost, on reserve, etc), circulation records, user records, acquisitions records. Sure, it's all just a database schema mapping exercise, if your vendor's license allows you to touch that data directly. Sadly, the past generation of libraries seems to have accepted vendor lock-in as a matter of course; a mistake that we're paying for now and which led directly to the development of Evergreen.

    But really, let's be realistic. The major OPAC package is Voyager, which runs on top of Oracle, so runs on anything that runs Oracle. Libraries that don't have Voyager are pretty much all just wishing they could afford it (and the Oracle licenses).
    Wow. This is just so wrong that I don't know where to begin. First, Voyager is far from the market leader (in either usable interfaces or in market share). See Second, the underlying database doesn't mean a thing if you aren't given the APIs to actually modify or extend your primary application, unless you're willing to reimplement the entire application -- in which case, why bother paying for a library system in the first place. And in most cases, when the vendor has made an API available, you have to pay extra fee per potential developer to receive the documentation and to be eligible for paid support for their API (which, of course, is an additional support fee over and above your standard support fees). Third, most librarians I know couldn't care less about what technology their system is built on. They're focused on providing the best possible service to their users. Over the past few years, the library community has started to realize that there are some pretty cool Web interfaces out there in the wild that their vendors aren't providing for us. So we've been going through exercises like NCSU's use of Endeca (on the proprietary side) and Koha, Evergreen, and WPopac (on the open-source side) to try and correct the situation. Librarians rock, you know.