Twelve days ago Linus penned a lengthy addition to his release notice of the Linux 4.19-rc4 kernel. During a previous discussion about when and where the next Kernel Summit meeting would be held Linus suggested the meeting could take place without him. He was overruled, but apparently it got some people, including Linus, thinking and planning.
Many years ago Linus posted a "Code of Conflict".
What's changed? Linux kernel development has changed from a meritocracy base (which had no gender, religious or racial overtones) to one of political correctness, which does. To effect this change the Linux development project has adopted a Contributer's Covenant, adapted from the Code of Conduct.
The attack on Linus started in earnest five years ago when Sarah Sharp criticized his management style and made sex and racism an issue, while various social justice warrior sites began criticizing meritocracy as a method to obtain high quality code.
(Sarah Sharp is the author of the Linux USB 3.0 host controller driver.)
Torvalds replied:
The correlation with Linus stepping down and the immediate adoption of a code of conduct has many Kernel developers concerned. A msg was posted on the Kernel mailing list telling developers that "Regarding those who are ejected from the Linux Kernel Community after this CoC:" they should consider as a group pulling their permission for using their GPL2 code in the kernel!
If a threat of this kind were acted upon by a group of banned kernel coders it could stop kernel development in its tracks, freezing the kernel at the last version released for as long as it would take the remaining developers to replace the missing code.
Eric S Raymond says that "the threat has teeth"
Eric doesn't seem to understand that as of 2016 over 13,500 developers from more than 1,300 companies have contributed to the Linux kernel since tracking began 11 years ago. A s employees of those corporations they have to abide by that or a similar CoC anyway. If more independent kernel coders drop out then the kernel project will be totally under the control of corporations. Sadly, the number of unpaid developers continues its slow decline, as Linux kernel development proves an increasingly valuable skill sought by employers, ensuring experienced kernel developers do not stay unpaid for long.
Those in favor of the CoC claim it has been adopted by thousands of companies and development groups. Being adopted and being enforced are two different situations. There are probably lots of companies and groups that claim they have adopted the CoC just to avoid antagonizing the SJW's but don't enforce it. There are software companies that enforce and go beyond the "telos" or "ethos" of their employees or group and demand that a group member be fired even without proof of misdeeds based on accusations alone. Sound familiar?
Some have suggested that this is a political ploy designed to by Intel and others to take over control of the Kernel development.
My own view is that Torvalds was the victim of a political coup. I believe that Torvalds will pack up and move back to Finland and never engage in Linux kernel development again. despite his claim that his step down is "just for a while". He's been given stock options, large salaries and other monetary inducements in the past so if he has managed his finances correctly then after 20 years he should have enough to retire on, or start his own software company, or start another kernel, if he love working on kernels as much as he claims.
I am going to take time off and get some assistance on how to understand people's emotions and respond appropriately.
Put another way: When asked at conferences, I occasionally talk about how the pain-points in kernel development have generally not been
about the _technical_ issues, but about the inflection points where development flow and behavior changed.
These pain points have been about managing the flow of patches, and often been associated with big tooling changes - moving from making releases with "patches and tar-balls" (and the _very_ painful discussions about how "Linus doesn't scale" back 15+ years ago) to using BitKeeper, and then to having to write git in order to get past the point of that no longer working for us.
...
To tie this all back to the actual 4.19-rc4 release (no, really, this is_ related!) I actually think that 4.19 is looking fairly good, things have gotten to the "calm" period of the release cycle, and I've talked to Greg to ask him if he'd mind finishing up 4.19 for me, so that I can take a break, and try to at least fix my own behavior.
This is not some kind of "I'm burnt out, I need to just go away" break. I'm not feeling like I don't want to continue maintaining Linux. Quite the reverse. I very much *do* want to continue to do this project that I've been working on for almost three decades.
This is more like the time I got out of kernel development for a while because I needed to write a little tool called "git". I need to take a break to get help on how to behave differently and fix some issues in my tooling and workflow.
Put another way: When asked at conferences, I occasionally talk about how the pain-points in kernel development have generally not been
about the _technical_ issues, but about the inflection points where development flow and behavior changed.
These pain points have been about managing the flow of patches, and often been associated with big tooling changes - moving from making releases with "patches and tar-balls" (and the _very_ painful discussions about how "Linus doesn't scale" back 15+ years ago) to using BitKeeper, and then to having to write git in order to get past the point of that no longer working for us.
...
To tie this all back to the actual 4.19-rc4 release (no, really, this is_ related!) I actually think that 4.19 is looking fairly good, things have gotten to the "calm" period of the release cycle, and I've talked to Greg to ask him if he'd mind finishing up 4.19 for me, so that I can take a break, and try to at least fix my own behavior.
This is not some kind of "I'm burnt out, I need to just go away" break. I'm not feeling like I don't want to continue maintaining Linux. Quite the reverse. I very much *do* want to continue to do this project that I've been working on for almost three decades.
This is more like the time I got out of kernel development for a while because I needed to write a little tool called "git". I need to take a break to get help on how to behave differently and fix some issues in my tooling and workflow.
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 <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/progr...y-councils/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."
----------------
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 <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/progr...y-councils/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."
The attack on Linus started in earnest five years ago when Sarah Sharp criticized his management style and made sex and racism an issue, while various social justice warrior sites began criticizing meritocracy as a method to obtain high quality code.
(Sarah Sharp is the author of the Linux USB 3.0 host controller driver.)
Torvalds replied:
Because if you want me to "act professional," I can tell you that I'm not interested. I'm sitting in my home office wearing a bathrobe. The same way I'm not going to start wearing ties, I'm *also* not going to buy into the fake politeness, the lying, the office politics and backstabbing, the passive aggressiveness, and the buzzwords. Because THAT is what "acting professionally" results in: people resort to all kinds of really nasty things because they are forced to act out their normal urges in unnatural ways.
The GPL version 2 lacks a no-rescission clause (the GPL version 3 has such a clause: to attempt furnish defendants with an estoppel defense, the Linux Kernel is licensed under version 2, however, as are the past contributions).
When the defendants ignore the rescission and continue using the plaintiff's code, the plaintiff can sue under the copyright statute.
Banned contributors _should_ do this (note: plaintiff is to register their copyright prior to filing suit, the copyright does not have to be registered at the time of the violation however)
When the defendants ignore the rescission and continue using the plaintiff's code, the plaintiff can sue under the copyright statute.
Banned contributors _should_ do this (note: plaintiff is to register their copyright prior to filing suit, the copyright does not have to be registered at the time of the violation however)
Eric S Raymond says that "the threat has teeth"
First, let me confirm that this threat has teeth. I researched the relevant law when I was founding the Open Source Initiative. In the U.S. there is case law confirming that reputational losses relating to conversion of the rights of a contributor to a GPLed project are judicable in law. I do not know the case law outside the U.S., but in countries observing the Berne Convention without the U.S.'s opt-out of the "moral rights" clause, that clause probably gives the objectors an even stronger case.
...
What we have now is a situation in which a subgroup within the Linux kernel's subculture threatens destructive revolt because not only do they think the slider been pushed too high in a normative direction, but because they think the CoC is an attempt to change the group's telos.
The first important thing to get is that this revolt is not really about any of the surface issues the CoC was written to address. It would be maximally unhelpful to accuse the anti-CoC people of being pro-sexism, or anti-minority, or whatever. Doing that can only inflame their sense that the group telos is being hijacked. They make it clear; they signed on to participate in a meritocracy with reputation rewards, and they think that is being taken way from them.
...
What we have now is a situation in which a subgroup within the Linux kernel's subculture threatens destructive revolt because not only do they think the slider been pushed too high in a normative direction, but because they think the CoC is an attempt to change the group's telos.
The first important thing to get is that this revolt is not really about any of the surface issues the CoC was written to address. It would be maximally unhelpful to accuse the anti-CoC people of being pro-sexism, or anti-minority, or whatever. Doing that can only inflame their sense that the group telos is being hijacked. They make it clear; they signed on to participate in a meritocracy with reputation rewards, and they think that is being taken way from them.
Those in favor of the CoC claim it has been adopted by thousands of companies and development groups. Being adopted and being enforced are two different situations. There are probably lots of companies and groups that claim they have adopted the CoC just to avoid antagonizing the SJW's but don't enforce it. There are software companies that enforce and go beyond the "telos" or "ethos" of their employees or group and demand that a group member be fired even without proof of misdeeds based on accusations alone. Sound familiar?
Some have suggested that this is a political ploy designed to by Intel and others to take over control of the Kernel development.
My own view is that Torvalds was the victim of a political coup. I believe that Torvalds will pack up and move back to Finland and never engage in Linux kernel development again. despite his claim that his step down is "just for a while". He's been given stock options, large salaries and other monetary inducements in the past so if he has managed his finances correctly then after 20 years he should have enough to retire on, or start his own software company, or start another kernel, if he love working on kernels as much as he claims.
Comment