A History of LAD As Seen Through Heated Discussion
|
Warning
|
Summarizing years of discussions is a difficult task. I do not intend to distort the meaning of quotes and if you have a particular quote which you feel is being misrepresented please let me know. This article is designed to review the community as a whole, not impose my opinions onto it. Posts reflect the sentiment of the user at the time of posting and may very likely not reflect the current state of projects or even the authors |
What is LAD?
To get a bigger picture of what exactly has lead up to the current state of affairs within LAD I decided it was a good idea to read through some historic [LAD] discussions which made up some of those peaks in activity. This is somewhat more biased towards the flame wars and community rantings, but those discussions should still reveal plenty about the evolution of pain points within the community. First to frame this community analysis let’s look at how the linux audio mailing list officially defines its goal:
Our goal is to encourage widespread code re-use and cooperation, and to provide a common forum for all audio related software projects and an exchange point for a number of other special-interest mailing lists.
This simply shows that the mailing list should be a cooperative place and somewhere where information should be exchanged. Some medium like this is a pretty darn valuable resource and it was recognized as such early on.
The problem is that most Linux audio apps are developed by people who have full-time jobs doing other things. The problems involved in designing audio apps are so great that even those people who are able to work full time on Linux audio are often stumped as to how to implement the desired solutions.
With varying levels of success there have been some huge discussions about the tradeoffs for different plugin standards, session managers, licenses, knobs (boy do audio devs love talking about knobs), and a variety of other topics. Even with the advantages that something like a community mailing list offers, it’s questionable whether people really consider linux audio developers as a whole a community.
I think the linux audio world is too small and varied to have a tightly knit organisation like the Gnome guys.
If you want to organize something go ahead and organize it, but please don’t tell me that I have to conform to some consumer driven vision of the great commercial future of Linux Audio.
The notion of "the development community" is a misnomer. In fact, what we have are "development communities" (plural).
Fundamentally, the 'community' is made out of a large variety of independent individuals who need to have a large spread of specialization in order to make effective software. This typically has manifested itself with many different projects with single developers without a great sense of cohesion. This sort of hobbiest development has produced a lot of content, though overall workflow may fall short of users expectations and many projects are subject to bitrot after the small development team moves onto other projects. Everyone has conflicting ideas on how things should work:
Everyone has their point of view. It’s not like you will tell someone "I want to add this feature to your app/api" and will say "Ok". You will simply get an answers like: -No, sorry, I wont accept that patch, i’d rather the library concentrates only on this. -Why dont you do it as a separate library? -Feel free to fork this and add it yourself. -Yeah I recognize it’s useful, but I think it’s out of place, inconsistent with the rest, that I try to keep simple.
Before moving on to the issues presented in this community I want to take a brief detour showing how the linux-audio-dev mailing list and the linux-audio-user mailing list are linked. Within the overall community you frequently have developers who extensively use other LA tools and you have quite a few users who occasionally dabble in details generally reserved for developers. By looking at how many people fall into each one of these categories as a function of how often they post to LAD/LAU we can see that there is an overlap for casual users and a very strong overlap for heavyweight posters.
This overall trend also exists on a much smaller scale. Within any given month there is a significant number of people who have posted on both lists.
These individuals tend to generate a very significant number of the total posts in any given month as well.
By acknowledging this relationship, a good number of the problems observed on the LAD list should correspond to issues visible to users as well. In some cases like the 'What sucks about Linux Audio' threads there have been corresponding threads on both lists. In other cases ideas simply flow from one location to another.
Initial Friction
In the past it wasn’t all that unusual for these disagreements to leak onto the mailing lists where they could grow substantially. A good example of this friction would be the Impro-Visor forking effort in 2009. In this thread a fork of an existing project had been created due to GPL licensing issues, but the way the forking was done produced disagreement within the community.
One of the main reasons why R. Stallman started GNU/FSF/GPL because of it’s social aspect. You learn kids on schools for example to corporate and help each other, being social.
Forking a project is by it’s nature, and GPL "rights" aside, quite an impact on the author. He or she may have been sweating over their code base for some time, and i don’t think anyone could say they wouldn’t feel a bit awkward if they saw their code being forked, and developed further. Even more so for those who may not have developed their code under the assumption of GPL. From an "outsider’s" point of view, it would seem like a big decision to take both ways, if both parties have any sort of empathy.
The individual forking the project could be described as quite aggressive with his approach which did spawn quite the meandering discussion. This thread was one of the first threads in my reading of [LAD] which seemed to significantly put users off and it certainly didn’t help that in June a rather heated flame war on RealtimeKit had already driven away that project’s developer.
I have been following these list serves for a while, but I am just not interested in this kind of drama, and would like to mention for the record that I will no longer be following the lad or lau list serves.
In the last 18 months in LAD we’ve seen some pretty emotive flamewars about Reaper, LV2 in closed source software, LinuxSampler licensing, plugin output negotiation, JACK packaging, JACK and DBUS, PulseAudio, the way qjackctl starts up jackd, RTKit, and probably some other things I’ve forgotten. And this. This isn’t a high traffic list; the flames quite likely outnumber the rest.
So now is the time to give your positive feedback and constructive critics. Don’t troll and don’t start another flame war unless your goal is to alienate me to stage of me detaching from this community. I will not respond to trolish and flamish mails, feel free to contact me with private mails if you prefer so.
As these discussions scale out of proportion it’s easy for them to shift from a heated dialog into a flame war. These flame wars often result in huge misunderstandings, a lot of misinformation, tons of angry emails, and importantly wasted time. Wasting time on these mailing lists is a significant offence if they want to retain users and help keep the discussions targeted and helpful to those involved.
When Flamewars Aren’t Stoked
Of course these so called flame wars are not something which is entirely bad for a community to have.
Most of the occasionally 'caustic' folk in this community … understand that heated arguments are just a part of how developers find the best solution, and there is no ill will involved. It’s simply a useful tool/process - and arguably, I would say, the most effective way of hammering out good software design the world has seen to date.
Unfortunately there are always a few childish fools who don’t understand this concept (or think it’s a competition and can’t handle the fact that they were wrong) and elevate silly little arguments into long term personal grudges… Like trolls, they are best ignored while the rest of us get on with useful things.
What we’re looking for is less completely irrelevant noise like this. Particularly in response to jokes (blatant smileys and all).
When you have a heated discussion while keeping it on topic real work can be done, though it is often off-putting to bystanders and those caught in the middle.
When Flamewars Are Stoked
Generally for a lot of these flame wars to take flight there need to be a large variety of people stoking the flames and not directly contributing to the discussion in a meaningful way (though this is not always the case). In most threads this was done by a variety of users mostly ones who weren’t very frequent posters. There was one repeat offender who during July 2010 really caused quite the meltdown within the LAD mailing list, Ralf Mardorf. I originally wasn’t going to mention this, but essentially all flames and off topic communication that july could be traced back to him.
Who is Ralf Mardorf?
I never programmed anything for Linux. I’m not able to do it and I don’t have the time to learn it.
I subscribed to the list, because I needed some information when I tried to program for Linux audio. I guess you want people to learn how to program for Linux audio. What you’re looking for is an attitude test, not a test about programming knowledge. I’ve got knowledge about programming, not about programming for Linux. You don’t like my attitude, but I hope you like other people who have the attitude that you want, even if they don’t have programming knowledge. (This is another issue, but not that one OS might or might not be good, better or what ever, so I guess I should reply :p)
Btw. on user lists a user don’t get some needed information, e.g. actually about what kernel is fine with rtirq and what kernel isn’t fine with it, so it can become impossible to set up an audio Linux, another reason why I’m subscribed to this list.
I’m and other users are responsible for my/their Linux installations, we should use all available sources to get knowledge. Some, me too, do so. In addition now you expect from users that they also should have the same attitude?
And what happened in July?
Well, it started off in a discussion about MIDI jitter. This is something which can be quantified and discussed in terms of the numbers quite easily. Ralf brought the issue up which could imply some interesting bugs, design flaws, or configuration issues. Some simple tests to find the issue were proposed, but the data was never returned to the list resulting in posts such as:
I know very gifted musicians who do like me and they always 'preach' that I should stop using modern computers and I don’t know much averaged people. So the listeners in my flat for sure would be able to hear even failure that I’m unable to hear.
There is no objective valid timing fluctuation. The musical savant next door might be much more sensitive than I’m, regarding to the groove, I don’t know … I guess there doesn’t live a musical savant next door, perhaps I’m this savant ;).
Anyway, forget about my assumptions about ms of jitter. I’m fine with the C64, Atari ST and all those stand alone sequencers from the 80ies. I tested did it, but I’m sure I’ll be able to hear hear the difference to my Linux computer … not when listening to all MIDI instruments played alone at the same time, but when listening to MIDI instruments + audio tracks.
Sorry for this PS, I try to learn not to write such a high amount of mails :(, but it could be important.
Of course this was pretty frustrating to a number of developers who wanted to solve the problem at hand.
You are comparing a banana and an orange to find out which one is sweeter. Given the nature of the problem it would help a lot to have as little differences between the systems under test, otherwise it’s impossible to track it down.
We’re getting seriously off-topic here. After all, this is developer list. What happened to the ALSA MIDI Jitter measurements and test-samples?
This was followed up by numerous off topic threads. Ralf Mardorf ended up accounting for 44 of 463 posts in June and 165 of 653 messages in July. There are frequent replies to himself and if you look at the timestamps from that month there’s even a period where 7 emails are fired off to the list with no responses from anyone else among them. I’m honestly not sure if this is intentional trolling or not, but when a thread named "STEREO RULES" in all caps is created in the midst of the chaos you have to at least suspect it. Either way, this is just an illustrative example on how threads can spiral out of control and it is not necessarily representative of any of the individuals involved.
The sort of replies which can be seen in this month highlight some of the major issues at play. Developers generally want to know that their software works and that people can use it. They also crucially have very limited time considering that this work is typically done in addition to their other obligations without any return other than the enjoyment of it.
General Thoughts
So, up to this point in history flamewars have been a problem and they have been fueled by a number of individuals who intentionally or otherwise don’t contribute substantially to the original aim of the discussion. Both users and developers for linux audio software seem frustrated with this as it makes it difficult to obtain information, convey accurate information, and interact with other members of the community without wading through a lot of noise. Some of these issues are mirrored in more recent 'heated discussions', but this writeup is long enough, so that will have to wait for a part two.