Zack's Kernel News

Zack's Kernel News

Article from Issue 217/2018
Author(s):

Zack describes recent discussions of the new Linux kernel Code of Conduct.

New Code of Conduct

There's been some upheaval in the kernel developer community lately over the issue of appropriate behavior. Linus Torvalds decided that his own harsh behavior towards developers over the years has been unacceptable. Essentially, he's yelled and cursed at developers on many occasions. We could say that this was a conscious management style or that his behavior was intentionally calibrated to the person he was talking to, but he's gotten a lot of criticism over the years, and had a sort of a wake-up call at the Kernel Summit, when some developers confronted him directly about those behaviors. So on September 16, he released version 4.19-rc4 and said he was taking a break from kernel development while he figured out the best way forward. That was his last post on the mailing list as of this writing, although he later approved a kernel patch that included a Code of Conduct for developers, essentially an update to the existing Code of Conflict that had been in the kernel since 2015.

There was a mixed reaction to these events. Some people, like Luke Kenneth Casson Leighton, felt it was a very good thing for Linus to acknowledge the problem and try to address it. He said, "I just wanted to say how amazed, relieved, and delighted I was to see what you wrote. That you recognized that you needed to reflect, *sought feedback*, and, most importantly, were willing and able to discuss that and ask publicly."

Luke also gave a bunch of links to materials about communication and conflict resolution. And he offered to recommend a "coach."

On the other hand, Opal Hart felt that seriously adopting a code of conduct would leave Linux open to sabotage by those with a political agenda. Opal said, "This Code of Conduct trend is nothing but a concern-trolling campaign that people carry out in order to gain control over projects, organizations, and communities. Everyone is best off if we do not give these people the control they desire. Take their demands with a grain of salt: They suggest a boilerplate Code of Conduct; you decide which parts from which Linux can benefit, if any."

She went on, "You, Linus, have never attacked anyone from what I have seen; you have only attacked poorly-decided actions, which is perfectly justified. People who really want to contribute to Linux dust their shoulders off, take your criticism, and figure out how to reapproach you depending on what they did that was not to your taste. Anyone who shies away from criticism is IMO unfit to contribute in the first place. I mean, yes, there are ways to get your criticisms across in a more 'constructive' tone, but this does not call for any code of conduct. Maybe you do need to take time to figure out how you want to approach the community, but don't take it that you *have* to do anything."

Michael Woods seemed to agree with Opal's assessment, saying, "Whomever convinced you to add the Code of Conduct was convincing you to give control over to a social justice initiative that has no interest in the kernel's core function or reason for existence."

He then provided a list of blog posts about this issue [1] by alt-right activist and blogger Theodore Beale [2].

Michael went on, saying to Linus, "If you start being 'nice' instead of forthright, every excuse in the mental health cookbook will be used to persuade you that emotions of the incompetent and their politics are more important than improving the kernel."

Pavel Snajdr felt that maybe the code of conduct was not as dangerous as Opal and Michael seemed to suggest. He proposed, "How about if we viewed the new Code of Conduct as about the same thing as BitKeeper was for the development process? It was not perfect, but was *something* for a start. And I believe that Linus will probably come back with a Git of CoC, or something in that fashion."

Elsewhere, Martin Steigerwald offered his own personal experience of dealing with difficult behaviors and responses. He said:

"During releasing a lot of limiting 'stuff', I found that probably nothing written or said can hurt my feelings unless I let it do so or even unless I choose (!) to feel hurt about it. So at times I am clear about this, I'd say: "I have chosen to feel hurt about what you did."

However in this human experience a lot of people, including myself, still hold on to a lot of limiting "stuff" which invites feeling hurt. We, as humankind, have a history of hurting each other.

During this releasing work, I also learned about two key ingredients of successful relationships: harmlessness and mutuality. I opted out of the hurting cycle as best I can. And so I choose to write in a way that moves around what from my own experience of feeling hurt I know could hurt others. I choose to write in a harmless way so to say. While still aiming to bring my point across. A very important ingredient for this is to write from my own experience.

Of course others can feel hurt about something I would not feel hurt about, and I may not be aware that the other might feel hurt about. That is why in such a case it is important to give and receive feedback. Still when writing from my own experience without saying that anything is wrong with the other, it appears to be unlikely to trigger hurt. That is at least my experience so far."

In response to this, Luke remarked, "It's interesting to me to note that you use the word 'releasing'. That's a keyword that I recognize from energy work, which, surprisingly is increasingly being recognized and used by individuals and businesses all over the world. It seems that people are beginning to recognize it's actually effective and no longer associated with cloud-cuckoo-land, 'detached-from-reality', new age hippies."

Meanwhile, Eric W. Biederman came from a different direction, offering a more technical defense of the idea that too much politeness might lead to bad code in the kernel. He said:

"At an implementation level, namespaces and cgroups are hard. Coming up with a good solid design that is very maintainable and handles all of the corner cases is difficult. Very few people choose to do the work of digging into the details and figuring out what is really needed.

This is not an area where you can hand-hold someone. It really takes people who are able to work out from first principles what the code will need to do.

Very often people will propose patches that do solve their specific case but only do 10% or maybe 20% of what is needed for a general kernel-level solution. For something that just works and does not cause maintenance problems in the long run.

Someone has to deep dive and understand all of the problems and sort it out.

That takes a person that is willing and able to stand up with all of the rest of the kernel developers as an equal. It requires listening to other opinions to see where you need to change and where things are wrong, but it also requires being able to figure things out for yourself and to come up with solid technical contributions.

