Code, conflict, and conduct

Some time off

Torvalds has always been known as a harsh critic; what perhaps fewer people have seen is that he has always been willing to be just as harsh toward himself when (in his opinion) the situation warranted it. He has seemingly come to the conclusion that some self-criticism is indeed called for now:

Torvalds went on to say that he will be taking a break from kernel work at least through the end of the 4.19 development cycle — which should come in around four weeks. Greg Kroah-Hartman will be handling pull requests during this time; he has already done a number of pulls as of this writing. Torvalds, meanwhile, will "get some assistance on how to understand people’s emotions and respond appropriately". He expressed a strong wish to continue leading the kernel project once things settle, and said that he was "looking forward" to meeting with the maintainer community at the Maintainers Summit at the end of October.

As for what brought this moment about, we may never know for sure. He talks about being confronted by members of the community, but people have been telling him for years that some things should change. If somebody did get through to him this time, they did it privately. In any case, we seem to have arrived at, as Torvalds put it, one of "the inflection points where development flow and behavior [change]". Sometimes, perhaps, it really is just a matter of waiting for the right moment when change becomes possible.

The response to this announcement on the net as a whole has, as one might imagine, covered a wide spectrum. Some people like Torvalds just as he is and do not welcome any change, while others are quick to say that he is beyond redemption and probably cannot change. Most people, though, seem to recognize an individual confronting some internal pain and are waiting hopefully to see what comes next. We wish him the best and look forward to his return.

A new code of conduct

Critics of the kernel community have spent years calling for the establishment of a proper code of conduct. The adoption of a "code of conflict" in 2015 did little to mollify those critics, many of whom saw it as, at best, an empty gesture that would change little. Judging three years later whether they were right is harder than one might think. There is little in the way of hard evidence that the code of conflict brought about any changes in behavior. On the other hand, the kernel community continues to grow, and most of the approximately 4,000 people who contribute each year have a fine experience. The web sites that specialize in publicizing inflammatory messages found in the mailing lists have had to dig harder than in the past. Perhaps the code of conflict helped to moderate behavior a bit, or perhaps we are just seeing the slow, long-term trend toward professionalism that has been evident in the community for at least two decades.

Attentive readers will note that my name appears as one of the signoffs on the patch adding the new code of conduct; they might wonder why I chose to do so despite my beliefs that (1) the situation is not as bad as many like to portray it, and (2) things are getting better anyway. Over the last weekend, I was informed that there was a window of opportunity to change the code and given the chance to comment on the new one. How or why this window came to be is still not entirely clear; I did not know about Torvalds's plans until I read the announcement along with everybody else. I saw the new code as a way of encouraging the community's slow drift toward greater civility. It was not the code I would have written, but I agree with the principles expressed there and believe that it can be adopted and used in the pragmatic manner in which the community approaches most problems.

One of the strongest criticisms against the old code of conflict is that it did not enumerate the types of behavior that are unwelcome. The new one cannot be criticized on that account. Such laundry lists of misbehavior can leave a bad taste in the mouth; that can be especially true if, like me, you are an older, run-of-the-mill white male; it is easy to look at a list like that and say "everybody is protected except me". It can look, rightly or wrongly, like a threatening change pushed by people with a hostile agenda.

But the purpose of such a code is not to threaten anybody; indeed, it is the opposite. It is a statement that we all have the right to be who we are and participate in the community as equals without having to contend with bullying, abuse, and worse. Posting a patch should not be a frightening experience. The code of conduct is a way of saying that, if we drive away contributors with a hostile environment, we don't just impose a personal cost on those contributors; we also make ourselves weaker as a community. Not even the kernel community, which still attracts at least 200 first-time contributors in each development cycle, is so rich that it can afford to lose talent in that way.

I can also understand a hostility to rules. I grew up in a small Wyoming town that had a sign reading — literally — "Population: 35". There is little need for formal rules in such a place; there are no strangers and everybody knows that they have to get along for many years into the future. Every such town has some eccentric and difficult personalities; people learn how to cope with them.

Cities do not run the same way, though; cities need rules. There are too many people coming from too many different backgrounds to just get along without some sort of framework. The kernel community is the free-software equivalent of a city at this point. It has grown hugely, and is divided into a number of neighborhoods, some of which are rather friendlier than others. Many bad experiences reported by developers are associated with crossing into a new neighborhood and unwittingly violating one of the norms in place there. There is a place for some city-wide rules on how we deal with each other so that such bad experiences become much rarer.

The early O'Reilly books about Linux, including mine, used a wild-west cover theme for a reason. But the kernel community is not the wild frontier that it was back then; it has become a far more disciplined, professional, and even welcoming place. In the end, my hope in signing off on the new code of conduct was that it would drive home the point that we are no longer the wild west, that it would encourage further progress toward civility and professionalism, and that it would help the kernel community continue to scale into the future. Those of us who work on the kernel tend to be in it for the long term; we want the community ten years from now to be better than what we have now, because we expect to still be a part of it.

Hazards

One need not look far to find predictions of doom in many flavors. Some, seemingly including the author of the Community Covenant, think that the kernel community may be a lost cause. There is, among some people, a sort of hostility toward the kernel community that brings a special toxicity of its own; there is little to be done about that. On the other hand, plenty of people — generally not those with a lot of contributions to their credit — claim that the adoption of a code of conduct will force developers out and be the beginning of the end of the kernel project. Now that the "social justice warriors" have taken over, the real developers will flee and it will all collapse into a heap.

That outcome seems unlikely, but there will indeed be challenges in adopting this code in such a large community. The nature of kernel development requires relatively high levels of pushback on code submissions, many of which will not be merged in anything resembling their current form. It attracts passionate developers with strong opinions who do not always understand the need to create a kernel that works for a huge and diverse set of users. It attracts developers who are trying to solve problems above their technical ability — perhaps at the direction of their employers. Kernel developers care deeply about the kernel itself and are unwilling to stand by idly if they see changes that threaten to make the kernel worse. And the kernel, perhaps more than any other project, is surrounded by a vocal community of onlookers with opinions on every move the community makes. These are all the makings of a relatively high level of conflict.

The community as a whole will have to find a way to implement the code that handles the community's inherent conflicts without collateral damage. It is thus unhelpful that it was adopted so abruptly, without a community-wide discussion; that will not sit well with some developers. It would have almost certainly been better to go more slowly, and involve at least the invitees to the Maintainers Summit; on the other hand, any public discussion would have had a high probability of being an unpleasant experience for everybody involved.

It seems almost certain that some people will try to test the boundaries of this code and its enforcement mechanisms in an attempt to show which effects it will (or will not) have. Neither the boundaries nor the consequences for crossing them are particularly well specified at this point. Some parts of the code do not entirely seem to fit; it's not clear that the kernel project can even have an "official social media account" or an "appointed representative", for example. Those who end up enforcing this code will have to handle complaints with great care, protecting members of the community while fending off those who might, as some seem to fear, attempt to use the code to further an unrelated agenda.

The written code was changed with a single patch; implementing that code may be a rather longer and harder process. Like the kernel's out-of-memory killer, the code of conduct might be seen as a collection of heuristics that never quite converge on what is really wanted.

That said, the chances are that what will emerge from the dust will be something that looks like the same kernel community that has achieved so much in the last 27 years. Only hopefully it will be a bit friendlier, a bit more diverse, and much stronger. This could indeed be one of those inflection points mentioned by Torvalds in his announcement; the kernel has always emerged from those episodes stronger than ever. It is hard to see any reasons why this time should be different.

Did you like this article? Please accept our trial subscription offer to be able to see more content like it and to participate in the discussion.