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

[Jan Depner]

Damn.  That was all perfectly lucid.  I must be missing something ;-) 
Seriously though, it all makes sense to me.  (Sorry for top-posting but
I'm lazy).

Jan

On Tue, 2004-08-17 at 06:17, John Check wrote:
> 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.
>