gmane.education.web4lib

Jesse Ephraim | 16 Jul 21:58

RE: vendors and usability

"For years, my library has been struggling with some basic usability 
flaws in our online catalog interface for the web, things that can't 
apparently be done with the software as it stands and are apparently low

priority for the vendor.
What are librarians doing to pressure catalog softwarevendors to address

usability issues?"

There are several things you can do:

1) Call the vendor every single time there is a problem or a usability
issue, no matter how small.  Use the support and maintenance agreement
to its fullest.  If everyone does this, it will become more
cost-effective for them to simply fix the problems (or make the software
more usable).

2) Haggle very hard over the cost of everything.  Library automation
software companies don't get challenged enough on their prices, and many
don't feel that they have to be competitive since it is an involved
process to change software (and there are a limited number of
competitors).  However, many will come down pretty significantly
(particularly on support/maintenance costs) if you dig your heels in,
particularly if you let them know that you have been talking to other
vendors who are willing to take less and have been evaluating open
source solutions.

3) I was a professional programmer for 10 years, and believe me when I
say that most of the automation software out there is VERY poorly
written.  If I had produced code like that for final release on

(Continue reading)

headers

Karen Coyle | 17 Jul 18:02

Re: RE: vendors and usability

Jesse Ephraim wrote:

>2) Haggle very hard over the cost of everything.  Library automation
>software companies don't get challenged enough on their prices, and many
>don't feel that they have to be competitive since it is an involved
>process to change software (and there are a limited number of
>competitors). 
>  
>
I'm actually going to argue against this technique. The library 
automation vendor marketplace is not a strong one, for a number of 
reasons. One is that libraries are relatively poor institutions who buy 
systems and upgrade as seldom as possible. We are seeing an increasingly 
shrinking vendor pool, which isn't good. Companies have recently gone 
out of business or been bought, and not because they've got good 
profits! Another reason why the market is difficult is that it's a zero 
sum game. There are a finite number of libraries, and they all need 
systems. Every purchase from one vendor robs a customer from another. 
This kind of market doesn't respond well to the normal economic pressures.

The other argument against pressuring vendors to work on their user 
interfaces is that the user interface is going to be the most variable 
part of the system across customers. It's not economically viable, nor 
terribly sensible, for vendors to put a lot of energy into customizing 
the user interface for individual libraries. I still think we should try 
to split the user interface away from the rest of the system so that it 
CAN vary for each library. The vendor's energy could then be put into 
making the program interface as flexible as possible.

kc

(Continue reading)

headers

Jennifer A. Heise | 17 Jul 19:23

Re: RE: vendors and usability

> The other argument against pressuring vendors to work on their user 
> interfaces is that the user interface is going to be the most variable 
> part of the system across customers. It's not economically viable, nor 
> terribly sensible, for vendors to put a lot of energy into customizing 
> the user interface for individual libraries.

I'm sorry, I don't think you are understanding the problem. What we are 
seeing are interfaces that, while nominally customizeable, are still so 
invested in older systems technologies on the back end that little 
effort is being made to improve customizeablility.

> I still think we should try to split the user interface away from the 
> rest of the system so that it CAN vary for each library. The vendor's 
> energy could then be put into making the program interface as flexible 
> as possible.
>
While the interface IS generally split from the rest of the system, 
especially in web-based systems, the customizeability of the user 
interfaces seem to be a low priority. For instance, wouldn't it be nice 
to be able to put 'Next page' buttons whereever you wanted on a page of 
results? I'm informed that our catalog web interface software will not 
allow putting it anywhere except the system-defined spot.

Now, if vendors were to come up with interfaces as a separate swapable 
module, so that a good interface could be built locally or by another 
company and fixed onto the systems back-end, that would be a way to go. 
Z39.50 etc. interfaces to our existing catalog databases don't seem to 
be very flexible because of the limitations of backend diversity and old 
code in the backend systems.

(Continue reading)

headers

David Walker | 18 Jul 16:51

RE: RE: vendors and usability

>> I still think we should try 
>> to split the user interface away 
>> from the rest of the system

I think Karen is spot-on here.

As strange as it sounds, I don't think we want library vendors spending
what little resources they have trying to build better interfaces.  For
two reasons:

(1) Frankly, they aren't very good at it.

There are some simple and even painfully obvious things some companies
can do to make their systems more usable.

