[linux-audio-dev] Read this after your first cup of coffee

[John Check]

Good Morning,
Here's the position paper I drafted up. As usual I'll request that responses 
be well considered. I'll post this to my webserver after I have a chance to 
mark it up and hopefully, I can stop repeating myself and get things 
implemented. Apologies in advance for the length. Comments on what I propose
to do are welcome, but it may take a while for me to reply.

--------

Legitimizing Linux As an Audio Platform.

The current state of affairs WRT to Linux as a platform for audio production
is an open question, but in my considered opinion it is technically adequate
to start getting some real traction. At the current pace, there will be some
truly excellent applications in a years time, but it must be understood that
everybody has time limitations and not taking that into account is
counterproductive.

Bottom up penetration (simmer down now) is the most likely to succeed path,
however there are some issues which need to be addressed to improve on the
chances and avenues. These issues are outside of the scope of interest for
most developers. The pattern seems to be the people with the highest  level of
technical expertise are the least interested in these issues and that is as it
should be. Coders should code, EE's should handle the physics, etc. In short,
we all need to play to our strengths, especially since most of what goes on is
done voluntarily.

The issues that are playing against the community at large are not
insurmountable obstacles and I intend to do some heavy lifting to try and
change things. There are several phases to getting where we need to go, but
here are the primary stumbling blocks. First I'll layout the issues, which
fall into two categories, then I'll reveal my strategy for tackling them and
why I think these opinions matter. 

The Issues:

1) Too Much Information
	A) Unclear development status and suitability of offerings.
	B) Unreasonable requirements for list monitoring.
	C) To much time spent on repetition of information in the wrong places.
	D) Disorganized and inadequate documentation.

2) There's Only 24 Hours In A Day
	A) Unnecessarily high time requirements for building code to evaluate.
	B) A somewhat distorted sense of what musicians and pro audio need/want
	C) Nobody cares about Linux except the converted.
	D) No compelling business case.

Let's break it down:

Too Much Information
	Unclear Development Status And Suitability Of Offerings
	http://linux-sound.org

There is in excess of 36 categories of applications listed at the above URL.
The "Sound Editors" category alone has 35 entries just in it's "General" 
sub-category. Each of these has their own particular raison d'etre and
diversity is a good thing, but 3 of the first 10 listed projects according to
timestamps on tarballs, haven't had a release in over 12 months. Two of the
ten are Java based and one is a KDE app which means artsd.
This particular sub-category has a relatively good ratio of active projects,
but even so this means 7 pieces of software to evaluate when looking for a wav
editor. We could extrapolate that number, but 7 is a good start and it
includes some of the best candidates. 

	Unreasonable Requirements For List Monitoring

We've got 7 candidates for evaluation, 2 are unavailable as Debian packages.
This isn't a problem because I use Debian, it's just an example. This is two
out of 7 packages that need to be built from source. Again, it's not a problem
for me, but assuming the user isn't comfortable with that, we're down to 5 on
Debian and probably less on some other general purpose distros.

So we install our 5 binary packages and have a pretty good idea what they can
do, but if the user wants in depth info that's not covered in the
documentation that comes with the package it's time for mailing lists. Most
have at least 2 lists one for developers, one for users. That's potentially 10
lists subscriptions and 5 Wikis. 15 sources of information for 5 programs, not
counting the man page and whatever is in the help menu. 
The key to making the lists useful is participation. If there is no traffic on
the users list, it's a safe bet it's not because the programs UI is so
intuitive that nobody has a question. There is a threshold of tolerance for
user questions on the developer lists and that is also as it should be. 

	Too Much Repetition of Information In Too Many Places

See Unreasonable Requirements For List Monitoring ;)
There is an interesting corollary here with the LA lists. I'm guessing that LA
is supposed to be among other things, a sort of clearinghouse so that
everybody has a place to get an overview of the big picture. I have personally 
seen a developer quote one of his own postings to an LA list in order to
answer a specific on-topic question asked on his own project's list. 
Searching that project's list archive for this bit of info (which was pretty
crucial) came up dry until the question was asked on the project's list and
the person replying was helpful enough to find his LA post and answer what the
question was. Not only was that aggravating to watch, but it was duplicated
effort on the part of the developer answering the question.

	Disorganized And Inadequate Documentation

