After Years of Abusive E-mails, the Creator of Linux Steps Aside (The New Yorker)

> 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.

The article reserves its strongest language to describe people who complain about the problems in the kernel community. Linus is "a harsh critic", messages on LKML are "inflammatory", but outsiders have "hostility toward the kernel community" and "a special toxicity", and people are afraid of "a threatening change pushed by people with a hostile agenda". (Yes, I'm aware that last one came right before trying to reassure people; you should know full well that saying "you might fear X but don't worry" still highlights X and frames the way X is described.) Defensive, us-vs-them, othering. You're demonizing those who complain or call attention to problems, while feeding into exactly the fears you're theoretically trying to quell.

For the record, I'm not suggesting that it was a bad idea to help reassure people who might well be unfamiliar with this kind of thing, especially those who are coming from a position of privilege and who haven't had to deal with as much of the kind of behavior that this change aims to address, and who wonder what they in practice need to *do*. Parts of that were well said, and needed saying. I'm not suggesting that you *should* "just roll over the very real fears that some people have". Explaining "what this likely means for you in practice" is *useful*. But consider the above, and consider the following:

> in the end, less may change than many expect or fear.

> 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.

Literally the first sentence after the fold starts out on the defensive.

> Critics of the kernel community have spent years calling for the establishment of a proper code of conduct.

This creates an "us vs them" tone, without observing that many of those "critics" are *part* of the kernel community, not outsiders.

> The adoption of a "code of conflict" in 2015 did little to mollify those critics

Right, because the problem is mollifying critics, rather than solving the problem?

> On the other hand, the kernel community continues to grow,

This is the kind of statement that has made the Linux kernel such a damaging bad example: it keeps growing, so why is there a problem?

> my beliefs that (1) the situation is not as bad as many like to portray it, and (2) things are getting better anyway.

> It was not the code I would have written

And by saying this you immediately start undermining it.

Perhaps you'd like to expand on what code you would have adopted? You have a golden opportunity to do so, since LWN could use one. Personally, I'd suggest using the same one the kernel does, for uniformity, for the same reason that projects should adopt GPL-compatible licenses rather than incompatible and/or custom ones. At the moment, LWN's approach towards toxic behavior in its own community comes across roughly like https://www.youtube.com/watch?v=W9ZD3_ppcPE .

> 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".

For the record, lest you think I'm criticizing everything here: this was well said, and needed saying. This *is* how some people feel the first time they encounter a code of conduct; among other things, they have to think about the discomfort that others regularly experience. That *can* be very uncomfortable to think about, but then, it's even more uncomfortable for those who go through it.

> Many bad experiences reported by developers are associated with crossing into a new neighborhood and unwittingly violating one of the norms in place there.

This is an interesting choice of phrasing. I would imagine you might have meant it as, for instance, coming into the kernel community and not following the conventions there (a variation on the old "lurk more"). But given that "norms" (especially in the context of communities or neighborhoods) tends to be most strongly associated with behavioral norms, this also comes across as highlighting developers who find themselves "unwittingly violating" the standards of behavior of one of the more friendly communities.

> Hazards

> Some, seemingly including the author of the Community Covenant, think that the kernel community may be a lost cause.

The tweet you linked to said nothing of the sort. The damage that *has already been done* isn't necessarily reversible. But the very same tweet says "That being said, let’s see if things get better from this point on."

> 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.

Already commented on above.

> 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

For the record: reporting on *these* "predictions of doom" seems perfectly reasonable. (Though I would have also quoted "real developers", since the false dichotomy there is very much an invention of those making such dire predictions.)

> 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.

This feeds directly into the fears of people who equate "don't be awful to people" with "you can't criticize or reject bad code".

> It is thus unhelpful that it was adopted so abruptly,

More undermining.

(And, of course, we now know why it was adopted abruptly.)

> It would have almost certainly been better to go more slowly

This has been needed for years. Cries to "go more slowly" ring rather hollow when absolutely *nothing* was done before. How many of the people popping up to complain now did anything, at all, to help? How many of those people did anything to improve the hostile environment that made people lose hope anything would *ever* change?

(And again, we now know why it wasn't done more slowly. Which is almost certainly going to lead to more people thinking "it would have been better if we weren't forced from the outside to improve". Personally, I wonder if without that outside impetus, anything would ever have changed.)

> on the other hand, any public discussion would have had a high probability of being an unpleasant experience for everybody involved.

Thank you for observing this.

More importantly, perhaps: such discussion would have had a high probability of either not actually getting anything done (design-by-incremental-evolution-with-small-patches does not work here), or of ending with something very much like the "Code of Conflict".

> in an attempt to show which effects it will (or will not) have

> the code of conduct might be seen as a collection of heuristics that never quite converge on what is really wanted.

Even more undermining.

> I think that some people wanted a piling on, another hit piece; I wasn't going to do that.

I certainly was *not* looking for anything of the sort. Complaining about an article being slanted in one direction does not mean I expected it to be slanted in the other direction. And I *do* think that a careful discussion of "what this means in practice" would have been a valuable contribution. You weren't wrong about there being people who don't fully know what this means yet, and who wonder how it affects them and what they might need to do or to change.

As an example, it might have helped to take some time to talk in more detail about how this doesn't mean accepting bad code, and doesn't prevent people from being direct and clear in their responses and criticism. Or talking about how the first response to problematic behavior in the community would typically be a reply, not a ban; the word of a kernel maintainer carries a lot of weight, and may hopefully be enough to help people rethink their behavior. So many things the article *could* have done to help people...rather than highlighting fears and hazards, undermining, and otherwise coming across as reactionary and defensive.

I think I can summarize my problems with the article by saying that it is defensive.

It quotes from Linus' apology and admission of doing harm to others, and then spends a lot of words to provide mitigations.

This is a bad way to report an apology for harm done. It weakens the apology. Political strategy people could probably explain this better than me, but this can be used as an intentional bad-faith tactic. It is best avoided.

Secondly you had the option to describe several significant reactions of some who were harmed; who were "possibly [sic] drove away from kernel development entirely". Or provide information about the harm. You decided not to.

You *could* have cut down the defensiveness, and be left with a newsworthy update. But the defensiveness and omission together make a terrible combination.

(I think I see defensiveness also in the section where you are most re-assuring about change. As you say, this is not the change you would have written, so you give justifications why you did not protest it at the time. As a reader, I had the impression you felt strongly about writing up the personal justification. My impression is those personal feelings did not help in writing a good article).

You relied on the apology and discounted "critics of the kernel community". But they correctly predicted there was an omission that was significant, and in fact what that omission was. A wisdom gained from harsh experience.

I'd like to read more from the Corbet who wrote: "I don't think we'll improve things by questioning the experiences that people are reporting. I'd much rather focus on how we can make things better without making them worse in other ways."