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 ;).
---- Original message ----
>Date: Tue, 6 Nov 2007 10:33:33 -0800
>From: Roy Tennant <[log in to unmask]>
>Subject: Re: [CODE4LIB] Library Software Manifesto
>To: [log in to unmask]
>On 11/6/07 10:27 AM, "Jonathan Gorman" <[log in to unmask]> 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,