Vendors, etc. (was "What LibraryThing means to OPACs")

"I would love to see a library vendor take up the Red Hat model of
making a profit: getting behind the various open-source packages,
working on making them enterprise ready, and selling documentation,
support, and training. But I don't think it's going to be one of the
existing vendors who really commits to that."

Or libraries.  As I tried to say earlier (I think my post was either
gobbled up or ignored, but oh well), "And who will help me bake this
bread?" asked the Little Red Hen.  Is Brandies or Cal or anybody else
going to buck up for this?

Vendors - companies - are creatures of profit.  They respond to
demonstrable market interest - requirements in RFI's, RFP's, ItB, and in
dollars spent.  Also, as communities of people, more than a few of them
are earnestly interested in delivering great tools at an affordable
price to their customers - within the realm of "what's possible."  One
of the things that's missing in this conversation is an awareness of
what I'll call political economy inside a company.  How, as a customer,
do I get vendor management attention to get what I want.  Well, getting
attention is as simple as picking up the phone and asking for somebody.
If you want to talk to a CEO, those folks aren't unapproachable - chat
'em up.  When you have that conversation, however, be prepared to have a
meeting of equals, and that's a rather harder thing to do, isn't it?

I don't know the president of our vendor, and I'm sure that president
doesn't know me from Adam, but if I was going to have a serious
conversation with him or her about the alignment (or lack thereof)
between the vendor's sales, marketing and development strategy, and my
library's strategy for its future (we do have a strategy, don't we?),
I'd prepare like I was going to war.  A more polite way to put it is I'd
have all my ducks in a row:

   - a clear understanding of what I want, what I need, what I have and
what I am and am not getting from my vendor.
   - a list of alternatives, if necessary.
   - an understanding of what my users - my customers need - first, and
then an understanding of what staff need, first from the bottom-up, and
then from the top down.
   - explicit backing from management, from me all the way up the org
chart.
   - clear authority to negotiate.
   - and if I can get it, money.  Maybe its just clarity about what I've
paid and spent so far.

David Scharf hit the nail on the head: technology changes, people don't.
Where is the leadership coming from to make the next big leap [to the
next generation catalog - MJA] which we all agree is sorely needed.

I think about this in Venn diagram terms.  Imagine two circles.  One is
what I want a system to do, the second is what the vendor's system can
do.  There is never perfect overlap between those two circles.  If there
is 80% overlap, maybe that's good enough.  So I back fill functionality
A LITTLE with some focused, local product development (e.g. MyLibrary at
NCSU and now Notre Dame, and LibData at U. of Minnesota).  Less overlap
sometimes equals more local development - witness Endeca at NCSU.  Note
that none of these places has scrapped their ILS or the vendor it came
from.  If there is 30% overlap or less then you see things like
Open-ILS, FOSS products, and local development of large systems.  Note
what happens though - now the library becomes the "vendor."  Please
re-read the paragraph beginning "Vendors - companies - are creatures of
profit...."  Well libraries aren't for-profit entities - no, they are
not.  But that doesn't change the inner dynamics at work in an
organization, do they?

My questions are:

   - What is the definition of a next-gen catalog?

   - What should a next-gen catalog be able to do?

   - How should it look & act with & for my users?

   - How do I accommodate changing needs (at the front) and technology
(at the back)?

   - How do I get this new wonder in an affordable, timely and
technologically viable way (def. - works, in-use, well-documented,
understandable design, support available, scalable, customizable)?

   - Do I:
      * Buy it from a vendor?
      * Get a FOSS product?
      * Make it myself?

   - If the product is pre-existing, do I:
      * Use it stock?
      * Customize it a little?
      * Customize it a lot?

   - What are the product and implementation (="product as installed at
my place for a finite amount of time") life cycles and how do they
overlap?

Above all I am interested in this:

   - Library bought a vendor system - what are the model implementations
and failures?
   - Library acquired a FOSS product - what are the model
implementations and failures?
   - Library created their own systems - what are the model
implementations and failures?

We don't talk nearly enough - public ally - about project failure in
this business.  This means naming institutions, companies, people,
money, the whole panoply of screw-ups.  And this can't distract us from
what the Appreciative Inquiry folks would call (and ask) "What works?
What do we do well and how do we do more of it?"

M. Andrews