Yes, it's time for the Dis-integration of the integrated library system!
Talk to any librarian who has recently gone through an RFP process to buy a
new system and they'll all tell you that they wish they could have taken
the serials control from vendor A, the acquisitions module from vendor B,
and the cataloging interface from vendor C. Notice I didn't mention the
OPAC? As far as I can tell, and vendors have confirmed this for me, no one
picks an ILS based on the OPAC functionality and vendors know that the OPAC
is not going to sell their system. The result is that library users get
short shrift in terms of features and service.
Components of course need interfaces to each other. "Innovative Interfaces"
got its start by providing an interface between the library cataloging
module and OCLC. It was, literally, a black box. Z39.50 serves as an
interface to the catalog (yep, although imperfect) and OPACs can be built
that talk to any library catalog with a Z server. What we need are not
better ILSs but more and better interfaces.
At 11:22 AM 5/6/2003 -0400, Rhyno Art wrote:
>As long as a large-scale ILS remains a monolithic application involving
>thousands or millions of lines of code, then I suspect it will be an uphill
>battle to get library decision makers to invest in OSS. At the very least,
>there will be a fear that the code base will be too large to sustain itself
>even with the amount of communal maintenance and nurturing that libraries
>could collectively contribute. A worldwide community of developers can be
>galvanized to tackle an operating system or an office suite, but the
>numbers dwindle pretty fast when you start talking about MARC editors and
>Serials Control. In other words, we are still a pretty small bunch when it
>comes to this kind of system.
>The question I have is whether monolithic applications have to be the only
>answer for every kind of enterprise system. I have rambled about this at
>/usr/lib/info concerning ERP, but the ILS vendors are way behind in
>component-based computing and utilizing mainstream software. I find it
>extremely interesting that Sun's latest paper on Digital Libraries points
>out that the commercial ILS solutions are lagging on this front. Sun is
>very good at promoting commercial ILS options because, for the most part,
>they seem to prefer Sun hardware, but other somewhat comparable systems,
>like in the banking and insurance industries, are knee-deep into
>component-computing. The fact that Sun would even recognize that commercial
>ILS vendors need to get into this environment speaks volumes to me.
>Not that I don't doubt that a million-line OSS ILS could be built for the
>million dollars they cost on the marketplace, I just question whether a
>self-authored million line system of any kind makes sense any more. This,
>in fact, is where I see the most hope for OSS for large library systems,
>because I don't think the ILS vendors' business models are ready for using
>mainstream components and it's conceivable that OSS approaches could
>leapfrog over them. Remember, it wasn't that long ago that universities at
>least, did build million line systems through consortium-based software,
>and there was a great turning to the marketplace in the 80s when it was
>realized that they couldn't easily keep them running.
>Let's take the module that has come up here and that ILS programmers
>probably fear the most, Serials Control. Any one who has slogged through
>programming a Serials Control module will probably tell you it takes very
>intricate business logic and all sorts of weird time-specific pattern
>matching algorithms to handle predictions on when issues should arrive.
>There are mature OSS component container systems like JBOSS that provide a
>framework for plugging in general purpose building blocks which might be
>able to do most of the heavy lifting. If you used JBOSS with OFBiz (an OSS
>component for handling business logic) and an OSS calendar server (for
>handling predictions), how close would you get to a viable Serials Control
>system? My sense is that the target would become much more achievable
>because a lot of that million lines of code that runs underneath it all has
>suddenly been contributed by other programmers who wouldn't, and don't need
>to, have a clue what a MARC record is about.
>Make no mistake, it would still be a lot of work, and as Eric points out,
>we all have our day jobs, but what I find the most interesting about the
>University of Saskatchewan document is not the cost of the upgrade, but
>their compelling description of what an ILS in 2003 needs to be able to
>accomplish. Even the library vendors are finding it hard to maintain the
>ILS as both a purchasing and inventory control system while at the same
>time trying to keep up with what the users expect and want when they
>interact with systems on the web. Eric Raymond talks about the benefits
>of "constructive laziness", maybe the trick is find similarities in other
>applications and use component models to employ them for library systems. I
>suspect we would still need to dump some day jobs to make this happen, but
>the needs of the user community may be what it takes to push some
>organizations to invest in this.
>Or, like the use of relational database behind commercial ILS systems, the
>vendor community will eventually get there by themselves. Our advantage is
>that we can use some great OSS building blocks because the licensing
>doesn't hurt our bottom line. The trick is probably to find a way to
>leverage this advantage.
>Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
>The only event dedicated to issues related to Linux enterprise solutions
>see also http://oss4lib.org/