Brad, I was impressed with your presentation. Continued best wishes with
Evergreen and the rest of your PINES endeavors.
Hopefully, I can meet up with some of the PINES crew in New Orleans.
Ed Trever
Lincoln County Library Director
306 W. Main St.
Lincolnton, NC 28092
(704) 735-8044
Fax (704) 732-9042
----- Original Message -----
From: "LaJeunesse, Brad" <bradl_at_GEORGIALIBRARIES.ORG>
To: <NGC4LIB_at_listserv.nd.edu>
Sent: Saturday, June 10, 2006 2:06 PM
Subject: Re: [NGC4LIB] The origins of Open-ILS
> 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 Tue Jun 13 2006 - 19:28:49 EDT