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.

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.

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.

The only text input will be for URLs. This should minimize grammatical and language issues as well as make internationalization easy.

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?

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.