I think this depends entirely on what type of developer we are talking
about. Let's say it is a large ILS vendor who promises that their
software will do all things for all types of library. When a promised
feature or a discovered bug that only applies to a small subset of their
customer base (let's say academic or public or government) is found, the
reason that is does not benefit a large enough community to put the
expense is simply bogus.
The end result is that type of library essentially sitting on a product
for years because there is no commitment to improve their service in
their future. This is happening frequently with "new" products that are
introduced (at least in my ILS community) which, while are sold as
usable to all types of libraries, are clearly designed for one specific
or their largest base in mind only.
A smaller development company or cooperative team is a bit different.
Hopefully they have communicated their product specifically for what it
does, and communicated their organizational size, strength, and focus so
that the consumer understands that going in. Large library software
corporations should really be doing the same, but that doesn't happen.
Tim
Tim McGeary
Senior Systems Specialist
Lehigh University
610-758-4998
[EMAIL PROTECTED]
Jonathan Gorman wrote:
Hmmm, I'm tempted to add something to responsibilities along the
lines of "Seek to understand the priorities of the software
developers". Similar to "requesting features responsibly". I can
see an important difference. Sometimes it's important to let people
know of a desired feature, even if in the end the vendor/developers
decide resources can't be dedicated to fixing that bug or adding that
feature. Often it's difficult for "customers" to know the relative
difficult of adding a feature or doing a bug fix. We don't want them
not to request. When they're requesting features for others, they do
have a responsibility to document those desires (usability testing,
interviews, etc).
However, sometimes fixing a bug or adding a particular feature will
only have a small benefit to a small community, be simply too
expensive given it's priority, or may be in a part of the system
that requires a more radical rewrite. When these conclusions are
reached it's helpful for the customer not to try to do a "run-around"
or pull strings to get that feature added anyhow. Say, by calling
their buddy the CEO and convincing him the developers are just
avoiding work unnecessarily.
How about an equivalent list from the vendor/software developer's
perspective? I think that would help balance the picture, but
perhaps that's already in your plans ;).
Jon Gorman
---- Original message ----
Date: Tue, 6 Nov 2007 10:07:45 -0800 From: Roy Tennant
<[EMAIL PROTECTED]> Subject: [CODE4LIB] Library Software Manifesto
To: CODE4LIB@listserv.nd.edu
I have a presentation coming up and I'm considering doing what I'm
calling a "Library Software Manifesto". Some of the following may
not be completely understandable on the face of it, and I would be
explaining the meaning during the presentation, but this is what I
have so far and I'd be interested in other ideas this group has or
comments on this. Thanks, Roy
Consumer Rights
- I have a right to use what I buy - I have a right to the API if
I've bought the product - I have a right to accurate, complete
documentation - I have a right to my data - I have a right to not
have simple things needlessly complicated
Consumer Responsibilities
- I have a responsibility to communicate my needs clearly and
specifically - I have a responsibility to report reproducible bugs
in a way as to facilitate reproducing it - I have a responsibility
to report irreproducible bugs with as much detail as I can provide
- I have a responsibility to request new features responsibly - I
have a responsibility to view any adjustments to default settings
critically
