Mark J. Andrews wrote:
> Brad,
>
> Nice to meet you! I've followed Open-ILS for a couple years now. Can you
> shed some light on your project, namely:
>
> * the problem(s) - without damning anyone or any company, what did and
> does PINES want that commercial systems can't or won't deliver?
Sure, and I will speak in generalities as you suggest. I want to make it
clear that I don't want to frame any conversation as "us vs them". I
have a great amount of respect (and, honestly, sometimes sympathy) for
folks that work for library automation vendors.
First, I believe you have to consider the composition and organization
of the PINES consortium. PINES is governed by an elected committee
library directors from the 44 regional or single-county library systems
throughout the state. They decide on policies and procedures, with the
assistance of central PINES staff.
Under these 44 library systems, we have approximately 250 individual
locations governed under 44 separate regional or single-county library
systems.
Our database is not so out of the ordinary. We have about 8 million
items attached to 1.8 million titles and about 1.6 million active patrons.
However, one thing that I believe makes us out of the ordinary is the
number of cataloging units that are affecting the database daily-- we
have 44 separate cataloging units. (This is a good entry point, I
believe, into the points you were asking about.)
So, our catalogers touch, on average, 5,000 titles on a good weekday. By
"touch", I mean add, remove, edit bibliographic data... add items, etc.
Of course, each touch will require an update to the index. Our indexing
engine does not like this-- and, on occasion, will implode, taking all
CPU time along with it. When the indexing engine vendor was consulted
about this problem, the response was "well, do not use it that way".
Of course, that is not an option for us. We must catalog books to get
them out of the door. So, without going into specifics, we hacked around
and made it work for our situation. It's duct tape-- you'll find a lot
of that here. So, in this specific case, as you can see, it is not
really depth, it is width of activity.
Taking a step back out of this specific example, we want each of our 44
separate systems to manage themselves as much as possible in their
fiefdoms. (and, in some cases, the 44 systems want individual locations
underneath them to manage themselves).
One way to support that is with a granular permissioning system. Users
in Evergreen/Open-ILS are granted permissions in two ways: 1) by virtue
of membership in a user group (that is assigned permissions) or 2) on an
individual user/permission basis.
Further, we have the ability to give a user the ability to delegate a
permission s/he has to a user lower down on the food chain. So, for
example, PINES central will give regional system administrators the
permission to edit the holidays in the libraries in their respective
library systems. We will also give these regional admins the "delegate"
flag on that permission, which will allow them, at their prerogative, to
give that permission to a specific library location manager, so they can
each manage their own library holiday closings.
Taking a step back... most library automation systems support a very
limited (or flat, in some cases) permission and organization hierarchy.
We've build Evergreen to handle many different layers of administration
and permissioning.
Let's take another example. Libraries want to create their own special
shelving locations, and have those appear in the catalog. For example,
we have a library that has a nice garden room that they keep a special
collection in. In most automation systems, if we added that shelving
location to the system, it would show up in every cataloger's interface
throughout the consortium. (there is no better way to rile up a
cataloger than to add to an already long list of shelving locations in
the software, trust me). In Evergreen, shelving locations can be global
(they display in every cataloger's interface in PINES-- we only have 1
like this now-- "stacks"), attached to a system (only display to
catalogers associated with that system), attached to a specific branch,
or sub-branch.
We follow this course in many areas of the software. For example,
catalogers can create local "statistical categories" that they can
attach on to specific copies. So, for example, if they wanted to
specifically track their sci-fi collection (or something that is not
supported by the title-level MARC data), they can do so at whatever
level they have permission without affecting other library systems.
I made the analogy before that PINES is like a big passenger train. Each
library system has sets of cars together, and each library is like an
individual passenger car. At PINES central, we just make sure the train
engine runs, the cars are on the tracks, etc. It is largely up to each
library system and branch to decide what they do in their train cars.
However, with most library automations systems, all of our passengers
would be shoved into one large box car.
I could go on and on, but I think you get the gist of it. We want to be
one, but separate. There is an economy of scale that PINES provides us
as one, but we want the freedom to what we want within PINES policy.
To another facet: availability, scalability, and fault-tolerance are
extremely important to a statewide service. While we present ourselves
as one big server to the world, behind the scenes, we're built on a big
Linux cluster that our software takes full advantage of.
I won't go into the gory details here, but it has been described a bit
in our blog http://open-ils.org/blog. There is one post there that has
pictures of the cluster we're running on. Also look for the OpenSRF posts.
So, really, we have developed an enterprise-grade ILS here. Need more
capacity? Add more nodes. We can switch out faulty equipment without
affecting the live system. We can roll out updates seamlessly to the
cluster. Much more.
Let me stop here. Really. I have a few more pages on the tip of my
fingertips, but I'm afraid I will bore everyone to death.
> * the ability of a given, usually commercial, product to solve those
> problems - Where the problems financial (a vendor could do x, or so they
> claimed, but they wanted a boat-load of money), architectural (the
> commercial product's architecture couldn't support x, or couldn't be
> changed
> to support x in a given time-frame, or for a given amount of money),
> lack of
> interest ("Sorry, we aren't interested in x, go talk to somebody else"), or
> something else?
I think there was a combination of all of the above. Some vendors would
be able to do X by, say, their version due in 2008 or whatever. Some
/sort of/ did some things. Some said that they just didn't foresee doing
X (and we really appreciated those the most-- they were the honest
vendors). Some vendors were openly afraid of us, and told us so up front
(again, we really appreciated the honesty). We were also close to a
situation where another library system contracted for a specific service
from an automation vendor. After a couple of years of vaporware, the
vendor ended up giving the money back, and said "no thanks". To be
clear, this was NOT PINES, and not any vendor we do business with.
Our problems were above and beyond what we felt the various vendors were
up to. (I'm sure some would disagree with me) Besides, the idea of an
open source ILS was tantalizing.
> * changing user needs (and it probably doesn't matter why they change.
> Changing markets? Changing user preferences? Changing technology? All
> three and more) - Now PINES is the vendor. How does your design accomodate
> changing user needs?
One of our developers can probably answer this better than I can-- but
we have built-- primarily-- a flexible and extensible support framework.
Hrm, you know, instead of my trying to say it, let me point you to our
code4libcon keynote:
http://open-ils.org/documentation/presentations/code4lib2006/code4libcon-pines-1.html
and our blog postings on OpenSRF:
http://open-ils.org/blog/?cat=4
I have a feeling that one of the developers will swoop in here to elaborate.
> * the ability of vendor(s) to respond to change - Again, how has PINES
> organized itself to do this?
I think it is important to note that PINES has been a "vendor" in this
sense since 1999. We have 44... errmm... demanding customers. If we
assume that the Evergreen ILS will spread beyond just Georgia, and a
community will grow around it, we're going to have to examine how best
to govern the project. We have talked a bit about it internally, but I
don't know what that will look like yet. Personally, I imagine it as a
benevolent dictatorship, but with GPLS instead of Linus. But, I don't
know what will happen or what form will best suit the need at this point.
> The PINES experience can be a help to everyone interested in NextGen
> products. We are all faced a similar problem set.
Definately agreed.
--Brad
Received on Sat Jun 10 2006 - 14:08:14 EDT