[LAU] Linux Audio podcast. episode003: commenting replies

[J. Liles]

On Fri, Aug 16, 2013 at 1:57 AM, Gabbe Nord <gabbe.nord at gmail.com> wrote:

> If we move past the current arguments of "don't complain about free
> stuff", there's something pretty interesting to discuss that we all could
> benefit from; how do we make this better?
>
> From both a user and a developers standpoint, how do we make this
> interaction better? What can users do to provide better bug reports, and
> how should they be handled? Are there guidelines for most projects as to
> how users should report bugs? Can we simplify this bugreporting somehow for
> the user, and at the same time make it more powerful to the dev?
>
> What does developers think is lacking in this interaction right now? What
> does users think's lacking?
>
> One point Hermann made is that devs more or less only gets contacted when
> there's something wrong with their application. I can really see how that
> is, and that's very unfortunate. For me, one of the greatest draws to Linux
> Audio is the fact that I can so easily interact with the people who write
> the applications I use. A tighter community integration would be great for
> most people. We have forums like Linuxmusicians.com, which might be a bit
> more laid back than the projects official forums. Maybe we could try and
> use LM-forums as a gathering point for the community for real? If we make
> sure every project that wants gets its own sub-forum, getting together and
> both discussing as well as helping each other gets very easy. Any thoughts
> on that idea?
>
> For me personally as a user, I can subscribe to a lot of Louigi's
> thoughts. The applications I use more or less always has some fairly basic
> functionality that's either half or fully broken. Even if there's reports
> and a will to help debug, there's only so much one (or at best, a handful)
> developer can do. What's basic and a *must* functionality for me, might not
> at all be important to the rest. This is a reality, but can we make it
> better?
>
> Please feel free to answer any of my questions here. I'd love to hear what
> both developers and users have to say about this, as this is something that
>
>
The fact of the matter is, if you have a feature that is non-trivial,
critical to you, and not critical to others (especially the developer), you
have the following options:

1) pick a more appropriate tool. The natural instinct of a user is to
INSIST that the feature X they want should be integrated into software Y,
when really the feature may have nothing to do with Y at all, it just
happens to be the software they're working with at the moment. This force
should not be underestimated, as it is a very real effect and one of the
major causes of software bloat. Chances are that some other program exists
that was DESIGNED to do X and does it well. This is why we have DAWs that
burn CDs and text editors that play tetris and browse the web--and the
general result is a lot of software that does the same thing poorly rather
than a little bit of software that does it well.

2) make a convincing case to the developer (maybe even one not connected to
the project you want to change). Programmers work for free in a large part
because it can be fun. They will only work for free on fun things. For
unfun things, you have to pay them boatloads of money. If you have a
feature that you consider important--convincing the developer that it's
importand and interesting is going to be a lot more effective than just
whinging about how badly you need it.

3) pay for it. 60% of the time, it works every time.

4) Do it your own damn self. I'm dead serious here. This is how users
become developers. They identify a need that only they have, or in a domain
that only they understand well enough to devise a solution. Either by
patching existing software (a hell of a lot easier than you think!) or by
starting something from scratch (goodbye nights and weekends! but hello
personal improvement and satisfaction). Many great free-software projects
started out this way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20130816/d141b57e/attachment.html>