But designing a good, usable system is hard.  It requires talented
people with skills in interaction design and a deep understanding of
end-user needs and goals.  Vendors cannot acquire either of those
easily, but libraries themselves can.

(2) Ultimately, the library consists of many systems.

Most academic libraries have a half-dozen or more local systems besides
the catalog, usually from multiple vendors, as well as access to 100s of
remote databases, most of which have serious interface problems.

What my users need is not a better OPAC interface. They need a simple,
intuitive interface that spans *all* of our systems.

Vendors simply cannot create that for us.  The only way libraries can

(Continue reading)

headers

Joshua Ferraro | 18 Jul 17:50

Re: RE: vendors and usability

On Mon, Jul 18, 2005 at 07:51:58AM -0700, David Walker wrote:
> >> I still think we should try 
> >> to split the user interface away 
> >> from the rest of the system
I think I finally understand what you mean by this. Interestingly,
the open-source ILSes have this feature built in (I assumed that
proprietary systems did too, hence my confusion). Koha for instance,
has a system of templates that allow any web designer to completely
overhaul the look and feel of the interfaces without needing to
know anything about the programming languages that Koha's written in.
Here are some examples of vastly different 'skins' for Koha's OPAC:

http://search.athenscounty.lib.oh.us
http://library.lgnz.co.nz/cgi-bin/koha/opac-search.pl
http://opac.lianza.org.nz/cgi-bin/koha/opac-search.pl
http://opac.eeo.katipo.co.nz/cgi-bin/koha/opac-main.pl
http://opac.liblime.com

The same thing has been done with the librarian interfaces.

> Most academic libraries have a half-dozen or more local systems besides
> the catalog, usually from multiple vendors, as well as access to 100s of
> remote databases, most of which have serious interface problems.
> 
> What my users need is not a better OPAC interface. They need a simple,
> intuitive interface that spans *all* of our systems.
> 
> Vendors simply cannot create that for us.  The only way libraries can
> offer our users the seamless experience they expect, is through APIs.
Some vendors can .

(Continue reading)

headers

Joshua Ferraro | 19 Jul 19:00

ammendment: free vs. public domain [was vendors and usability]

On Mon, Jul 18, 2005 at 08:50:00AM -0700, Joshua Ferraro wrote:
> When I first started working at Nelsonville, I figured that since most
> libraries are publicly funded they'd be supporting public domain software.
> But instead, the vast majority of folks use proprietary systems.
Mike pointed out (thanks) that my use of 'public domain' in this sentence
isn't accurate. Public domain is a legal term meaning there is no 
license at all, whereas Koha is licensed under the open-source General
Public License (GPL).

There's a good breakdown of the different licensing categories for software
here: http://www.gnu.org/philosophy/categories.html

Under Public Domain:

"Public domain software is software that is not copyrighted. If the source 
code is in the public domain [...] which means that some copies or modified 
versions may not be free at all."

[... snip ...]

" Sometimes people use the term ``public domain'' in a loose fashion to 
mean ``free'' or ``available gratis.'' However, ``public domain'' is a 
legal term and means, precisely, ``not copyrighted''. For clarity, we 
recommend using ``public domain'' for that meaning only, and using other 
terms to convey the other meanings."

Sorry for the confusion, I fell prey to using a nice-sounding word to
convey my idea and didn't pay enough attention to the meaning -- and 
thanks to Mike for pointing out the distinction.

(Continue reading)

headers

Bridge, Frank | 18 Jul 21:33

RE: vendors and usability

Hello Everyone--

I believe that Karen Coyle is closer to the reality of the situation.
The library automation marketplace is a limited universe and the number
of vendors is declining.  The marketplace is not a wealthy one and its
users are demanding, not only in system functionality but also in system
reliability.  Libraries often establish strong contractual performance
guarantees to assure that system functionality and reliability are
preserved.  

In the middle of this business environment it is difficult to expect its
vendors to re-design their systems from the bottom up so that a library
can then affix its own locally-built user interface or someone else's.
It takes millions of dollars for a vendor to re-engineer a system.  The
marketplace is littered with the carcasses of vendors who have failed to
transition between system architectures.  A major intent of such a
change was to deliver a new look and feel--this is a major system
selling point, but also intended to fall within the bounds of the secure
functionality and reliability mentioned above.  

The newly-suggested model--having a library automation vendor design an
open-ended system so that the local library can then overlay its own
interface--introduces variables that a library automation vendor could
not control and whose look and feel could be seriously compromised.
There are a number of libraries who have the local expertise to
accomplish this successfully, or to administer a third party vendor to
do so.  But is there a sufficiently large universe of libraries to
sustain a market for the vendor investment to develop such a system?  

