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 >