Lately, there have been many well-intentioned but I would contend misguided ideas proposed to handle noise on public programmer mailing lists. The premise is that in fact there are very important messages being drowned out in a chorus of irrelevant messages from ill-informed developers. Warnings of inefficiencies have been tossed about quite a bit as the curse of "bike shedding."
To understand what they mean by "bike shedding," one must know the bike shed parable. Once upon a time, a group of people got together to build a nuclear reactor to power the city. Everyone in the town said "great, we need more power," and so they got to work designing the plant. Everything was going great, the design of the reactor sailed by until one day, one of the citizens said "hey, let's build a bike shed for the workers so they don't have to come to work in cars and can get exercise." Everyone agreed until an argument broke out over whether to paint the shed blue or red. Eventually, the whole process broke down, and the plant was never built because they couldn't choose a color to paint the bike shed. The moral of the story: everyone agrees on the complex important things, but the process breaks down over arguments about irrelevant details.
I think we can all agree that this is a tragic parable, illustrating what happens when the process for decision-making breaks down.
When there is a problem of signal-to-noise ratio on a mailing list, the problem has to do with the process for accepting public input, I completely agree with this. However, I am troubled by the implication that having unmoderated mailing lists is the intrinsic problem with open source that must be solved. There is a crucial balance between rewarding quality and being open to the outsider that is the life blood of open source. You could even think of it as the "affirmative action" of the programming world: we recognize that amateur programmers who do not come from the establishment of the temples of programming in academic computer science departments or even computing careers, may have ideas that are better than the most learned highest karma achiever.
For my musician reader: Open source thrives on meritocracy: the idea that those who can do junk have more influence than those who can't do as much junk. Karma is the thing with which these individuals are rewarded. Only those with karma are able to actually make changes to the source code. It doesn't matter who you are, or what your background is, if you demonstrate good coding and community, you get karma.
String quartet rehearsal is similar, the best ideas get more weight regardless of whether the person who has them is playing the melody.
Why am I talking about string quartet rehearsal in a post about moderated programmer mailing lists? I come from a profession (professional chamber music) where "karma" is a fluid object, and unlike the programming world tends to break down when we attempt to nail it down. My string quartet has found that rather than try to decide who will be "the decider" for tough decisions, it's not just friendlier, but is also far more efficient to devote our individual energies to two essential things:
- always try to find the bigger picture
- always try to understand and respect everyone else's crackpot stupid ideas
Sometimes they are crackpot, but most of the time, the reason they just seemed crackpot because they were outside the boundaries of our collective imaginations.
An example: in our first years together, we occasionally would get into endless arguments in my quartet about whether to play a particular musical section faster or slower (PHP developers: think endless namespace separator arguments). After a long time of arguing about this, it usually turned out that we were asking the wrong question, until one day we would find the right question, which was something like "how long are the phrases?" (PHP developers: the right question turned out to be "how do we solve the ambiguity between static methods and namespaced functions?"). After finding the right question, we stopped arguing nearly as much, and the music sounded much better after we all re-adjusted our thinking.
This illustrates an important distinction: the question of how fast to play was not an irrelevant "bike shedding" detail, it was a crucial part of the solution. We still had to choose a speed to play, just as the nuclear power plant people still would need a place to put their bikes. By changing the question from "How fast?" to "How long is the phrase?" we were actually solving the question of what color to paint the bike shed at the same time we solved the question of how to design access to the nuclear reactor, not ignoring it.
The best solution is for those with the most karma to use this power to redirect unfruitful arguments towards larger questions that can lead to a more natural solution to the problem, not to limit external input and even conflict.
Perhaps the principal designers of the ill-fated hypothetical nuclear power plant would have done better to instead suggest that the bike shed be integrated into the reactor building. This would protect the bikes from the elements, and also require any bike thieves to go through security to get to the bikes - and eliminated the question of what color to paint the shed entirely without ignoring it.
It takes hard work and more than a little gut-wrenching conflict to resolve a truly important, difficult problem, and I for one, am willing to tolerate a little noise to find that gem which would otherwise be missed.
