[CODE4LIB] Library Software Manifesto now online
As you may recall, last week I asked for input and feedback on a draft library software manifesto I was going to talk about at a conference. I did, and I've taken the key points of the talk and posted them on my TechEssence.info site at: http://techessence.info/manifesto/ I specifically created this not as a blog post, but a document that I can feel free to change according to feedback and my changing thoughts on the matter. So I welcome comments either on the item itself or directly to me. Thanks, Roy
Re: [CODE4LIB] Library Software Manifesto
Carl Grant wrote: a. You've got to accept responsibility for helping to test software. There can be 1000's of pathways through code. We know you want bug-free code, but the developer/vendor can't test them all by themselves or you'd never actually get the code! I don't know about this. There is a thing called Quality Assurance. Mass market software makers like Microsoft spend quite a bit of effort on QA procedures to try and assure a basic level of _working_ before a product is released. In our market, we very very seldomly get this. There are techniques and methodologies that other software companies have developed to try to assure quality without never getting the code. What is it about our particular industry that leads to us not being able to expect this? On the other hand, yes, customers should be willing to be beta testers. But the software we are often given to 'beta test' (or even as _release quality software_) is sometimes at a level that wouldn't even be called 'alpha' in other industries. Other times final release software has serious flaws in it that keep the software from doing what it's advertised to do. Customers should not have to themselves perform as unpaid testers for the vendor to achieve a basic level of quality. I guess the question is in what is that 'basic' level of quality. I guess vendors think they are currently delivering it, but customers don't think they are currently getting it. (I guess the various constraints that keep us from _no longer buying_ the software even if we think we aren't getting that basic level of quality is the answer to why we aren't able to expect that basic level of testing before software is released... Many of us are trying to work on those constraints.) Jonathan b. If you're paying a commercial vendor to support/maintain, understand that costs should go up to compensate them for supporting that increasing complexity. 5. Try to standardize practices, **where possible**, between like institutions. Use development resources for great ideas, not just to support local idiosyncrasies... 6. Understand if you're trying to please everyone, it means lowest common denominator. If you're trying to lead and develop new ideas, somebody is going to be upset. It's not the developer/vendors responsibilities to decide which of these apply to your institution or what to do about it when it happens. Decide up front, are you following, or are you leading? Carl Carl Grant President CARE Affiliates, Inc. E:[EMAIL PROTECTED] M:540-529-7885 O:540-552-2912 866-340-9580 x 801 (Toll-Free) Website: www.care-affiliates.com Adium: carl_r_grant Skype: carl_grant On Nov 6, 2007, at 1:33 PM, Roy Tennant wrote: On 11/6/07 10:27 AM, Jonathan Gorman [EMAIL PROTECTED] wrote: 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 ;). Funny you should ask...I had originally intended to do this, but then I was wondering if it start to be redundant -- that is, would a number of points simply be restated from the vendor's viewpoint? But if there are unique points to make from that perspective it would be worthwhile to include them. This is an area where I consider myself even more ignorant than usual, so if those of you who work on that side of the fence would like to chime in with relevant manifesto points from the perspective of developers and vendors, I'm all ears. Thanks, Roy -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu
Re: [CODE4LIB] Library Software Manifesto
Perhaps the poster was paraphrasing the quote Writing about music is like dancing about architecture. At least that's how I read it. - Mike __ Mike Kmiec Lead Developer : Innovation Centre National Library of New Zealand Te Puna Matauranga o Aotearoa [EMAIL PROTECTED] +64 4 474 3137 Roy Tennant [EMAIL PROTECTED] 8/11/2007 7:49 pm I really wish I could understand what you mean. I think I get the difference between a contract and its enforcement and software architecture, but is there a reason why these should not be addressed in the same talk? There is clearly something I'm not getting here, so perhaps further explication could help me to see it? Thanks, Roy On 11/7/07 11:24 AM, D Chudnov [EMAIL PROTECTED] wrote: On 11/6/07, Roy Tennant [EMAIL PROTECTED] wrote: I have a presentation coming up and I'm considering doing what I'm calling a Library Software Manifesto. It's a fine line between focusing people's attention on specific aspects of how to enter into and enforce contracts and dancing about architecture. -- This e-mail is intended for the addressee only and may contain information which is subject to legal privilege. The contents are not necessarily the official view or communication of the National Library of New Zealand. If you are not the intended recipient you must not use, disclose, copy or distribute this e-mail or any information in, or attached to it. If you have received this e-mail in error, please contact the sender immediately or return the original message to the National Library by e-mail, and destroy any copies. The National Library does not accept any liability for changes made to this e-mail or attachments after sending. All e-mails have been scanned for viruses and content by security software. The National Library reserves the right to monitor all e-mail communications through its network.
Re: [CODE4LIB] Library Software Manifesto
I just saw Roy's presentation, and it was good. Faced with a restive but not radicalized audience of SD customers, Roy moved the issue another couple yards toward what most members of Code4Lib believe and want, but without any harshness or rancor. But those of us who are angrier than Roy need to keep it up, so Roy's mellow but essentially radical vision becomes the safe alternative! ;) Tim On 11/8/07, Nathan Vack [EMAIL PROTECTED] wrote: On Nov 6, 2007, at 12:07 PM, Roy Tennant wrote: 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 things I like in software products / Consumer Responsibilities how to not be a jerk of a customer / The thing that kind of bugs me here is the idea that these things are somehow _rights._ They're certainly excellent guidelines (and I'd take all these points into consideration when looking at software)... but they're not 'rights.' 'Rights' implies a legal entitlement. When you're buying software, you have a whole bunch of rights, which vary depending on what jurisdiction you're in -- but I doubt the use of an API is in that list in ANY jurisdiction. Really, when you're buying software, your most common right is to negotiate a contract and price with vendors. If either party to uphold their end of the contract, the other party generally has a right to sue. If no vendor will provide a contract and price you can agree to, you have a right to build software yourself... or find vendors who will build the software, and to negotiate contracts with them. So: these are indeed good ideas. They are most definitely not rights. Cheers, -Nate -- Check out my library at http://www.librarything.com/profile/timspalding
Re: [CODE4LIB] Library Software Manifesto
On 11/6/07, Roy Tennant [EMAIL PROTECTED] wrote: I have a presentation coming up and I'm considering doing what I'm calling a Library Software Manifesto. It's a fine line between focusing people's attention on specific aspects of how to enter into and enforce contracts and dancing about architecture.
Re: [CODE4LIB] Library Software Manifesto
Thanks for providing your input Carl. I think is very good to get the thoughts on this issue form someone with your background. For those who haven't read it, even though it is a couple years old, I'd recommend reading the article that Carl Grant and Rolad Dietz published in Library Journal back in June 2005 on The Dis-Integrating World of Library Automation. It is available at: http://www.libraryjournal.com/article/CA606392.html Edward Carl Grant said the following on 11/06/2007 2:23 PM: I'm willing to jump in here as a long time vendor to add to the customer responsibility list some items that would make developers/ vendors a lot happier.. 1. Select software using a fair and reasonable process for both the vendor and the organization (one could say a lot more here!) 2. Make sure you know the needs of all users of the product (especially the END-users - get them involved! I promise, in most cases, their needs are NOT understood). 3. Acknowledge, accept and honor the deadlines that YOU bear in the development timeline. (The phrase teflon-customers comes to mind here...) 4. Understand that more functionality means more complexity in the code. This means: a. You've got to accept responsibility for helping to test software. There can be 1000's of pathways through code. We know you want bug-free code, but the developer/vendor can't test them all by themselves or you'd never actually get the code! b. If you're paying a commercial vendor to support/maintain, understand that costs should go up to compensate them for supporting that increasing complexity. 5. Try to standardize practices, **where possible**, between like institutions. Use development resources for great ideas, not just to support local idiosyncrasies... 6. Understand if you're trying to please everyone, it means lowest common denominator. If you're trying to lead and develop new ideas, somebody is going to be upset. It's not the developer/vendors responsibilities to decide which of these apply to your institution or what to do about it when it happens. Decide up front, are you following, or are you leading? Carl Carl Grant President CARE Affiliates, Inc. E:[EMAIL PROTECTED] M:540-529-7885 O:540-552-2912 866-340-9580 x 801 (Toll-Free) Website: www.care-affiliates.com Adium: carl_r_grant Skype: carl_grant On Nov 6, 2007, at 1:33 PM, Roy Tennant wrote: On 11/6/07 10:27 AM, Jonathan Gorman [EMAIL PROTECTED] wrote: 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 ;). Funny you should ask...I had originally intended to do this, but then I was wondering if it start to be redundant -- that is, would a number of points simply be restated from the vendor's viewpoint? But if there are unique points to make from that perspective it would be worthwhile to include them. This is an area where I consider myself even more ignorant than usual, so if those of you who work on that side of the fence would like to chime in with relevant manifesto points from the perspective of developers and vendors, I'm all ears. Thanks, Roy -- Edward M. Corrado http://www.tcnj.edu/~corrado/ Systems Librarian The College of New Jersey 403E TCNJ Library PO Box 7718 Ewing, NJ 08628-0718 Tel: 609.771.3337 Fax: 609.637.5177 Email: [EMAIL PROTECTED]
Re: [CODE4LIB] Library Software Manifesto
I really wish I could understand what you mean. I think I get the difference between a contract and its enforcement and software architecture, but is there a reason why these should not be addressed in the same talk? There is clearly something I'm not getting here, so perhaps further explication could help me to see it? Thanks, Roy On 11/7/07 11:24 AM, D Chudnov [EMAIL PROTECTED] wrote: On 11/6/07, Roy Tennant [EMAIL PROTECTED] wrote: I have a presentation coming up and I'm considering doing what I'm calling a Library Software Manifesto. It's a fine line between focusing people's attention on specific aspects of how to enter into and enforce contracts and dancing about architecture. --
Re: [CODE4LIB] Library Software Manifesto
Roy, WRT I have a right to the API if I've bought the product, would it be useful to add, maybe as a subpoint, I have a right to implement the API in an open source product even if I've signed an NDA dealing with that API? I understand vendor's (perceived) need for non disclosure statements, but one barrier to integrating vendor black boxes is not being able to proliferate their secret APIs. Mark Roy Tennant wrote: 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 -- Mark Jordan Head of Library Systems W.A.C. Bennett Library, Simon Fraser University Burnaby, British Columbia, V5A 1S6, Canada Voice: 778.782.6959 / Fax: 778.782.3023 [EMAIL PROTECTED] / http://www.sfu.ca/~mjordan/
Re: [CODE4LIB] Library Software Manifesto
Roy, While your rights are interesting, the consumer responsibilities I find are actually more important (and always more difficult to see followed). As some that develops software for wide public consumption (read, not developers but the computer illiterate in many cases), I find that points 1-3 are the most difficult for most people. Invariably, people don't really know what they want from an application -- just an idea of a workflow as to how something might have worked (or had learned) before. Likewise, most assume that if you just say, x doesn't work then as the developer you'll be able to decode the problem. Sometimes, I can decode the problem as the User (which tells me that what I'm doing needs to be more straightforward) -- other times, I rely on the user to provide as much information as possible to reproduce problems which can be like a trip to the dentist. I think our software vendors are in the same position. Many have fallen to sleep in terms of understanding what libraries want today -- but at the same time -- librarians have traditionally been, as a user group (I'm painting in broad strokes here), a bunch of whinners that really don't know what they want to begin with. Any library software manifesto that includes vendor responsibilies needs to equally highlight the responsiblities users have in this relationship (which looks like the direction you are going -- just don't undersell it). --TR *** Terry Reese Cataloger for Networked Resources Digital Production Unit Head Oregon State University Libraries Corvallis, OR 97331 tel: 541-737-6384 email: [EMAIL PROTECTED] http: http://oregonstate.edu/~reeset *** From: Code for Libraries on behalf of Roy Tennant Sent: Tue 11/6/2007 10:07 AM To: CODE4LIB@listserv.nd.edu Subject: [CODE4LIB] Library Software Manifesto 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
Re: [CODE4LIB] Library Software Manifesto
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
Re: [CODE4LIB] Library Software Manifesto
On 11/6/07 10:27 AM, Jonathan Gorman [EMAIL PROTECTED] wrote: 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 ;). Funny you should ask...I had originally intended to do this, but then I was wondering if it start to be redundant -- that is, would a number of points simply be restated from the vendor's viewpoint? But if there are unique points to make from that perspective it would be worthwhile to include them. This is an area where I consider myself even more ignorant than usual, so if those of you who work on that side of the fence would like to chime in with relevant manifesto points from the perspective of developers and vendors, I'm all ears. Thanks, Roy
Re: [CODE4LIB] Library Software Manifesto
Vendors need to guarantee that software development and support is not a factor of the software's life-cycle. Too many library systems products are being under supported presumably because the products are no longer generating new revenue for the vendor. I don't know how that fits into your manifesto, but I think it is worth mentioning in the context of this conversation... -- Andrew Ashton Systems Librarian Scribner Library, Skidmore College (518)580-5505 -Original Message- From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of Roy Tennant Sent: Tuesday, November 06, 2007 1:34 PM To: CODE4LIB@listserv.nd.edu Subject: Re: [CODE4LIB] Library Software Manifesto On 11/6/07 10:27 AM, Jonathan Gorman [EMAIL PROTECTED] wrote: 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 ;). Funny you should ask...I had originally intended to do this, but then I was wondering if it start to be redundant -- that is, would a number of points simply be restated from the vendor's viewpoint? But if there are unique points to make from that perspective it would be worthwhile to include them. This is an area where I consider myself even more ignorant than usual, so if those of you who work on that side of the fence would like to chime in with relevant manifesto points from the perspective of developers and vendors, I'm all ears. Thanks, Roy
Re: [CODE4LIB] Library Software Manifesto
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
Re: [CODE4LIB] Library Software Manifesto
some ideas for vendor's responsibilities: 1) Care for the software as a whole. This means sometimes not giving what your customers what in the short term to make a better product in the long term. 2) Care about the end user, despite whoever your customers are. Frequently they're not the same. 3) Make it easy for customers to request feature and report bugs. Work with them to do so, since it's appears extremely difficult for people to gauge what information is needed. I suspect it has something to do with the non-physicality of software and poor mental models of software. For some reason, people who would say Well, the engine makes a put-put sound whenever I accelerate, especially on hills. have difficulty saying Every time I try to send an email to these sites, I get this error message. They just say things like the email is broken or your website links aren't working. They seem to have a difficult time just giving details about what isn't working. Quick example, in an in-house web-application there's a report issues link. It takes you to a form that also lets you know that there's some diagnostic information being included about the current state of the application to help the developers. Frequently we can learn more from the diagnostic information than what the users supply. 4) Offer real information, not just marketing bull. Can I call you up and ask questions about how many developers you have? Projects they're working on? Timetables and goals? This is more a pipe dream than anything, I've never seen any vendor offer this amount of information. I can stand and watch my mechanic tinker, but I can't do the same with my software. 5) Keep your staff well-trained, review their work, and don't let things rot. Even if it means charging more money, because otherwise your company will become mediocre and depend on the inertia of existing customers more than expansion. Well, that's enough for now, I got other work to do ;). Jon Gorman Original message Date: Tue, 6 Nov 2007 10:33:33 -0800 From: Roy Tennant [EMAIL PROTECTED] Subject: Re: [CODE4LIB] Library Software Manifesto To: CODE4LIB@listserv.nd.edu On 11/6/07 10:27 AM, Jonathan Gorman [EMAIL PROTECTED] wrote: 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 ;). Funny you should ask...I had originally intended to do this, but then I was wondering if it start to be redundant -- that is, would a number of points simply be restated from the vendor's viewpoint? But if there are unique points to make from that perspective it would be worthwhile to include them. This is an area where I consider myself even more ignorant than usual, so if those of you who work on that side of the fence would like to chime in with relevant manifesto points from the perspective of developers and vendors, I'm all ears. Thanks, Roy
Re: [CODE4LIB] Library Software Manifesto
Hi Roy, Not sure how to make this succinct enough to be elegant (i.e. a bullet point) but... We have a large enough staff to break into software when necessary. A typical scenario is: We need a feature added (or bug removed) to make workflow tenable We request the feature (bug fix) We hear ok, thanks for mentioning it or known problem but have absolutely no idea the extent of the need, where it will be prioritized We wait a long while, give up, and develop a work around Two weeks after our success the company releases the feature/fix Essentially, I'd like to know the extent of the issue. If 90% of their customers have reported/requested I would like to know this. To avoid doing the devlopment locally to replicate something that will be coming (soon?). Many times the local devlopment makes life possible for a year or two, so it isn't fruitless. It's only when it turns out the whole world has been screaming, but the company doesn't want to acknowledge where it is on the list o'priorities. Maybe: - I have a right to access a prioritized list of what the developers are working toward. (except more elegantly phrased) Tim Roy Tennant wrote: 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
Re: [CODE4LIB] Library Software Manifesto
I'm willing to jump in here as a long time vendor to add to the customer responsibility list some items that would make developers/ vendors a lot happier.. 1. Select software using a fair and reasonable process for both the vendor and the organization (one could say a lot more here!) 2. Make sure you know the needs of all users of the product (especially the END-users - get them involved! I promise, in most cases, their needs are NOT understood). 3. Acknowledge, accept and honor the deadlines that YOU bear in the development timeline. (The phrase teflon-customers comes to mind here...) 4. Understand that more functionality means more complexity in the code. This means: a. You've got to accept responsibility for helping to test software. There can be 1000's of pathways through code. We know you want bug-free code, but the developer/vendor can't test them all by themselves or you'd never actually get the code! b. If you're paying a commercial vendor to support/maintain, understand that costs should go up to compensate them for supporting that increasing complexity. 5. Try to standardize practices, **where possible**, between like institutions. Use development resources for great ideas, not just to support local idiosyncrasies... 6. Understand if you're trying to please everyone, it means lowest common denominator. If you're trying to lead and develop new ideas, somebody is going to be upset. It's not the developer/vendors responsibilities to decide which of these apply to your institution or what to do about it when it happens. Decide up front, are you following, or are you leading? Carl Carl Grant President CARE Affiliates, Inc. E:[EMAIL PROTECTED] M:540-529-7885 O:540-552-2912 866-340-9580 x 801 (Toll-Free) Website: www.care-affiliates.com Adium: carl_r_grant Skype: carl_grant On Nov 6, 2007, at 1:33 PM, Roy Tennant wrote: On 11/6/07 10:27 AM, Jonathan Gorman [EMAIL PROTECTED] wrote: 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 ;). Funny you should ask...I had originally intended to do this, but then I was wondering if it start to be redundant -- that is, would a number of points simply be restated from the vendor's viewpoint? But if there are unique points to make from that perspective it would be worthwhile to include them. This is an area where I consider myself even more ignorant than usual, so if those of you who work on that side of the fence would like to chime in with relevant manifesto points from the perspective of developers and vendors, I'm all ears. Thanks, Roy
Re: [CODE4LIB] Library Software Manifesto
Original message Date: Tue, 6 Nov 2007 14:16:05 -0500 From: Tim McGeary [EMAIL PROTECTED] Subject: Re: [CODE4LIB] Library Software Manifesto To: CODE4LIB@listserv.nd.edu 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. At some point there simply isn't enough time/money etc. I think the flaw here isn't in priorities, but in the vendor being too broad in the first place. The drive of my point is more is that it's bothersome when a developer honestly decides that they cannot do the feature with their given resources. Then a customer pulls some strings and the manager tells them they have to get it done anyhow. Do this consistently and you start seeing things like training, support, and internal organization slip as you have developers waiting for the next sign from above. It's too dangerous to try to stick to schedules because of the likelihood of disruptions. I've had to deal with similar situations from several sides of the issue and it can be extremely frustrating. I'm not advocating that the number of people always be the sole basis of adding a feature of fixing a bug. I'd advocate a more complicated algorithm, similar to ones I've seen advocated by most software design books. This would count a couple of factors * Number of people affected * Severity of problem * resources required to solve problem * risk of not solving problem I've seen some differentiate this from severity, usually taking a more business like approach. So, maybe there's issues with screen readers. This affects a very small group of users. However, the impact on those users is quite severe. On top of that, it's likely an indicator of bad design since other tools. The risk of not solving the problem is also quite high from a legal standpoint. Compare this with some feature request that might really only apply to a small group, but has a workaround, even if uncomfortable. The severity is low, since they have an existing workaround. They're the only ones who want the feature. The cost of fixing it might be high, since it requires some redesign. 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. This is a huge issue. The library vendors are trying to be too many things to too many people. That's a deeper issue than customer responsibilities and a failing of the vendor. I just sent Roy some suggestions of vendor responsibilities, and that would have been a good one to add. (As well as the vendor has a responsibility to be open on decisions on these types of requests and future software development plans). There's an excellent chapter on this exact phenomenon in Alan Cooper's The Inmates are Running The Asylum. 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. Yeah, I think we're talking about the same thing here. The issue is with the communication process. It's the responsibility of the vendor to be open and clear in it's communication process. The customer should respect this. The clear communication should hopefully give the customer an idea too of what measures they have to take. Devote time to a workaround, try to revise their case for the fix, or simply accept it. Right now we're seeing the large library vendors having a host of features, including not doing things a long-term look at their software. This is leading to software created largely by political maneuvering and consensus. That's not the quite the same as evaluating needed features and bugs. Tim, the response I'm sending to the list is a bit different from the one I sent to you earlier. Some minor improvements and hopefully clarified a bit more, but the general thrust is the same. Jon Gorman