[...]

I know many other maintainers get hit with such a stream of bad container ideas that they tend to stop listening. As their priorities are elsewhere, I don't blame them.

Also don't forget that most of the time to do a good implementation that it requires rewriting an entire subsystem to make it container friendly. Think of the effort that requires, especially when you are not allowed to cause regressions in the subsystem while rewriting it.

Further the only power a maintainer has is to accept patches, to listen to people, and to express opinions that are worth listening to. In the midst of doing all of those things a maintainer's time is limited.

[...]

Because maintainers have a limited amount of time there are no guarantees how much we can help others. We can try, but people have to meet maintainers at least half way in figuring out how things work themselves, and sometimes there is just not enough time to say anything. As the old saying goes: 'You can lead a horse to water, but you can't make him drink'.

So there are no guarantees that people won't be demotivated or that they will learn what is necessary. All that we can do is aim to keep conversations polite and focused on the technical details of the project. Which should keep things from getting unpleasant at the level of humans interacting with humans. I don't think that will give you greater guarantees beyond that."

Meanwhile, Enrico Weigelt felt that the Linux kernel project was in danger of a social engineering attack against it, in the form of the Code of Conduct. He said, "I really don't see any conceptional deficiencies in the way the Linux kernel community worked in the last decades. Actually, it worked very, very well. It created the best general purpose OS kernel in known history, that scales from small embedded to big clusters. And this has *VERY MUCH* to do with how the community worked for the last decades. IMHO, it's even the primary reason. Not having to care about personal behaviors, corporate hierarchies, marketing, whatnot, only care about technical excellence. Nothing more, nothing less."

Regarding specifically the Code of Conduct, and the sense that it might be a good beginning that could be modified later, Enrico said:

"That sounds like the typical corporate manager's/politician's behavior pattern: There seems to be a problem; we need to do something fast – doing nothing is worse than not doing anything quick enough.

Yeah, that's exactly what I'm regularly observing with my clients (the bigger the corporation, the worse). And that's exactly why so many of their projects fail so miserably, and products are such a crap.

I really hate the idea of the Linux community falling into the same trap. (Many of the GUI projects already did, and their code is crap.)

The best thing, IMHO, is to totally ignore any kind 'social rules' and focus on the actual technical goals. And don't take anything here personally. *If* there really happen [to be] some ugly personal attacks, we can talk about that on a case-by-case basis."

As you can see, there were a lot of different ideas in this thread. One thing is certain – the old ways are changing, and Linus will implement something new in their place. That doesn't necessarily mean a Code of Conduct or anything else that's been mentioned so far. But at the very least, it does mean that Linus's old justifications for his own behavior will probably disappear, and he will personally adopt a new "code of conduct" just for himself. If it follows earlier modifications to the kernel development process, it will probably start out with a few basic and obviously good ideas that will be tweaked over time.

That is really what Linus said in his announcement – he was going to take some time to examine his own behavior and come up with a way to address the issues that had emerged.

Virtually none of the mailing list discussion addressed that at all. There's really nothing to address until he comes back. The mailing list discussion was almost exclusively in response to the Linux Code of Conduct (see the box "Contributor Covenant Code of Conduct") that replaced the earlier Code of Conflict (see the box "Code of Conflict") that was added to the kernel tree in 2015.

Contributor Covenant Code of Conduct

Our Pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

Our Standards

Examples of behavior that contributes to creating a positive environment include:

  • Using welcoming and inclusive language
  • Being respectful of differing viewpoints and experiences
  • Gracefully accepting constructive criticism
  • Focusing on what is best for the community
  • Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

  • The use of sexualized language or imagery and unwelcome sexual attention or advances
  • Trolling, insulting/derogatory comments, and personal or political attacks
  • Public or private harassment
  • Publishing others' private information, such as a physical or electronic address, without explicit permission
  • Other conduct which could reasonably be considered inappropriate in a professional setting

Our Responsibilities

Maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.

Maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

Scope

This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project email address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the Technical Advisory Board (TAB) at mailto:tab@lists.linux-foundation.org. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The TAB is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.

Maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.

Attribution

This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html.

Code of Conflict

The Linux kernel development effort is a very personal process compared to "traditional" ways of developing software. Your code and ideas behind it will be carefully reviewed, often resulting in critique and criticism. The review will almost always require improvements to the code before it can be included in the kernel. Know that this happens because everyone involved wants to see the best possible solution for the overall success of Linux. This development process has been proven to create the most robust operating system kernel ever, and we do not want to do anything to cause the quality of submission and eventual result to ever decrease.

If however, anyone feels personally abused, threatened, or otherwise uncomfortable due to this process, that is not acceptable. If so, please contact the Linux Foundation's Technical Advisory Board at mailto:tab@lists.linux-foundation.org, or the individual members, and they will work to resolve the issue to the best of their ability. For more information on who is on the Technical Advisory Board and what their role is, please see:

http://www.linuxfoundation.org/projects/linux/tab

As a reviewer of code, please strive to keep things civil and focused on the technical issues involved. We are all humans, and frustrations can be high on both sides of the process. Try to keep in mind the immortal words of Bill and Ted, "Be excellent to each other."

Infos

  1. Woods, M. 17 September 2018. Reply to Linux 4.19-rc4 released, an apology, and a maintainership note: https://lkml.org/lkml/2018/9/17/1147
  2. Theodore Beale: https://en.wikipedia.org/wiki/Vox_Day

The Author

The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News