[Web4lib] RE: vendors and usability

[C.S. Durfee]

Yes, the ILS I was talking about uses a standard SQL database and
heavily uses stored procedures, views and triggers... I wasn't really
trying to compare the two as far as functionality.  I was really just
trying to make the point that library software is complex, period.  I
don't understand why anyone, especially people who administer or
program library software for a living, should find that in the least
controversial.

AFAIK, nobody has written an ILS from scratch in the past few years
that, as of right now, has equivalent functionality to the major
players.  Most of them are built on top of codebases which are 10
years old or more.  Anybody who was writing an ILS from the ground up
today would be crazy to not use as much of other peoples' plumbing and
buisness components as possible, but the technology (and the mindset)
wasn't there 10 years ago. And I agree, it's insane that library
software vendors are still writing their own shopping carts or search
engines or Z39.50 components, much less their own RDBMSes...

But often backporting cutting-edge stuff to a system that was designed
10 or more years ago is just not feasible, and at best you're putting
a hat on a mule.  It might be an awful nice hat, but it's still just a
mule.  Starting from scratch is a regression testing nightmare and a
several million dollar and several year effort, during which your
ability to improve your existing products is severely limited, which
drives off large chunks of your customer base to other systems that
may be mules with hats, but at least are for sale today.   Given the
state of the market, it's not surprising that vendors are very
conservative about doing so.

Once you've got a fairly robust codebase, even if it's 20 years old,
it's usually more feasible to keep going on with it.  After that long,
you're bound to have gotten rid of a whole lotta bugs. Of course it's
often very brittle -- you add shiny brand new feature X and it breaks
breaks some piece of code that nobody's even looked at in 18 years. 
Or it comes to the point where it's just impossible to develop it any
further.  So yeah, does an ILS have to be 3 million lines of from
scratch legacy code?  Heck no.  Are there any systems out there that
were written after 1999 or so, designed bottom-up in an enterprise
programming language like Java or C#, using standard RDBMS technology,
supporting standards from the 60's (MARC) to today (SRW/U, VIEWS,
etc.) and built around robust, widely used components?  I know of
several in the pipeline, but none that you could go live with today.



On 7/19/05, arhyno at uwindsor.ca <arhyno at uwindsor.ca> wrote:
> >I made it because I know about how many lines of code there are in the
> >entire OpenOffice suite (about 10 million lines total among the 5
> >separate programs that make up the suite) and about how many lines of
> >code there were in one major ILS vendor's product as of a couple of
> >years ago (around 3 million if you include the OPAC software).
> >OpenOffice Writer has pretty much the same feature set as MS Word.  So
> >with only a little handwaving I feel confident saying that there are
> >about as many lines of code in a for-pay ILS as MS Word, and since the
> >ILS holds your hand a lot less than Word does, I think that adds up to
> >it being much more complex overall.
> 
> It's tough to compare these two classes of application, I would be really
> curious if the ILS in question used a third-party database. The more
> important metric may be how much plumbing needs to be created from
> scratch. One thing to note with the ILS is that there has been significant
> progress on Open Source enterprise systems, such as Open for Business <
> http://www.ofbiz.org/>, that may help with some of the heavy lifting, and
> XML component models are gaining a lot of traction all over the computing
> landscape. Technologies like Services Orientated Architecture (SOA) have
> generated a lot of interest in the banking and insurance industries, for
> example, and I wonder if, in fact, millions of lines of code is an
> indicator that a development team has taken too much on. I have looked
> fairly closely at OpenOffice and it would indeed be hard to cover the
> amazing range of bases it targets without a lot of code, but the ILS is
> much closer to the server-side, enterprise side of the software world and
> not even the organizations that can actually afford the monolithic
> monsters that tend to live in this swamp want to fund them anymore.
> 
> Steve made the comment that ILS vendors haven't even managed to get a good
> shopping cart type of function layered into the OPAC and I think it is a
> great example of where development resources go astray. A decent web
> application framework can supply this and much more without requiring a
> lot of sweat from a development team. I see the OSS options as having an
> advantage here because the OSS crowd are more open to sharing, but the
> vendors will come along too. VIEWS <http://www.views-consortia.org/> is an
> important initiative in this context, and most of the major ILS vendors
> have long since accepted that it doesn't make sense to build things like
> databases and web servers on their own.  In practical terms, I think
> libraries without a lot of technical resources could start asking that
> responses to RFPs and RFIs include information on VIEWS, and start
> inviting responses from organizations like LibLime.
> 
> art
>