Re: [LAU] Linux Audio podcast. episode003: commenting replies

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Gabbe Nord <gabbe.nord@...>
Cc: linux-audio-user <linux-audio-user@...>
Date: Friday, August 16, 2013 - 4:53 pm

--047d7b5d474a27e33d04e4136df6
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 16, 2013 at 1:57 AM, Gabbe Nord wrote:

> If we move past the current arguments of "don't complain about free

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.

--047d7b5d474a27e33d04e4136df6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 16, 2013 at 1:57 AM, Gabbe Nord <gabbe.nord@gmail.com> wrote:
If we m=
ove past the current arguments of "don't complain about free stuff=
", there's something pretty interesting to discuss that we all cou=
ld 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 h=
ow should they be handled? Are there guidelines for most projects as to how=
users should report bugs? Can we simplify this bugreporting somehow for th=
e user, and at the same time make it more powerful to the dev?

What does developers think is lacking in this interaction right n=
ow? What does users think's lacking?One point Herman=
n made is that devs more or less only gets contacted when there's somet=
hing wrong with their application. I can really see how that is, and that&#=
39;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 applic=
ations I use. A tighter community integration would be great for most peopl=
e. We have forums like Linuxmusicians.com, which might be a bit more laid b=
ack 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 pro=
ject that wants gets its own sub-forum, getting together and both discussin=
g as well as helping each other gets very easy. Any thoughts on that idea?<=
br>

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 so=
me 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 o=
ne (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 t=
he matter is, if you have a feature that is non-trivial, critical to you, a=
nd not critical to others (especially the developer), you have the followin=
g options:
1) pick a more appropriate tool. The natural instinct of a u=
ser is to INSIST that the feature X they want should be integrated into sof=
tware Y, when really the feature may have nothing to do with Y at all, it j=
ust 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 ex=
ists that was DESIGNED to do X and does it well. This is why we have DAWs t=
hat 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 n=
ot 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 h=
ave a feature that you consider important--convincing the developer that it=
's importand and interesting is going to be a lot more effective than j=
ust 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 i=
n a domain that only they understand well enough to devise a solution. Eith=
er by patching existing software (a hell of a lot easier than you think!) o=
r by starting something from scratch (goodbye nights and weekends! but hell=
o personal improvement and satisfaction). Many great free-software projects=
started out this way.
=C2=A0

--047d7b5d474a27e33d04e4136df6--


Messages in current thread:
[LAU] Linux Audio podcast. episode003: commenting replies, Louigi Verona, (Thu Aug 15, 11:23 am)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, Leonardo Palomares, (Fri Aug 16, 5:58 pm)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, J. Liles, (Fri Aug 16, 4:53 pm)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, Fons Adriaensen, (Sat Aug 17, 10:00 pm)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, Fons Adriaensen, (Sun Aug 18, 11:25 am)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, Harry van Haaren, (Thu Aug 15, 11:42 am)