[OPEN-ILS-DEV] import data from voyager - wiki documentation

[arhyno at uwindsor.ca]

> Based on my gut feeling, not very scientific I know, the current code 
> base coupled with the sheer amount of installation issues people report, 

> does give a bit of a "ducttape" feeling.

I think it's important to remember that Evergreen was developed for one 
very demanding, and time-constrained, situation first, and is in the 
process of expanding to other sites now, rather than having a wider base 
at the start. This is a good thing by many measures, not the least of 
which is that it verifies production-readiness at the outset. It does have 
the consequence that there is a lot of ground to cover for anyone starting 
from scratch. I used to participate in a group known as the SPIRES 
consortium, a collective headed by Stanford University that took its name 
from the system that Stanford built for its internal operations. SPIRES 
was way ahead of its time, but it took a while to develop the structures 
that allowed other sites to run with it quickly. I like the fact that 
Evergreen uses a number of technologies and, as Dan has pointed out, is 
using a mainstream messaging system. I totally agree  with Dan that 
picking Jabber is a brilliant design move, and brings in a wealth of 
expertise and options as a result. 

But even outside of this, the ILS landscape is not exactly loaded with 
options, and I would argue for the scale of operation that Evergreen can 
support, it doesn't have a lot of peers, if any. I think the state of 
documentation and ease of installation is not a weakness as much as it is 
a consequence of a complex system starting to find traction in new spaces. 
I know you don't mean this, but I tend to use "ducttape" in the "Red 
Green" sense, as a way to arbitrarily bring together disparate things in a 
fragile way. Whatever Evergreen is, the selection of technologies 
represent a lot of "best of breed" decisions, and the variety is to 
improve the overall strength of the system at the expense of making it 
simple to deal with for installation and configuration, rather than the 
other way around. If you are dealing with a busy system, this is exactly 
the trade-off you will probably prefer when the traffic on the system 
reaches its peak. That's not to say that Evergreen can't be made easy to 
install or should not have good documentation, but this is going to be 
harder to achieve with a system that can handle the circulation demands of 
255 libraries rather than, say, OpenBiblio or whatever, and I thank the 
net gods for those systems too.

The difficulty with technology is that pronouncements are rarely followed 
by verification. One simple "I hear it's hard to install" or "it's not 
ready for prime-time" can be the kiss of death around a library 
decision-maker. And it's not just libraries, I own a newspaper and I see 
technology decisions made all the time with the thinnest of reasoning. I 
don't know what the solution to this is, or even if it can be solved, but 
it reminds me of those church recruitment posters that seem to say "there 
better be something out there or it's a pretty scary world otherwise". 
Evergreen is tackling the massive scalability issue head-on, and I think 
it can shine at the metrics if a realistic scale is used. 

art
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20070525/7c4d2523/attachment.html