Conflict over a code

It should be emphasized that these are your editor's thoughts; they are not representative of anybody else. The Linux Foundation's Technical Advisory Board (TAB), which is named as the resolving body in the code, and of which your editor is a member, does not even know the article is being written. Even your editor's dog has requested an explicit disclaimer stating that these are not her opinions. But, then, the dog's opinions are mostly concerned with whether something is edible or not.

Perhaps the most surprising thing from your editor's point of view is the articles portraying the code as directly aimed at Linus Torvalds; expressions like "slap down" or "rein in" are not hard to come by. One particularly amusing piece saw it as a deliberate attempt to undercut an "over the hill" Linus and, presumably, take his place. In fact, Linus was given the opportunity to comment on the code and was, of course, the person who merged it into the mainline. It would be unusual for somebody to cooperate in his own reining-in in this way.

If the behavioral problems on the kernel mailing lists could be solved by muzzling one person, the issue as a whole would be much more easily dealt with. But that is not the case here; opinions differ on how large the problem in the kernel community really is, but it is a rare participant indeed who thinks it comes down to a single individual. Attempts to change the way a community behaves generally require addressing the community as a whole; that is what the code of conflict is attempting to do.

There is another line of thought that sees the "code of conflict" as a no-op statement with no teeth. What your editor has heard from a number of sources is that the code looks like an attempt to paper over the problem without actually doing anything about it.

This code does differ from the codes of conduct adopted by a number of other projects. It states from the outset that conflict over technical issues is a part of how the kernel community works. It lacks a list of specifically prohibited behaviors — something that a number of critics have pointed out. There is no list of specific sanctions that can be applied to developers who are deemed to violate the rules, whatever they turn out to be. The code places the onus on the target of abusive behavior to raise the issue with a distant group of ten developers who may or may not have this person's trust. All of this, to some, means that the code is not designed to actually bring about any real-world change.

From your editor's understanding, the list of unwanted behaviors was left out for a couple of reasons: to keep the code short and comprehensible, and to avoid attempts to play games around the edge of the rules. So the actual rule is short and simple: participants are not to be made to feel "personally abused, threatened, or otherwise uncomfortable". The assumption is that targets of abuse can tell whether they feel abused without having to check a list of specific behaviors. The concern that such people may be more reluctant to complain without a specific rule to point to may have more merit. The good news is that the community is full of sharp-eyed observers who are likely to blow the whistle on poor behavior even if the target feels too intimidated to do so.

With regard to specific sanctions, there are limits on what can be done. Those who abuse the kernel mailing lists can already be banned; that has recently happened, for example, to some of the persistent systemd trolls who tried (unsuccessfully) to stir up flame wars recently. There is no community process that could, say, remove an abusive subsystem maintainer from that role. One could imagine that the TAB might advise such a course in an extreme case, but it would be up to Linus to actually carry it out. Hopefully, though, the bulk of any problems raised under the code of conflict can be resolved without resorting to punishments or the threat thereof.

At a different extreme, there are those who see the code as the beginning of the end for the kernel community. In this view, the code will curtail debate over code submissions and lead to a lowering of quality standards overall. In talking to many people about this code, your editor has noted that even those who feel most strongly that it should be more explicit and have sharper teeth do not say that it should become easier to get code merged into the kernel. It seems relatively safe to predict that anybody who complains that their code was rejected on technical grounds will be advised to address the issues raised and try again. There is no reason to believe that the standards for kernel code will be lowered.

Years of writing for LWN have given your editor a (possibly twisted) standard for success: if people on all sides of an issue appear to be equally unhappy with an article, it was probably reasonably fair. By that metric, the code of conflict may well be deemed to have gotten things about right: the complaints from the "it's business as usual" and the "it's the end of the kernel" camps both seem loud. At this early stage, it would have been hard to do better than that.

That said, those who see this code as an exercise in being seen to be Doing Something are probably not entirely off the mark. Doing Something does not always turn into "having done something useful" over time. The real value of this code can only be seen going forward. If it empowers the targets of abusive behavior to speak out, and if it helps to bring a resolution of such situations and end that behavior, it will be a success. If so, the kernel community should become a kinder, gentler place, though, in truth, that has already been happening for some time.

A few years from now, we might just look back on the kernel's code of conflict as an inadequate, failed response. But it is far too soon to predict that with any degree of certainty. The thing to do for now is to give it a chance and see if problems arise that the code's process fails to address adequately. As Linus said when he merged it: "Let's see how this works". Even your editor's dog would agree, especially if it came with something to eat.