Personally, I would hesitate from the get go to design a full-fledged
integrated library system, and instead I would advocate and encourage
the creation of small modular components of an integrated library
system allowing a thousand flowers bloom.
An integrated library system is akin to a computer operating system.
In both cased they are intermediaries between people and things. In
the first case they are intermediaries between patrons and libraries.
In the second, they are intermediaries between people and computers.
Additionally, in both cases, each thing (the ILS and the operating
system) are really a conglomeration of many different programs
forming a coherent whole. (Well, much of the time.) The process is
huge. Just look at Microsoft Vista or the various flavors of Linux.
This being the case, I would not go about trying to build an entire
operating system nor an ILS. Rather, I would go about building
particular parts of the system I thought needed fixing the most. When
building such things I would strive to keep three things in mind: 1)
make your programs do one thing and one thing very well, 2) make sure
your computer program works well with others, and 3) use plain text
as a way of communicating between programs since plain text is a
universal data format.
1. To elaborate, do one thing well means don't try to be all
things to all people. No Swiss Army knives. For example, write a tool
that creates MARC records (or whatever). You will need an editor. Let
a thousand flowers bloom. There may be many. The one(s) that work
well for most people will be the ones that ultimately get used. You
will need to support search. Find an indexer. Exploit it. When
another one comes along that works better, then go with it. If you
want to support circulation, then you will need a tool to import
information about patrons, import information about inventory, and
finally make relationships between them. Such a thing can be done in
a host of ways.
2. In the Unix/Linux world, "Make sure your computer program works
well with others" is often interpreted in as meaning, "Support the
things like 'standard input', 'standard output', and 'standard
error'". Maybe the keyword here is "standard". Like someone said
previously, try to implement things against standards and do not
implement "-isms". When you say you output MARCXML, don't add your
own elements. When you say you implement Z39.50, don't necessitate
your own extensions. Such implementations make migration process more
difficult for everybody, developers and users. There are quite a
number of standards we can work with in Library Land. Standards for
thesauri, circulation, data formats, and search. Build on them.
3. Finally, use plain text. Binary data is bad. It is very hard to
read without specialized programs. Plain and simple.
With these engineering principles in mind -- often called "The Unix
Way" -- it is easy to build modular applications supported by a
network of loosely connected individuals or groups. Such a principles
are flexible and adaptable. They lend themselves to very well to
large scale projects where there is no centralized leadership.
Which brings me to my last point. Many computer programmer types,
especially the ones in the open source world, consider the product of
their labors to have artistic characteristics. Software should not
only be functional and practical, but is can also be beautiful. They
tend to be puzzle-solvers and people who enjoy a challenge. They tend
to be craftspeople who enjoy the entire process from the articulation
of the problem, the outline of a solution, to its actual
implementation. If libraries are to take advantage of these skills,
then everybody needs to be talking. Don't hand programmers a set of
specifications and say, "Implement this." Such a process won't
motivate anybody and will probably result in bad code.
--
Eric Lease Morgan
University Libraries of Notre Dame
Received on Wed Oct 24 2007 - 17:05:14 EDT