Re: RE: vendors and usability

>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
_______________________________________________
Web4lib mailing list
Web4lib@...
http://lists.webjunction.org/web4lib/