Linux kernel patch releases "code of conduct"
When one considers open source, it's fairly easy to imagine a world of designers, developers, and distributors getting along fabulously while sharing ideas and ideals like most people share memes on Facebook.
Unfortunately, the reality isn't quite so kumbaya or Ubuntu (as it were).
In fact, the Linux development community has recently had to adopt the means to resolve conflict between developers. The sad reality is that the infighting among the Linux developer community goes back... way back. I would like to believe the conflicts within the community have all arisen from choice -- or the incredible amount of choice available to the platform. Along with such choice comes opinion, and we all know where opinion leads. You can't get away from the old tried and true "My toys are better than your toys" fighting. However, that's not what this is all about -- it goes much deeper. This is infighting among the developers of Linux itself... the kernel. So, it's not just the old GNOME pointing a finger at KDE. This is serious, and it's been going on for a very long time.
Some would say that the center of the problem is Linus Torvalds himself, that his blunt and cavalier attitude towards dealing with other developers has lead to too much tension within the ranks. However, when one man holds such a massive responsibility for that much code (and the patches submitted therein), it only makes sense that he carry a sharp stick and tone. The problem comes when contributors begin calling out Torvalds publicly. This happened recently when Lennart Poettering called Torvalds out for encouraging hate speech and attacks. Poettering went so far to say that the Linux community is a "sick place to be in."
Where is this coming from? Poettering is a Red Hat engineer responsible for the controversial systemd replacement for the UNIX sysvinit daemon and has been called to the carpet many times for pushing to replace a system that has worked (and worked very well) for a long time. At one point, there was even a website dedicated to Boycotting systemd (the site has been taken down). The vitriol surrounding this controversy is thick and venomous.
The systemd issue is just one in a long line of issues that have sparked debate over the years. That it has taken the Linux kernel developers this long to come up with a sort of "code of conduct" is beyond anyone with a grasp on logic. But at this time in the lifecycle of Linux (and open source), this sort of change is not just positive, it's necessary.
Why? Linux has reached a massive tipping point. The enterprise has accepted Linux as a defacto standard for many applications. Big data is going to heavily depend on Linux as its go-to standard. Many Fortune 500 companies have adopted Linux for mission critical services.
Linux now means business, and businesses need Linux. Period.
With that in mind, the whole of the Linux community needs to understand one thing -- when the world depends on you, you must deliver. Linux not only plays with the big boys now, Linux IS one of the big boys. That means a change in attitude and ecosystem. If Linus is to continue leading the charge (and why wouldn't he?), those following him must adapt their mindset into seeing the man as more than just the creator of Linux -- he holds the keys to a very large and powerful kingdom.
But here's the thing, the new "code of conduct" comes in the form of a Linux kernel patch that says:
"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 or the individual members, and they will work to resolve the issue to the best of their ability.
"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'."
So, instead of creating a process by which developers can deal with issues, a simple statement within a kernel patch was added to instruct those with said issues to contact the Linux Foundation Technical Advisory Board. Yes, civil discourse is a great beginning... but is it a means to an end? I don't think so.
From my perspective, it would seem the kernel of one of the single most important operating systems on the planet would benefit from having a stand-alone advisory board to handle such issues as infighting among kernel developers. This is, after all, not the Linux of five or 10 years ago -- this is the Linux that the world depends on. In fact, there's no reason why the Linux kernel shouldn't be led by an advisory board (of which Linus would head) that would not only handle squabbles but aid in the shaping and directing of the platform.
At present, the Linux Technical Advisory Board (TAB):
"...provides the Linux kernel community a direct voice into The Linux Foundation's activities and fosters bi-directional interaction with application developers, end users, and Linux companies."
Yes, the new kernel patch indicates that any issues should be brought to the TAB, but wouldn't it help if the kernel developers themselves had a representative voice within the rank and file? I can foresee this code of conduct patch sending every disgruntled kernel developer running to the TAB, and the members of the TAB having to sift through the issues like a shell hunter sifting through sand to find the truth. With a non-biased representative within the kernel developers chosen as a sort of lifeline to the TAB, the resolution of issues could be much more efficient.
In a perfect world, this wouldn't be happening. But when ego and emotion get involved, chests will be puffed and feathers will be ruffled. What's truly of importance here is that the issue of conflict resolution be streamlined and treated with more than a code of conduct patch within the kernel.
The Linux ecosystem has reach a point where it is powering some of the largest businesses on the planet. The kernel development team needs to understand that, in order for Linux to continue on its current "world domination" trajectory, the issues at hand must be treated seriously, justly, and efficiently.
What do you think would be the best means of resolving conflict within the Linux kernel development team? Share your thoughts in the discussion thread below.
