On mocking

There can be no doubt that the environment in our mailing lists, IRC channels, bug trackers, and other electronic communication channels can be intimidating and off-putting. Some developers handle such environments without trouble; others go away unhappy, and, perhaps, never return. Awareness of this problem has grown over the last decade or two, and, as a general rule, things have gotten better. Even so, one need not look too hard to find examples of harsh messages from high-profile developers. One might well wonder why such behavior persists.

One possibility is that the meritocratic nature of our community makes us willing to tolerate any sort of behavior in the name of technical excellence. We need top-level developers and will put up with unpleasantness if they can produce the code; as Rusty Russell once put it: "If you didn’t run code written by assholes, your machine wouldn’t boot." We want our machines to boot, so we have to accept the developers who can make that happen. There is almost certainly some truth to this claim; it is the same calculation that leads us to accept unpleasant politicians, doctors, managers, and plumbers.

That said, there is evidence that, in our community, we are becoming less accepting of such behavior than we once were. The recent changes in the GNU C library project could be seen as an example.

In the conversation following the LinuxCon article, it was asserted that the kernel development community continues to grow. That was put forward as evidence that things can't be all that terribly bad—the community is doing enough things right that people still want to be a part of it. Once again, there must be some truth to that claim. But it is also hard to imagine that the community is so rich in developers that it need not worry about those who do not handle the environment well. In truth, the community does worry about those developers. Improving the environment in the mailing lists and beyond is a perennial kernel summit topic, and has been the focus of a lot of private communications as well. For all its fearsome reputation, certain counter-examples notwithstanding, linux-kernel is a far more pleasant place than it used to be.

That said, one can still run into trouble on a list like linux-kernel, or in many other places. The previous LWN conversation hinted at a plausible reason for much of the remaining hostility: the lack of reviewer bandwidth. Any project that reaches a certain size tends to discover that it has far more people posting code and asking questions than people who review that code and answer the questions. Review bandwidth tends to be the limiting resource that slows the development process as a whole. Projects can try to deal with this problem in a number of ways; they can, for example, force developers to perform reviews to get their own code merged, or they can simply slow their process to the rate their reviewers can handle. A third alternative—skipping the code review step—has also been tried, but it tends not to produce pleasing results.

In this situation, anything that wastes reviewer time and slows the process further is going to be unwelcome. Additionally, code review can be a time-consuming, tedious, and thankless task; code reviewers are, as a result, often grumpy. Mercurial maintainer Matt Mackall recently described it this way:

Code reviewers often see the same kinds of problems over and over again, either because developers don't read the documentation, don't pay attention to previous discussions, or do not listen to the advice they have been given. When this happens, it is only human nature to strike out with strong words in the hope of making the irritation go away so that some real work can get done. This kind of response can be seen on the lists for a wide variety of projects.

Of course, one could just as easily argue that it's basic human nature to club one's neighbor with a rock to get at that nice stash of saber-toothed tiger bones in his cave. Anybody who has raised children understands how long it takes to learn to function properly in human society. So the fact that it's natural to strike out against mailing-list irritations does not mean that doing so is correct. Much of the time, it's the sort of impulse that we all (hopefully) learn to resist as we grow up.

As the free software development community has grown up, it has, indeed, learned to resist many of those impulses. We have become more adult, and more professional. Most communities tolerate far less unpleasant behavior than they once did; the kernel community can certainly be included in that group. For all the talk of public mocking, it does not actually happen all that often.

In the end, though, we live in a world that is not perfect. There will be people who come into our communication channels and call down impoliteness upon themselves; our world still contains trolls, people who feel entitled to free services from others, fanboys and fanatics who do not understand what "no" means, and those who simply refuse to listen. Some communities will respond to such people by trying to flame them off the list. Others might just quietly ban them from the list—an effective solution, but not necessarily a more civilized one. Not all who are flamed or mocked deserve it, but attempts to eliminate such behavior altogether risk being a cure that is worse than the disease.

In the end, there is value in having a sense of humor about things. It is not at all hard to find examples of developers being called morons or idiots on linux-kernel, but, much of the time, those developers are directing those words toward themselves. We are all morons sometimes; occasionally, we will get caught at it in public. Our community is usually quite accepting of those who understand when they've had one of their moments; it's those who refuse to listen who get the worst of it. Yes, we can do a lot better at dealing with each other respectfully, but, in the process, we should not close our community to real discussion, expect perfection, or lose track of how well we're doing now.