It is that business opportunity that creates the pressure to design such

(Continue reading)

headers

Joshua Ferraro | 18 Jul 22:17

Re: RE: vendors and usability

On Mon, Jul 18, 2005 at 03:33:43PM -0400, Bridge, Frank wrote:
> The newly-suggested model--having a library automation vendor design an
> open-ended system so that the local library can then overlay its own
> interface--introduces variables that a library automation vendor could
> not control and whose look and feel could be seriously compromised.
> There are a number of libraries who have the local expertise to
> accomplish this successfully, or to administer a third party vendor to
> do so.  But is there a sufficiently large universe of libraries to
> sustain a market for the vendor investment to develop such a system?
A bit of history:
In 1999 Horowhenua Library Trust in New Zealand hired Katipo Communications
to develop Koha, a full-featured open-source ILS. Koha is now used in over
60 libraries worldwide almost all of whom pay for support from one of four
vendors (LibLime in North America, Katipo in Australasia, Paul Poulain in 
France and MJ Ray in the UK). So market sustainablity is definitely possible
for 'open-ended' systems.

Interestingly, instead of competing with one another the four vendors
supporting Koha are collaborating together and sharing their development
resources to make the product better (with sponsorship from libraries).

> It is that business opportunity that creates the pressure to design such
> a system, not just our demands for it.
In fact, in many cases, open-source projects have far exceeded their
proprietary counterparts in terms of overall design, usability and 
functionality: Firefox and Apache are two examples. Don't forget the
Yaz toolkit and Zebra, both designed by Index Data ... Yaz powers more
than half of all Z39.50 servers and clients world-wide and is widely
considered to be the leading toolkit for building Z39.50 applications.

(Continue reading)

headers

David Walker | 18 Jul 22:37

RE: RE: vendors and usability

>> The same thing has been done 
>> with the librarian interfaces.

Which honestly, Josh, I think is a major drawback to Koha.

Don't get me wrong, I think it's an absolutely wonderful project.  I
would recommend it for any small public or school library today, and
will be happy to dump our lumbering, commercial ILS system in five to
ten years when Koha or some other open source ILS can compete in the
academic market.

But to do that, I think you need *desktop* clients for the back-end
modules.  A web interface for the end-users is a must.  But web
interfaces for management modules are simply clunky for anything but the
most trivial of tasks.  Heck, I would even take a terminal interface
over a web interface for cataloging, acquisitions, and circulation.

Unless, of course, Koha 3.0 will provide that.  In which case I will be
happy to eat my words and up the timeline to conversion. 

--Dave

=================
David Walker
Web Development Librarian
Library
Cal State San Marcos
760-750-4379
=================
_______________________________________________

(Continue reading)

headers

Joshua Ferraro | 18 Jul 22:49

Re: RE: vendors and usability

On Mon, Jul 18, 2005 at 01:38:36PM -0700, David Walker wrote:
> Unless, of course, Koha 3.0 will provide that.  In which case I will be
> happy to eat my words and up the timeline to conversion. 
. Koha 3.0 and as far back as 1.0 has a terminal interface 
(on the librarian side). We're investigating options for web-based 
clients that are based on DHTML (XMLHttp for instance) to lower the HTML
overhead and increase the usability of the interface. That's the
direction that the PINES Evergreen project has taken (the other
large player in the open-source ILS world) and the results there 
are quite impressive.

But to be honest, Koha now is more usable than many of the proprietary 
systems out there. Everything you need to do is neatly layed out on a 
resident navigational bar and short-cut keys control all actions so a 
staff member rarely needs to use a mouse.

You can try out the circ functions here:
http://koha.liblime.com

But you're right that Koha 3.0's interface will be much better.
The thing is, Koha 3.0 will include a lot of great features only 
because libraries who have vision are sponsoring them. I can't
tell you how many libraries have said 'well if Koha did X we could
use it'. Koha could easily do X ... but someone needs to step
forward and sponsor it before it's going to happen. None of the
libraries who have have turned back ... it's kinda like switching from
IE to Firefox ... how many proprietary vendors can say that? 

Cheers,
--

--

(Continue reading)

headers

Joshua Ferraro | 18 Jul 22:51

Re: RE: vendors and usability

