Excellent rebuttal. Oh wait, no it isn't.
Your comment on hobbies makes no sense to me as I am not in search of one more wish anybody else have or not have one.
The entire matter relates to the World's Largest FOSS Hobby Project, Linux (tm). Something which (apparently) you wish to interfere with directly or indirectly. Or maybe you just want another excuse to talk about Donald Trump.
a condition that in my personal opinion is created by lack of knowledge.
So are you calling me ignorant of the matter at hand, or ignorant in general?
You can only see what your understanding permits.
That applies to everyone, including you.
I believe that humans have potential far beyond what we see in our culture.
I believe that, in this instance, the apparent or actual potential of humans is of no concern. None of those people in the Linux community causing strife through their poor behavior have any need or desire to realize that potential. We aren't talking about deadbeat dads, homeless drug addicts, prison inmates just getting out of jail and in need of a future, or anyone else grossly in need of "turning their life around". We're talking about rude FOSS coders. They probably make enough money to survive, are reasonably well-educated, and have social problems. Making them into better people ranks pretty low on my list of Things to Do to Make Humanity Better (tm). They do rank pretty high on the list of people I'd rather just leave alone. Do I want them to become better people? Sure, why not? I could say the same for nearly anyone. But I do not wish people to take an active hand in manipulating them or forcing them to behave nicely. Either they figure it out on their own, or they don't. No big deal either way.
Anyone who does not want to deal with them can easily avoid them AND take full advantage of present and future kernel code. It's so easy, it's stupid. I'm not sure why anyone cares what the screaming Linux kernel developers are doing, since their blather is largely irrelevant anyway. You can appropriate all their code and roll it into your own kernel so long as you use the same license. No muss, no fuss.
Actually, this is now mostly a corporate project
Is that what it is now, or is that what the promoters of the Code of Conduct would like from the Linux project? Right now, corporate contributors submit code to the kernel project at the pleasure of the maintainers. They hold no special power or sway over the project, except that in some cases, major corporations do provide hardware access and documentation (or code based on those factors) that permit the kernel to function properly with modern hardware. It's pretty obvious when hardware vendors do NOT submit such code to the kernel. Getting 802.11ac hardware to work properly under Linux without some proprietary binary blob is a damned mess, let me tell you.
In any case, while it is well-understood how corporate involvement in kernel development can be beneficial, it grants them no special power over the maintainers. They don't have the right to push people around or make them act nice. They just don't. They can continue to participate in kernel development, or they can take their ball and go home.
and as people who work in corporate environments already have a code of conduct this is mainly spreading it throughout the entire line of devs.
Again, under what pretense can they even do this?
High level devs have left over the crap they have gotten (and no, I can't repeat it here since I would get banned if I used those words) spewed at them for no reason what so ever and that isn't the way to move forward.
Of course it's the way to move forward. If people left,
good. People shouldn't stay with the Linux project if they don't like the people involved. That gives them the power to pursue their own interests elsewhere, free of vitriolic blather. That's the desired outcome. It makes sense, and it works for everyone. If independent kernel developers continue to drive out major supporters of the project, eventually they'll be left to do their own thing (and yell at each other while doing so) while other contributors can roll their own kernel elsewhere, merging whatever they want into their project according to the terms of the GPL v3.x. That's probably the best outcome possible.
I dare say that eventually, we'll see major Linux distros ditch "official" kernel releases, and use their own in-house kernel versions instead. I've already used alternate kernels, such as the ones I used to support AMD's kfd before it became standard. There is nothing wrong with this.
Linux is today a project that drives all android phones, the backbone of the internet and a great deal of workstations/local servers. It's not some FLOSS hobby project anymore and as professionals are engaging in the process they expect professionalism in both coding and behavior.
Then why are they still dealing with a community that still operates as a FOSS/FLOSS hobby project? If the corporate Linux groups want to seize control of their own future, they need to go their own way. The current Linux development infrastructure is not theirs to control, no matter how important it has become.
And ironically, no matter how much it may gall those who demand professional behavior from Linux kernel developers, Linux still manages to be the most important OS software on the planet, day after day, despite the poor behavior of some kernel devs. How is this possible?
As a dev I support the new CoC.
I would support it more if people went about it the same way the Rustaceans did it. While I do not necessarily like their particular community conduct rules, I have to respect that their rules have been in place since the beginning of Rust development. Nearly everyone involved in Rust signed off on the idea at the start. Anyone who wants to take an active role in interacting with the Rust community or developing the Rust programming language (or any of its tools) has to get on board with what was there from the beginning. It's all laid out pretty clearly, even if the enforcement of their community conduct rules is . . . maybe hard to understand sometimes.
The proposed kernel dev CoC should have followed the same process, and part of that process would be to start an entirely new community based on that CoC. Forcing it on an old, established development community was the wrong way to go.
How To Command Respect Without Being a Jerk
I doubt that many of the kernel maintainers really care about respect.