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
[log in to unmask]


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
>> <[log in to unmask]> Subject: [CODE4LIB] Library Software Manifesto
>> To: [log in to unmask]
>>
>> 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
>