Why The Linux “Code of Conflict” Is Broken

On March 8 2015, Linux instituted a “Code of Conflict,” outlining its expectations for community conduct around the code review process. The Code was presumably developed in response to years of criticism that the open source project’s culture is exclusionary and abusive. While on the surface the “Code of Conflict” looks like a positive step forward in fixing that culture, closer examination indicates more of the same old, same old:

It opens up with an ENTIRE PARAGRAPH of total refusal to engage the community’s historic, ongoing and well-documented toxicity.  

The “Code of Conflict” begins by mythologizing the community’s existing cultural norms around code review, sneering at “traditional” ways of developing software while enshrining Linux’s “very personal process,” which it claims are “proven to create the most robust operating system kernel ever.” It’s unclear what “very personal” means, but in the context of prescribing proper conduct, it reads as justifying years of systemic verbal abuse and personal attacks against contributors as the inevitable, if unintended, byproduct of a superior methodology. Insisting that Linux’s approach — oft-regarded as the most glaring example of hostility and toxicity in OS culture — is simply more “personal” and innately produces a better result, dooms efforts at culture change to failure. Rather than acknowledging the dysfunction in the community and its impact, the Code holds dear the existing culture and processes, in the process gaslighting community victims and critics by acting as if systemic problems don’t exist and/or critiques of them are not justified.

It’s full of the frameworks abusive technical communities use to justify their behavior.

If the charge Linux is responding to with this “Code” is years of exclusion and abuse, its *4th sentence* is telling: “Know that this happens because everyone involved wants to see the best possible solution for the overall success of Linux.” This is a time-tested strategy: justifying abusive behavior and systemic discrimination by claiming the end result is desirable and good… in this case, superior software. Opening up with such abuser logics in the very first paragraph contributes to the Code’s overall tenor of focusing more on justifying and upholding its culture (and gaslighting whistle-blowers and critics) than on acknowledging problems, taking responsibility and creating change.

It contains barely-concealed anti-diversity arguments.

True, the Code of Conflict never once mentions diversity, marginalized groups or systemic oppression (another clear flaw), but in a statement on the Code from Linux Foundation executive director Jim Zemlin: “It’s no secret that the software industry would like to see more diversity. The Linux Foundation believes in that. While this code does not address that directly, we feel it’s an important step to make clear that civil discourse is an important part of an open source community and to make it very plain that all are welcome.”

While diversity is not part of the Code or its stated goals, anti-diversity ideologies are clearly present in its statement that “we do not want to do anything to cause the quality of submission and eventual result to ever decrease.” Appearing BEFORE any discussion of unacceptable behavior in the community and avenues for remediation, this comment reinforces and centers the dangerous and erroneous, yet oft-purported belief of white-male dominated communities that better inclusion will result in a decrease in quality. In this manner, the Code panders to the false and invented fears (and feelings) of the community’s most homogenous segments, rather than asserting the importance of diversity and condemning the false equivalence to loss of quality.

It doesn’t give any transparency into the reporting process, the steps that will be taken by the governance body, or what enforcement of the policy will look like.

The extent of the Code’s commentary on resolution processes is: “please contact the Linux Foundation’s Technical Advisory Board at <tab@lists.linux-foundation.org>, or the individual members, and they will work to resolve the issue to the best of their ability.” It says nothing of confidentiality, what will be done with reports and who they will be shared with, or otherwise address any of the many valid reasons community members may feel unsafe reporting. It provides no insight into what will be done when reports are received, or if that process has even been thought through. It fails to outline any processes of enforcement – such as sanctioning or banning community members – that signal to the community it is serious about reports and action.

Additionally, it gives very little insight into what, exactly, is considered acceptable and unacceptable behavior, simply noting that it applies to any behavior which makes “anyone feels personally abused, threatened, or otherwise uncomfortable.” As noted in A Code of Conduct is Not Enough: “Especially when the organizers are not very clear about what they consider to be misconduct or a CoC violation, it makes the burden of reporting violations higher. Attendees are forced to speculate: ‘Will this organizer (who I don’t know, who I’ve never interacted with before) respond to my report seriously? Will they consider my report itself to be bad behavior?’” The Code feels sloppy, half-hearted, barely thought through and totally unsupported by a useful and effective process for addressing reports.

And For the Fiftieth Time: Bill and Ted’s Excellent Adventure is not a governance model.

Far too often, the tech community relies on the “be excellent to each other” maxim derived from the ‘89 sci-fi movie about time travel. Linux’s Code uses this as its closing sentence, immediately after asking contributors “strive to keep things civil and focused on the technical issues involved.” No, invoking feel-good slogans from old movies when your community is toxically broken won’t fix it. And insisting the community stays focused on the “technical issues involved” instead of the *cultural issues* clearly implicated isn’t a recipe for change. But in some ways, the Bill and Ted quote is the perfect conclusion to a Code that is in every way reactionary, anti-intellectual and ahistorical, clinging to a false utopian vision of the Linux community over its reality, and defaulting to ideologies that have long been rejected by the movement for better inclusivity and diversity in tech.

In summary: The Code Of Conflict reveals a Linux community and governance that refuses to keep up with the existing state of community codes of conduct, much less acknowledge and make substantial improvement on the deep, ongoing dysfunctions of its project and leadership. It is unlikely that the Code,  dwelling primarily on outdated slogans, self-serving mythology and anti-diversity propaganda, creates the proper conditions for culture change: namely honest acknowledgement of issues, validation of victims and critics, defined enforcement strategies and safe and effective reporting processes.