It is not reasonable to expect coders to spend a lot of time on documentation.
They can either improve the code or improve the documentation and even if we
disregard the moving target factor, the latter isn't playing to their 
strength. Theoretically at least, if a user has a question that's not covered
in the documentation and wants to help out, the coders will cooperate. The
tendency is for build related questions to be well documented but stale,
because Linux is a fast moving target with lots of parallel development and of
course, actively maintained code changes.

One common solution is to provide a Wiki so that users can maintain their own
documentation easily. This is a good way to accumulate information, but it has
its drawbacks. Chief among them is the requirement to visit the Wiki in order
to use it, which can be problematic. Additionally, it's not unusual for the
Wiki to not be accessible from the "Documentation" link and vice versa.
Wiki's, like the rest of free software development are participation driven,
which makes a good segue into the next part. If you had to look up "segue" pay
close attention.


There's Only 24 Hours In A Day

	I'll start out prefacing this by saying software is built for a purpose. If
        I'm looking for a new construction house, I 
	can buy one or build one. I may be a big Bob Vila fan and choose to build
        one, but that doesn't mean I'm a fan of 
	Roy Underhill and want to make my own lumber too. Or forge my own hammer and      
        nails. Given enough stress, and 
	wasted time,	I'll more than likely to bail and find a contractor to finish,
        or even go buy a built house. Even if it's not custom 
	and the roof leaks, the builder at least acknowledges the obligation to fix  
        the leaky roof. I suppose free software is
	more like an old fashioned barn raising, but anybody participating in one of   
        those sticks to what they can do and
	knows what a barn is supposed to be. Marble floors and a media center is nice
        in a building, but it doesn't keep
	the livestock dry. 

	Unnecessarily High Time Requirements For Building Code To Evaluate.

This is highly variable. Some projects have better build processes than 
others, and less bleeding edge requirements. As projects mature
things tend to improve, but not always. It's not unheard of for an early on 
decision to leave a legacy of problems that only become more
bothersome as time passes. It's not reasonable to expect this to change due to 
inertia, but these types of problems generate questions that fall into
the "it's obvious to me" category. It's also not reasonable to expect users to 
either fix it or eat shit and like it. If a user spends enough time with the 
doco 
and the list archives they can usually hash it out build problems, but there 
comes a point when one either has to go "Gentoo" and drink the koolaid 
because of the time invested. (I've been there and if you're a Gentoo user who 
wants to flame me, tell me you didn't _want_ to love it after the time 
invested to install it fully bootstrapped). Or, the user gets fed up and moves 
to another piece of software. That's known as "getting burned" and it 
doesn't generate goodwill. If it happens enough times it ceases to become a 
[G|K|X]foo problem and becomes a LA problem because unhappy
users complain loudly. Happy ones are mostly silent. 

What it has to do with LA is, people trying to use these programs for 
relaxation or to make a living with audio/music have time constraints too. 
One might be a tech in a going facility that got a green light to do some 
experimentation with LA when nothing else is going on, but if a paying client 
has a problem with the headphone system that the tech didn't get around to 
fixing because he was cocking around trying to find an answer to something 
that was "obvious to me" or even worse  figure out why "it works for me" and 
not him, guess which facility isn't going to be testing any LA software? 
A Bob Clearmountain or Bruce Swedien certainly isn't likely to spend the time 
tweaking out a system. 
This kind of thing can fly in a weekend project studio, but if you have a tech 
with that much time on his hands, you probably can't afford to pay
for deadwood, unless maybe you use the studio as a cover to launder money, in 
which case "free" _really_ has no place there. (If you just started
looking at the floor and shuffling your feet, I do consulting ;) 
On the other end of it (the low, low end ;) are schmucks like me who just want 
to gig, and while I have the time and the inclination to do this,
it still cuts in to rehearsal and promotion time, which means less work for me 
and less exposure for you. We need each other, so let's not be coy.

 	A Somewhat Distorted Sense Of What Musicians And Pro Audio Need/Want

