"Fortidude"

1. So I presume libraries are getting everything for free as they aren't
really holding anyone accountable. ;-) Seriously though, lock-in,
monopolies, licensing and other problems prevent the full accountability
that you suggest. Some journals are only available from certain vendors.
Some ebooks are available only with strict DRM that prevents you from
doing some forms of preservation. In some cases money means
accountability but in many cases it's just a way to "pass the buck". Are
you buying from a vendor so you can hold them accountable or because you
yourself don't want to be solely accountable. It's easier to tell a
patron that you can't do something because vendor X doesn't support it
rather then "we haven't had the resources to build that feature".
---
Ryan - in my experience working for library automation vendors,
librarians were quick to remind me of who was paying who.  As far as
"hold[ing] them accountable" vs. "[not] want[ing] to be solely
accountable," this is not either/or, its both/and.  I can't solve every
problem myself, that's why I literally buy help.  As to demand for
features, I'll do my best to use what I bought to meet my customers
needs, and find ways to extend what I bought in unanticipated
directions.  It's a delicate dance to understand new needs and find ways
to meet them without getting too far outside one's skill set (or doing
nothing), spending too much money (or not taking any risks), and setting
expectations re/the desirable, the possible, and the doable with a given
set of resources.  Re-reading this it sounds like a log of vague crap,
but it's only a quick way of describing what vendors try to do daily,
sometimes well, sometimes poorly.

Fine tuning our relationship with library automation vendors is not the
only place that fine-tuning needs to occur, as you describe above.

2. Which doesn't mean that the Soyuz has to be some inflexible tin can.
FOSS also doesn't mean that everything has to be hand rolled at the
library itself. Take for example LibLime. They will gladly help you
build the solution you want using FOSS components. There's money and
some accountability. The difference is if down the road your not happy,
you can do something about it. Even if the vendor goes poof.

As far as I know LibLime will also help you build FOSS solutions for
existing vendor products, similar to what AADL did itself. I believe
they require the solution to be open-source though so other libraries
can use it. I think this is a much better solution long-term for
libraries. If we invest in solutions that other libraries can use we
will be much better off than building yet another walled garden.
---
Ryan - By no means is the library automation Soyuz anything like an
inflexible tin can; extending my analogy a little more, the Soyuz of
2006 is not the Soyuz of 1976 or 1966.  And that little spacecraft, with
updated avionics, propulsion and a variety of capable, tested designs,
keep the International Space Station manned, supplied and in the proper
orbit.

My "Soyuz" (I'm not afraid to name names here) is a lateral move from
SirsiDynix's WebCat to iLink.  I am greatly looking forward to making
the best possible use of a widely used, stable product at our libraries.
In due course I hope to install follow-on products from that same
vendor.  The vendor is not perfect, their products are not perfect and
Lord knows I'm not perfect, but we'll work together to server our
customers as best we can.

Nothing against FOSS, Koha, or LibLime, but I'm not going to be the
first guy to discover that his libraries are not necessarily a good fit
for a particular software development & marketing strategy, product or
company.  I am risk-adverse and I have very, very little time for
experimentation or product development.  I'll try a pilot project as a
learning exercise, to better understand a problem I'd like to solve, or
to demonstrated to a vendor-partner the way I'd like to see a problem
solved.  I would like to learn more about where FOSS works and fails
generally; I would like to learn more about where FOSS works and fails
in libraries; I would like to learn more about why a given library
choose to devise its own systems or deeply customize commercial
products.  There is not nearly enough public discussion of where and why
these projects work, and where and why they fail.

I'd like to extend props the PINES folks with Open-ILS, but I'll be very
specific:  I better understand, having read what they've posted here,
that they have a particular problem to solve that the ILS vendors
weren't going to solve for them.  But, to quote former Texas Gov. Ann
Richards, it takes extensive "testicular fortitude" to do what they are
doing.

MJA