On Mon, Jul 18, 2005 at 01:38:36PM -0700, David Walker wrote:
> Unless, of course, Koha 3.0 will provide that.  In which case I will be
> happy to eat my words and up the timeline to conversion. 
. Koha 3.0 and as far back as 1.0 has a terminal interface
(on the librarian side). We're investigating options for web-based
clients that are based on DHTML (XMLHttp for instance) to lower the HTML
overhead and increase the usability of the interface. That's the
direction that the PINES Evergreen project has taken (the other
large player in the open-source ILS world) and the results there
are quite impressive.

But to be honest, Koha now is more usable than many of the proprietary
systems out there. Everything you need to do is neatly layed out on a
resident navigational bar and short-cut keys control all actions so a
staff member rarely needs to use a mouse.

You can try out the circ functions here:
http://koha.liblime.com

But you're right that Koha 3.0's interface will be much better.
The thing is, Koha 3.0 will include a lot of great features only
because libraries who have vision are sponsoring them. I can't
tell you how many libraries have said 'well if Koha did X we could
use it'. Koha could easily do X ... but someone needs to step
forward and sponsor it before it's going to happen. None of the
libraries who have have turned back ... it's kinda like switching from
IE to Firefox ... how many proprietary vendors can say that? 

Cheers,
--

--

(Continue reading)

headers

C.S. Durfee | 18 Jul 23:03

Re: RE: vendors and usability

With all due respect, I have found in my experience that it is rather
a bad idea to "log every single problem or usability issue, no matter
how small".  That can lead to a situation where all perspective is
lost, and all problems are treated with the same level of severity -
none.  You really don't want your vendor treating trivial issues with
the same degree of urgency as more serious ones.  And you don't want
your vendor to spend all of their time firefighting, fixing things
that are problems for just a handful of customers, instead of building
next generation systems.

Besides, you always always always catch more flies with honey than
with vinegar.  You need to pick your battles carefully and win every
one.  How? For starters, by being polite but firm, and making it
easier for the vendor to fix the bug (by always filing exact steps to
reproduce the problem) and for them to understand why it is such a big
issue for your library.   Being the customer from hades is not the
best way to achieve that, in my experience.

Library systems software is extremely complex.  There are a lot of
reasons for that (some obvious, some not so obvious) which I won't go
into here, but it is.  I do not know for sure, but I am willing to bet
that the number of function points (a standard metric of software
complexity) for a complete ILS is much higher than for, say, MS Word. 
I would love to see a vendor actually provide such an analysis to
their customers, though.

I do agree with the suggestion to do what you can to get the best
software for your money.  Capitalism is a great way of encouraging the
development of better products.  If one vendor is better than the
others, by all means, give them your business!  And even if you are

(Continue reading)

headers

Joshua Ferraro | 18 Jul 23:07

Re: RE: vendors and usability

On Mon, Jul 18, 2005 at 02:03:52PM -0700, C.S. Durfee wrote:
> Library systems software is extremely complex.  There are a lot of
> reasons for that (some obvious, some not so obvious) which I won't go
> into here, but it is.  I do not know for sure, but I am willing to bet
> that the number of function points (a standard metric of software
> complexity) for a complete ILS is much higher than for, say, MS Word. 
> I would love to see a vendor actually provide such an analysis to
> their customers, though.
Ha! that sounds like it came directly from a TLC proposal . The fact
is, library software isn't that complex compared to a word processing 
suite like MS Office or OpenOffice.org. I don't know when vendors 
started making this claim but it's simply not true.

What is true is that the marketplace for ILSes is finite (which isn't
the case for MS Office yet). So libraries can make vendors jump through
enormous loops to prove that their product is better than the competition.
On-site demonstrations, lengthy RFPs and responses, etc. 

This process drives up the price enormously ... license fees are the
other major unnecessary cost involved in ILSes.

> I do agree with the suggestion to do what you can to get the best
> software for your money.  Capitalism is a great way of encouraging the
> development of better products.  If one vendor is better than the
> others, by all means, give them your business!  And even if you are
> using the best vendor in the world, negotiate for the best price you
> can get.
I agree with you 100%.

Cheers,

(Continue reading)

headers

C.S. Durfee | 19 Jul 02:38

Re: RE: vendors and usability

As far as I know, vendors haven't ever made that claim.  I made that
claim.  If you disagree with it, I'd like to hear your reasoning or
evidence to the contrary rather than some blanket statement like "that
sounds like it came directly from a TLC proposal...it's simply not
true".

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.

