Freely Fixing and Developer’s Time

Posted in Programming and Technical, Ubuntu on March 9th, 2011 by doctormo

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?

Tags: , , , ,

Ubuntu Manual Website

Posted in Programming and Technical, Ubuntu on March 2nd, 2010 by doctormo

I just found the Ubuntu Manual’s new website:

I’m getting a nice Ground Control website set up, Bret Allton who some of you may have seen here on planet ubuntu is doing it. It looks really nice and it’ll be very useful for showing off the ground control video and having a good place for the how-tos and classes when we run them.

So I think that having a project website is useful, more so than just the development page on launchpad or the blog entries here in my humble scratch pad.

What do you think about projects having their own websites? Do you think it adds value to a project?

Tags: , ,

Community Filtering and Disagreeableness

Posted in Free and Open Source Software, Ubuntu on February 23rd, 2010 by doctormo

This is an interesting comment to a previous blog post of mine:

I think there is a huge problem with the routes to contribution. There is a zero-requirement entry to Launchpad and Brainstorm, meaning that the small proportion of useful contributions are swamped by noise.

Ubuntu would benefit from a route to contribution that filtered interested and committed third parties capable of significant contributions. An excellent example of filtered contribution would be the recent article on kernel patching in Linux Format magazine (

In a practical regard I’m very impressed with the shear scale of development that the Linux kernel project manages to organise. It does have a very effective set of mechanisms for filtering contributions that intend to reduce noise and promote useful contribution over general chatter.

But, from my observations and the observations of other people, these filters primarily work through a social principle of being loud, obnoxious, aggressive and arrogant. Not to say that everyone is like that, but the culture certainly promotes those aspects. I don’t like contributing to the kernel project and I wonder why anyone else would bother to either. But that’s where the filtering comes in, you drive away so many people who would like to contribute, that only those who are hell bent on achieving a goal or are contractually obliged to would put up with it.

I remember asking an female kernel hacker (works for a big firm) one time about her experiences. I was rest assured that if it wasn’t for her companies requirement to work with the kernel project, that she would have no desire to contribute normally.

The Ubuntu community is quite different, the CoC means we can’t use unfriendly officious nastiness as a technical filter for poor contributors. We have to be a little better with our social skills, we have to encourage people, educate them and at the same time engage in tough love honesty so contributors know they’re work isn’t up to the standard, but we’d like them to continue to improve on it.

A hard balance to strike.

What are your thoughts?

Tags: , , ,