I was reading over the ever wise Matt Zimmerman and his blog post about Listening to Users; in it he argues that user involvement is a nuanced subject and which approach the developer takes can be highly dependant on the timing, cycle and context of the developing project. Providing examples and some interesting comment.
I basically agree with these ideas, but I wanted to add something more to the economic thought.
I talk about user involvement here; I never mean users who are programmers, users who help support other users or users who turn into developers by their continued project involvement. For that subject see User to Developer evolution.
What developers want from users is fine communication on what the challenges and needs they are facing. They would like as much depth into the issues with as much detail on the specifics which cause issues. This communication is not actually in effort to help the user, but is instead a way to help the developer’s project. The user can see the bug or interaction as a way to get their immediate issue resolved, but the developer will be focused on collecting and filtering the relevant information and making tasks to push the project forwards.
Of course the user will still benefit in due course; but the user’s direct support needs are instead not met by bug reports, but by support type people who may or may not know the aims of the project. The goal for support people is to give the user instructions so that they can mitigate their issue and it isn’t about helping the developer. A wily support person will be able to turn a successful support request into a successful bug report which the developer can process and turn into a permanent solution; on the other hand a user or support person who is used to mitigation strategy, but not used to developer interaction will fail to tie the loose end of why the user needed support in the first place.
This can lead to the dreaded ‘toxic workaround’ which Tim Cole has given a talk about. This is a workaround which becomes so well documented and so ingrained in the culture of the users of a product that they fail to actually tell a developer to fix it. So the problem always remains causing issue for anyone new and causing users to go through extra steps to get usable systems. A good example of this is in Ubuntu support channels when people are asked to and expected to compile anything instead of the code being added to a PPA.
In order the listen to users, I think a developer must know the difference between supporting the user, and supporting upstream development; which may place conflicting demand on the developer’s time. The user for their part, if they get frustrated with reporting bugs that never get to be solved, can lash out at developers, ordering and demanding action should be taken and issues resolved.
Of course, if the user isn’t paying the developer to fix their issues, then the user has no right to ask any developer to work on their issue. The user’s only real power is that they can be of use to the developer’s aims in their project’s future refinement. This is because the developer is the one that holds the majority of the economic power. When a developer talks with a user, it’s clearly with an effort to solve the issues the user has brought up; but I think the developer is always thinking about what fixes will benefit the project the most and which users are the most useful to communicate with to achieve those goals.
What are your thoughts?
I think “paying the developer” is a very touchy subject here. While one is not necessarily giving a developer money to use their software, the user does invest their own time in trying to use it. If you’re developing software and making it public, it’s generally likely that you want to have users; otherwise you have no reason to publish it anywhere. If you refuse to fix a user’s issues because “they haven’t paid” for your software, then you’re only harming yourself AND your users.
@dobey – Yes and then again no, it depends. You need enough users to create a testing network and hopefully provide positive ego boosting praise. But beyond dunbar, I can’t see the value to the developer to accept being ordered around. Basically, I think I’m saying that it’s much more balanced and both users and developers have to pander to the human aspects of people in their respective situation.
Interesting, but I find these discussions tend to over simplify.
How often is it one simple app that has a defined problem. So many reports are cross system, GTK does not provide what user wants in end app, or interaction between kernel module and app. And then when is a bug a wish list?
Your “wily support person” is the most important link in the chain, if they can focus a discussion with all the people involved, then the right developer gets the feedback they need.
@Rodney Dawes “If you’re developing software and making it public, it’s generally likely that you want to have users;”
This is not *often* the case. I have published a bunch of software because it solves my problem and by publishing it, i can allow someone with a similar problem to save time by being able to _modify_ my software.
When enough developers modify the software and submit the changes, the developers no longer have to write that bit of software as it fits most use cases.
I gain nothing from someone using my software. I gain everything from developers modifying my software. Can you see the difference ?
This isn’t the case with all software but with alot of free software, the developer gets no benefit from people just using his / her software.