Furthermore, the documentation on all the configurable features in
that major ILS is about 2500 pages long, it's written at a very high
level for people with a deep knowledge of how libraries operate and is
not particularly prolix.  "Microsoft Word 2003 Inside Out" is 976
pages long, a lot of which is on using Visual Basic for Applications
macros, and is written for total beginners.  The ILS' manuals don't
cover programming stored procedures or scripting at all, which would
be the  equivalent to VBA macros.  I think the number of pages of
documentation required to operate a piece of software is probably an
even better measure of how complex it is than the number of lines. 
The number of function points would be the best metric, but I don't
know if anyone's performed such an analysis on any ILS software.

(Continue reading)

headers

arhyno | 19 Jul 15:56

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

(Continue reading)

headers

C.S. Durfee | 19 Jul 22:33

Re: RE: vendors and usability

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,

(Continue reading)

headers

arhyno | 20 Jul 05:30

Re: RE: vendors and usability

>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

True, I guess the promise is that the development cycles may get smaller 
every time. The RDBMS solved some huge persistence and transaction issues 
when it became a standard part of the ILS, and if we reach a point where 
constructs like general ledgers can be acquired from mainstream sources, 
then the next generation of ILS applications will have a lot less lines of 
code and much more potential.

art
_______________________________________________
Web4lib mailing list
Web4lib@...
http://lists.webjunction.org/web4lib/

headers

Bollinger,Stephen | 19 Jul 14:24

RE: RE: vendors and usability

Comparing lines of code is a poor metric. Customizing our OPAC was like stepping back through a bad time
machine to 1997 (wretched, malformed HTML 3.2 with a stylesheet only a programmer who "knew some HTML"
could love). Configuring our OPAC was like stepping back to 1990 (terminal interface, green screen). Our
vendor can't even get a shopping cart to work right. Didn't everyone figure out how to do those back in 1995?

What you're counting there is bloat, legacy code, hacks and pure ugliness (in the commercial ILSs, that is,
MS Word's code is another flame war for another list).

An earlier poster commented that a programmer in the corporate world would be fired for producing the
buggy, ill-designed code that comprises our ILSs. That is spot on. We are the ones to blame, because we keep
buying/licensing them despite this.

Consolidation or no, zero-sum game or no, we are all wasting our time and money if we do not demand a minimum
level of user interface design, interaction design and usability both for our interfaces and those we
force our patrons/students/customers/whatever through before they can use our services.

I do not envy the ILS vendors. They have to accomodate libraries large and small that present some arcane
requirements. I don't think anyone is saying creating and maintaining an ILS is easy. There's no excuse,
however, for them to ignore usability issues and it is our responsibility to demand it of them.

Oh, and don't get me started on those 2500 pages of ILS docs. ;^)

Yours,
-Steve

Stephen Bollinger
Internet Specialist
CAPITAL AREA DISTRICT LIBRARY
401 South Capitol Avenue
Lansing, MI 48901-7919

(Continue reading)

headers

Bridge, Frank | 19 Jul 20:05

RE: vendors and usability

Hello--

I was directing my remarks at a specific business model:  

One in which the user base would pressure a library automation vendor to
re-design the internals of an existing system or to create a brand new
system so that customers could then overlay/attach library-preferred
front ends thereto.  That front end could either be an
internally-developed or third-party-developed product.  I also limited
my comments to the library automation marketplace only.  

I am pleased that the Horowhenua Library Trust hired Katipo
Communications to develop its open-source IOLS software.  I checked the
Koha Web site and learned that the software is being "...maintained by a
team of volunteers around the globe."  Koha rolled out in 1999 and has
approximately 60 libraries currently using this software.  Koha has done
reasonably well, but this model does not approximate the arrangement I
described above, and it appears that the Koha company/software viability
is more a labor of love and dedication rather than for financial gain.
These are admirable motivations and results--sixty users of free
open-source software in six years of company history.  
But to gain a substantial foothold in the IOLS industry, you are now
looking at a set of about a half-dozen large competitors each of whom
has a user base of at least hundreds of libraries each over which to
spread the development costs and support operations.  And yet even those
user bases are limited compared to other open-source projects with whom
Koha has drawn parallels.  Firefox and Apache have such a vast potential
audiences that it is unrealistic to compare the success and
sustainability of these applications to any IOLS.  
Don't get me wrong--if any group of librarians wants to pressure the

(Continue reading)