Re: [linux-audio-user] SNR (not audio)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-user] SNR (not audio)
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Mon Jul 29 2002 - 23:29:10 EEST


On Mon, 29 Jul 2002, Malsky, Ken wrote:

> I have quite a bit of experience with digital audio software and a fair
> amount of experience with Linux (& other Unices). I stumbled across this
> group thinking I might learn something.

Welcome to the list!

> Throw me a bone! There are lots of other places where I can hear
> open-source frontier flaming. Is this list always this bad?

No, although during the last few months there have been a few suprisingly
heated threads. But this isn't just a bad thing - feedback is always a
good thing, even if it's very negative. This is especially important for
us who advocate Linux as an audio platform. Sometimes we are too eager
and give a bit too shiny picture of the current status of Linux audio.
This is bad for both users, developers and the whole Linux audio scene in
general. If someone is promised a totally problem-free change from
Win/Protools/whatever_professional_setup to a GNU/Linux setup, she has
a right to vent a bit.

Anyways, I must say that participating in free-software projects is a lot
more fun (and productive!) if you take the social aspect into
consideration. The best example I can come up with is a workplace
environment. In a way, the relationship between users and developers is
very close to the social networks (between peers) at workplaces.

Like people working for the same company&project, also free-sw users and
developers share the same goals (more and better software). Also, like in
the workplace, paying money (to your peers) is not a real option. This is
the _key_ difference to commercial software! But like in the workplace,
there are numerous ways to get people to cooperate with you.

For those with little or no experience in workplace politics, here's a few
tips :) ...

- market your own project to other departments (ie. advocate the
  free-sw project you are using or developing on mailing lists, web
  sites, etc, etc); getting more developers&users to the project will
  usually lead to a better and faster-improving software

- give positive feedback; anyone knows that even the most highly
  paid employees have a huge soft spot for someone who says
  thanks or otherwise shows appreciation; same goes for free-sw
  developers (and btw; this is not a one-way thing, users can
  thank developers, developers other developers or developers
  users - I've personally done all three quite a few times ;))

- challenge people; workplace: "hey, guys at department/company b
  have this new server platform that breaks our old record",
  free-sw project: "project b has support for LADSPA-defaults,
  that's really cool" (.. lead developer of app 'a' starts searching
  for the latest LADSPA API version ... :))

- lead by example; there are tons of things besides programming
  that needs to be done in free-sw projects; take one task
  and start working on it - you shouldn't expect to be treated
  as a VIP-user if you write a few paragraphs of documentation,
  but I assure you that the work you do _will_ have an effect
  on people working on the project [1]; most people get
  a motivation boost if they see other people working
  hard (assuming they have a common goal); it might sound
  strange that an end-user could lead by example, but I've
  seen it happen many times!

- ...

The bottom line is that there is no clear division between users and
developers. This is both a blessing and a curse (depending on how you look
at it). Making claims or demands rarely works, because among peers there
are no "customer is always right" motives involved... who's the customer?

But the good side of this all is that both developers and users have
_MUCH_ more power and influence. As a drastic example, if you don't like
how ecasound is developed, you can say "fu** off" to me and start a new
project that continues ecasound development (better known as doing a
'project fork'). You can for instance use linux-audio-dev and
linux-audio-users to bring similarly thinking people together and then
start the new project and I can do nothing to stop you. In other words if
I'm a jerk and don't listen to user feedback, the users can completely
bypass me. Because of this possibility it makes more sense to me to
cooperate with users of ecasound, so we all get a better application.

[1] Prime example of this is the ALSA project. I've seen quite few
    people start working on some non-coding-related tasks,
    but then become utterly frustrated as they got no positive
    feedback about their work (or usually, no replies to their
    questions on ALSA lists). This is very unfortunate as the
    work these people did _was_ very much appreaciated... the developers
    just were busy with the coding work (now playing - led zeppelin:
    "communication breakdown" ;)). Hopefully at least some of these
    people will re-join the project at some point...

PS Hmm, I guess we'd need to start maintaining "Free-software
   Survival Guide for Developer and Users".. ;)

-- 
 http://www.eca.cx
 Audio software for Linux!


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jul 29 2002 - 23:23:44 EEST