Again, this is variable. Some applications, like Ardour and Jamin, would drop 
right into a professional setting, because they do 
what they're supposed to and the interface is what people who use these kinds 
of tools expect, even if they're not 1:1 knock-offs of commercial apps. 
Other tools like oh, say Ecasound, or Cecilia would flop, especially with the 
"prosumer" crowd that buys things like standalone HD recorders and synth 
modules. These apps may be technically excellent, but look at how many 
musicians can't even read standard notation! If these kinds of folks want to 
get
experimental, it's power it up and twist some dials and see where it goes. 
Neither one has an interface suitable for spontaneous creative monkeying.
Cecilia would fare better than ecasound in that scenario, but chances are 
anybody that could use either of them effectively to create traditional music 
is an EE or a CS by day. My intention is not to slam either of these apps. 
They've been around for a relatively long time for a reason; They work. 
They're just a tad esoteric for general use and fill a niche.
I'm not aware of any commercial software that does any of these things that 
doesn't have it's share of problems too. The tendency in professional
settings is to be conservative with revisions and put off updates until 
somebody else has tested them, or if they have on staff techs and a lab, 
stress
test well before inserting it in the revenue stream. The difference, when it 
comes to whether or not time spent getting support is worth the cost is 
simple. 
The vendor is obligated to come up with answers and the cost is quantifiable 
up front. If somethings not going to happen, they tell you. "We don't support
foo". You may hear "Foo will be supported in the next version" from marketing, 
but you don't see that on the homepage they way you see "Aims to support
foo, bar and baz" on a lot of sourceforge homepages.

	Nobody Cares About Linux Except The Converted.

They really don't. They care about quality and stability, sure, but just 
because it runs on Linux doesn't mean it's inherently stable or high quality. 
There's a joke among sound men and recording engineers that all the equipment 
runs on magic smoke. Once you let the smoke out, it doesn't work 
anymore. All that matters is that it works as advertised, and not just to the 
bean counters. A Windows power user that can put together his own
ProTools DAW isn't going to be real interested in feeling like a noob and 
getting flack because he's not comfortable patching kernels. They may not
even be comfortable getting DeMuDi up and running. It doesn't mean they're an 
idiot, it means they know their limitations. Fortunately, this particular nit 
is not news. Of course Macs are still solidly entrenched so that
has to tell you something.

	No Compelling Business Case.

Yes, I know, it's not about the money. Well, I hate to be the one to tell you, 
but as soon as you say "professional", it is. And let's face it, if you're
a core developer and you were offered a royalty or even a salary to do what 
you're doing for free you'd take it. There's no reason you shouldn't
benefit even if there's no legal requirement for a vendor to show 
appreciation. You wouldn't have a legal obligation to address the vendors 
requests
without a contractual obligation now either, would you?
Now that that's out of the way, let's consider the business angle from a 
potential user's point of view, relative to the standard arguments for free 
software.
	Joe Haxor: It runs on Linux!
	Mark Pigeon: What? On Lindows? I saw that in K-Mart, I wasn't impressed
	JH: You'll get a lifetime of free upgrades.
        MP: How often do these upgrades break file format compatibilty?
        JH: Almost never... Sometimes it happens, but somebody can write a
              filter.
        MP: Almost? What about my archived work?
	JH: And it will always be supported, because you can fix it yourself!
	MP: But I'm not a programmer. I took a course in BASIC when I was in school,
               but that was a while ago.
	JH: Basic huh? That must have been some school. That's okay though, you can
              always hire a programmer!
	MP: I'm not a software house, I do radio spots. 
	JH: Well, it doesn't cost anything, so you can pay the programmer per diem
              with what you save on commercial software!
	MP: Mmm lemme call my accountant. (ring ring, yack yack) He says custom
               software isn't deductible.
	JH: It's not custom!
	MP: Hang on (yack yack) He says it still not C.O.T.S. even before we modify
               it.
	JH: Tell him you can take the money you save on software and get twice as
              much hardware, that's deductible!
	MP: But then what do I pay for bug fixes with? And besides if I bring a
              programmer in they still have to wrap their head around the
              code.
	JH: AHA! You can hire the original programmer :D Now who better to fix the
               code than the guy who wrote it! :D
	MP: You mean the guy that implemented the bugs in the the first place? What
               happens if he gets hit by a bus?
	JH: Uh, well, um, there's a half dozen guys on the team and I know the code,
              so you can always hire me.
	MP: Well.. I guess thats true, but how do I know you'll be available? I'll
               tell you what, let's talk about hardware, now what's the
               warrantee like?
	JH: That'd depend on who you buy the hardware from.
	MP: I was thinking I'd buy it from you, since you're trying to sell me. What
              do you suggest?
	JH: Let's see.. you want a Foomax2k5 SMP board with a Flaprack googleplexer
              and 
	MP: A wha? Lemme ask you this, what's it cost per I/O channel?
	JH: Depends on what you want.
	MP: I want to go have lunch. Go work up 2 year lease price on 24 channel 
               system with a years support and 24 hr on-site emergency
               response and fax it  to  me when you have a number.
	JH: Why would you lease?
	MP: Okay, I have a business lunch to get to, let me walk you to your car.

