[WEB4LIB] Re:will OSS impact library automation?

[Rhyno Art]

> 
> At 11:01 AM -0800 22/3/01, Eric Hellman wrote:
> >Obviously, he doesn't mean to say "Perl will not have a huge impact 
> >in library automation" but rather something like "Don't expect to 
> >see gnuOPAC anytime soon".
> 
> Amongst other things there is http://osdls.library.arizona.edu/
> 
Since I am involved in the system at this site and have spent more time
than I can calculate chasing Open Source ILS solutions, I wanted to echo
and add to a few points in this discussion. Part of the problem, as has
been pointed out, is that a large-scale ILS is a huge target. An entire
community of developers may be galvanized to build the world's next great
operating system or spreadsheet, or almost anything else that Microsoft or
whomever actively markets and profits from, but far fewer developers are
interested in creating an alternative cataloguing editor or library
circulation system. A commercial ILS vendor has to throw significant
resources towards the pool of developers that are needed to make an ILS
tick in what is a relatively small market in terms of the software world.
Hence, library systems are not cheap, and, compared to many of the owners
of high tech companies at least, ILS vendors are not particularly rich.

That being said, I think OSS solutions for a large scale ILS will become
more feasible as the toolkits for wiring together large systems become more
accessible. The architecture for the system at OSDLS uses Enterprise Java
Beans (EJB), among other tools, because it provides a framework for
handling the details of managing transactions, threads, and load balancing
on the server while allowing developers to concentrate on business logic
rather than the low-level intricate system details. The advantages of this
approach are hotly debated, and like all promising technologies, the
promise is a little farther away than the implementation at this point (:-,
But at least two major benefits of this approach are that you don't need as
many developers and the ones that you can draw on can spend more time
concentrating on the overall design of the application. Again, this is for
large scale systems, PERL & PHP and all the other tools that work real
magic on a Linux machine are more than up to many of the computing
challenges that libraries face (in fact, I am in the second month of a
trial with an OSS PC booking system built with PHP and MySQL, and I would
argue that these technologies are perfectly, even elegantly, suited to the
task).

One of the strengths of EJB and other middleware/component-based solutions,
and for that matter, many XML-enabled technologies, is not only that they
open the door to using a combination of both OSS and commercial building
blocks, but also that they allow for the possibility of systems that don't need
to be constructed by one person, company, or organization. For example,
tying a general ledger program from IBM into the library's financial
system, or using a commercial LDAP setup for patron records, or using an
XML editor/word processor to modify bibliographic records, or whatever
other mixture of components creates the most compelling combination. If the
availability of a large scale OSS ILS is dependent on the library
community's ability to communally author the million or whatever lines of
code that sit under most full-blown ILS options, then efforts to muster the
resources to make it all happen and to keep it afloat will probably make
most library administrators nervous. But a key question is whether a
significant percentage of that intellectual property already exists,
regardless of whether it is built in a cathedral or a bazaar. If some of
the building blocks are already out there then libraries can take some
comfort from the fact that even organizations with deep pockets for
technology are pushing for better ways of gluing it all together. 

Unfortunately, we are not quite there yet and melding all this into a
coherent system is still a big challenge, but initiatives like the JA-SIG
(Java in Administration Special Interest Group <http://www.ja-sig.org/>)
and the Keystone Principles
(<http://www.oclc.org/institute/keystoneprinciples.htm >) give me hope that
the right balance can be found between library support for OSS development
and enlisting existing technologies to build an ILS that is flexible and
scalable. I think there is a tendency to view OSS as appropriate for small
to medium sized systems that rely on scripting languages and the amazing
efficiencies of Linux on low-cost hardware. But Open Source is also about
choice, and modern software environments may make it possible to enjoy a
collaborative environment and to re-use and "share" software in a manner
that was difficult to imagine in the bad old days of spaghetti code. Linux
benefited greatly from the tools constructed for BSD, and as Eric Raymond
points out in "The Cathedral and The Bazaar", part of the genius of Linus
Torvalds, the creator of Linux, was in his ability to find the minimal
effort path from Point A to Point B. There is no doubt that a large scale
ILS is hideously complex, and binary reuse of applications has always been
seen as one of the elusive holy grails of software design, but don't
underestimate the possibilities of tailoring mainstream components to do at
least some of the job for an OSS ILS. Such an approach may be enough to
push it into reality for even the biggest and most demanding library
systems.

art
---
Art Rhyno, Systems Librarian
Leddy Library, University of Windsor
Internet: arhyno at uwindsor.ca
Tel: (519) 253-4232, EXT. 3163
FAX: (519) 973-7076
WWW: <http://www.uwindsor.ca/library/leddy/people/art.html>