[OPEN-ILS-GENERAL] Introduction (Re: 226 subscribers) and Some Questions

[Jason Etheridge]

On 3/28/07, Karen Collier <kcollier at kent.lib.md.us> wrote:
> I've enjoyed reading about the backgrounds of all the other people on this list who've responded before me.  Now, I guess it's time to introduce myself.

Howdy!  I'm going to try to answer some of your questions...

re: installation documentation
>Is there any further documentation elsewhere, or are there people
actively involved in updating this documentation?  I would be more
than happy to help with writing up documentation... if I knew how it
worked and what needed to be said in the documentation...

The documenters and the ongoing activity (people working out
installation issues and reporting successes) can be found on the
OPEN-ILS-DEV mailing list that compliments this one.  We also have
folks on the IRC freenode network in channel #openils-evergreen

The docs really do need to be wrestled into something cohesive, and
we'd welcome any help we can get.

> So now, I'm wondering, how can I help with this project?

Just asking questions is a great start!  Installing the software and
filling in the holes in the installation docs would be very useful for
enabling others to get involved with the project.  If you're familiar
with wikis and would like to help out with it, just hollar at us
off-list at feedback at open-ils.org and we'll get you an account.

> Can I help with documentation?

More cohesive and complete documentation would be wonderful!  You have
the technical side of it (administration, development, deployment,
installation), the user side of it (patron, staff, admin), and even
such things as features analysis, high level overviews, advocacy,
critiques, etc.  Screenshots, videos, translations.. all sorts of room
for help there.

>With programming?

Most definitely.  There is a learning curve for getting the whole
picture, but that's not stopping folks from focusing on bits and
pieces.  For example, one of the very first pieces of feedback we
received (over a year ago) was on how to better use CSS (thanks
Shawn), and lately, we've got Scott ironing out some inefficiencies in
the C code, and Dan submitting patches as well.  Lots of folks are
hacking on their installations to make it more portable to different
architectures than that used by PINES.  And we have asmodai in IRC
working on integrating GNU autotools.

Personally, I'd love to see more people working up clients and
applications using the API from the middle layer.

>If not with programming yet (and I imagine not as I'm sure there are
lots of other programmers far more qualified than myself), what
languages, etc, do I need to learn to be more help with that?  And how
would you suggest going about learning these things?

Any language that's adept at handling stuff like HTTP requests and
JSON or XML parsing would be useful for client side projects (staff or
patron interfaces, remote testing frameworks, plugins/extensions into
other software products, etc.)  The current OPAC is heavy DHTML/AJAX,
the staff client is Mozilla/XUL, and the text-only "slim" PAC is plain
HTML, CSS, and XSLT.

Exercising the various web services that Evergreen exposes would be
useful.  Someone pointed out an OpenSearch bug today, in fact.

The OpenSRF framework that Evergreen is built on is language agnostic.
 Creating bindings for different languages for it would help out a
lot.  Just learning and documenting it would help a lot.

> In the process of migrating from Horizon to Evergreen, is there likely to be a loss of any data, like statistics on circulation etc, that we might need in the future?  This is probably our primary concern in evaluating whether or not to switch to Evergreen, particularly since it is so new and may not have all its features fully implemented yet.

Generally speaking, if it's at all possible for you to export your
data from an existing system into some consistent format, that data
can be mapped into Evergreen.  If it pertains to a feature that isn't
yet implemented in EG, that data can be saved and used for when the
feature is implemented.  The needs and resources of the community
determine what features get into Evergreen; so if you need it, and can
put resources toward it, it'll happen.

Putting on my vendor hat for a moment, I can say that Equinox Software
Inc. (composed of the original Evergreen core developers) has
partnered with a firm very familiar with migrating folks off of
Horizon.  Equinox also offers on-going support and consulting for
Evergreen.

> Out of curiousity, is the staff client intended only for windows or can it also run on linux or Macintosh?

In short, it is cross-platform.  It's built on the Mozilla framework,
so conceivably, any platform which can run Firefox can run the
Evergreen Staff Client.  However, in practice, all recent development
has been in Windows on a static version of xulrunner, and since the
pace of xulrunner development is rapid, it would take a non-trivial
amount of work to polish it for different non-windows xulrunner
builds.

Putting on my open source zealot hat, I'm pro-Linux (and grudgingly
pro-Mac), and did all of my original prototyping and development for
the staff client in Linux (first as a Mozilla plugin and Firefox
extension, and then as a xulrunner application).  It's just the
demands of the libraries that have pushed me toward Windows for the
time being.  I'd love to apply more resources to other platforms.

> One last question.  We spoke with a library consultant about whether to switch to Evergreen or not.  She advised us to wait a few years until other libraries with more programming and technical staff made the switch and Evergreen became more mature.  Do you think this is good advice, or is the water warm to dive right in?  I know my director is eager to switch to something other than Horizon as quickly as possible.

Given my bias and lack of knowledge about your environment and
situation, I can't really answer that one.  But, I can say that
currently there are 265 libraries that run on Evergreen everyday.  As
for maturity, Evergreen is "differently" mature than commercial
software.  It's a modern framework built on mature components (Apache,
PostgreSQL, Jabber) that can be rapidly evolved to meet changing
needs.  Commercial software, however, runs the risk of fossilizing
into something that can't grow, as we've witnessed.

Thanks Karen!

-- Jason