The moral of the story: There is no such thing as free and people have things
to do.

So What's Your Plan Smartass?

	First thing is to improve the documentation factor to help make things easier 
for the brave. Right now it's a Gordian knot and here are what the scissors 
look like. I expect we all know what a MIDI implementation chart is. 

I'm going to whomp up a database driven reporting system that extends the 
concept to include protocol and library support and has some 
Wiki like features. One will be able to search for specific types of programs 
with specific criteria like:
Sequencers with LADSPA, JACK, DSSI, MESS, OSC, PHAT (Yes PHAT is that cool)
Hits will come back in table form with checkmarks in the appropriate columns, 
ranked by how much of a match and a "freshness" date.
The app name will link to the project site and there will be additional links 
to the primary documentation and the Wiki, if one exists.
There will also be a link to and reporting form for an MI chart. 
Forms will be radio buttons/check boxes/combo boxes. 
The only text input will be for URLs. This should minimize grammatical and 
language issues as well as make internationalization easy.
Links will be validated at a regular interval and 404's will generate an email 
to me, or if someone has taken responsibility for a project, that person.
Bounced emails to that address will be returned to me for further 
investigation.
This is intended for both developers and end users. It will take no more than 
5 minutes to file a complete report.
This may sound like a burden for the developers, but no more than a Wiki is a 
burden on users. I'll prime the pump with some reports on what I use myself. 
Newly interested users looking to help out on projects should find filing a 
report to be a good way to begin.

	This by itself isn't quite enough, but it's a start. I'm also planning on 
subscribing the system to the LAA list or possibly spidering
the list archive for announcements to get the ball rolling with automating 
some of the updating. As far as library support goes, I'm going to keep
a CVS tree of what I consider to be the cream that will be cron'ed to update 
daily, then recursed and diffed for new options in configure files. New 
options
will initially generate an email to me, and if all goes well will eventually 
report directly to the system.

I would appreciate any ideas on what should be included, but I'm not going to 
get into extended debates about what should be in. 
I'm the ultimate arbiter, at least until it debuts. The basic manual reporting 
and search should be live in 7-10 days.


What About The Business Angle Then, Donald Chump?

	That's the easy part. I'm laying the legal groundwork for becoming a vendor 
and support channel for turnkey systems. There is a lot of
money spent on this kind of stuff and if price is a factor, it only takes a 
few dollars difference. Anything more than that is counter productive. 
If you don't believe me, have a garage sale and put out a box of "free" stuff, 
then after an hour or two put "$1" on it people might haggle you down but 
it'll move.  
"Linux" will be on the last page of the brochure. If all goes according to 
plan the biggest chunk of revenue is going into R&D, which means to guys 
who've been doing heavy lifting on the core apps.
Anything they're not interested in gets farmed out, most likely on a bounty. 
Despite the apparent lack of popularity of the idea, it will have distributed 
processing as an option. This will allow for incremental penetration and 
interoperability with 
existing systems. Depending on the budget one has there are more ways to skin 
that cat than the plugin route. We have MADI support on the platform
for the high end and good old coax for low end applications like live FX 
processing.

And there you have it. Why these opinions should matter is self evident.