the-grey-tribe:

The adoption of the contributor covenant for the Linux kernel is a political gesture. It was Linus finally bowing to the threat of a media smear campaign. It will have a large impact on the climate among Linux kernel devs, but not because of the rules inside of the code of conduct. It’s more what the adoption of the contributor covenant means.

None of this is remotely controversial. The author of the contributor covenant has pushed open source projects to adopt it in order to have leverage to get people she disagrees with to stop contributing. She has gloated about gaining influence on her public twitter. She has written an anti-meritocracy manifesto.

Now you can disagree with the naive idea of “meritocracy“ in open source. But if you think about why “meritocracy” is not a good way to frame it, you shouldn’t just reverse it and say everybody is valid. This misses the point of “open source meritocracy”, and it also misses why “meritocracy” is a misnomer. You should not judge the character of a contributor when you decide whether to merge a contribution. You are valid, and maybe your code is valid, but if you want to express yourself in your code, play code golf, join the demoscene or write games! Some contributions are hard to maintain, and some contributions are formally correctbug-free, but not very useful.

Linux is not a small project where you can mail in a patch and get CVS commit access after a while if it cleanly applies and complies every time. Linux is not a project where you can send pull requests on GitHub.

Linux is a large project with a complex release schedule, many, many downstream projects, style guides, road maps, code review, sign-off and dedicated maintainers to different subsystems. Linux has multiple corporate stakeholders with competing use cases, and most of them can’t afford to maintain a long-lived hostile fork.

The new code of conduct is an empty gesture because it’s not a good first step, or a step in the right direction, but clearly and transparently woefully inadequate. But while the previous code of conduct was a defiant statement against regulating human behaviour, Linus acted like the contributor covenant can sole anything. It can’t.

How would we deal with the situation if Red Hat joined the BDS movement? What if somebody at Red Hat joined it? What do you do when somebody supplies falsified benchmark data to Phoronix to make somebody else’s proposed patch look bad? What if people act rudely in an official capacity on the forum of a downstream project? Does Linus still have to reject patches by a banned developer when they are signed off by a trusted maintainer?

Can Linus get a little mad when different employees of the same unnamed GPU manufacturer send in pull requests that load binary blobs, crash, and violate coding guidelines? Does the employer have to sign the code of conduct before employees can contribute in an official capacity? You’d think they would think this through.

Take these for example:

https://wiki.archlinux.org/index.php?title=Code_of_conduct&oldid=513170

https://nextcloud.com/code-of-conduct/

https://github.com/fantasylandinst/fcop/blob/master/CODE_OF_CONDUCT.md

https://github.com/rosarior/Code-of-Merit/blob/master/CODE_OF_MERIT.md

The first three codes of conduct in this list are much more detailed than the contributor covenant. The Arch Linux and NectCloud CoC’s are emphasising the common goals of the project and community, not just inclusion for its own sake. They explain what you should do and how, not just what not to.

The Code of Merit and FCOP are clearly reactions to the contributor covenant. The Code of Merit is more a manifesto than a code of conduct. The FCOP is the polar opposite. It’s more of a constitution. The FCOP is a comparatively fine-grained framework for conflict resolution, but it does not prescribe any kind of preferred mode of interaction or common goal. The FCOP and Arch CoC are relatively unambiguous and enforceable.

Now look at this, and tell me what should happen when somebody asks for help configuring CUPS on the LKML, and what should happen when somebody at Intel wants to break user space: https://github.com/torvalds/linux/commit/8a104f8b5867

The Linux Kernel CoC needs:

  • positive values
  • positive examples of expected and exemplary behaviour
  • additional rules for the rights and responsibilities of core developers and maintainers
  • a clear delineation between mainline and downstream
  • clarifications about the etiquette on the LKML, coding guidelines, commit messages, and what applies where. links to the other guides, and netiquette documents. reserve the right to ban people from the whole project for repeated violations of rules (top posting, three-space tabs)

Basically, link back to this page: https://www.kernel.org/doc/html/v4.10/process/index.html and add three sections to it about

  1. the goals of Linux kernel development; the complexity and multiple stakeholders; the importance of not breaking userspace for other people; interaction with downstream projects

  2. the preferred communication style (frank and to the point) that doesn’t waste maintainer time

  3. what spaces the CoC applies in (lkml, bugzilla, docs, code, linux foundation, conferences) and what additional rules can apply to these spaces

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s