Message-ID: <20241026145640.GA4029861@mit.edu>
Date: Sat, 26 Oct 2024 10:56:40 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Jiaxun Yang <jiaxun.yang@...goat.com>
Cc: linux-kernel@...r.kernel.org, conduct@...nel.org, security@...nel.org,
        cve@...nel.org, linux-doc@...r.kernel.org,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>, shuah@...nel.org,
        lee@...nel.org, sashal@...nel.org, corbet@....net
Subject: Re: Concerns over transparency of informal kernel groups

On Fri, Oct 25, 2024 at 04:15:42PM +0100, Jiaxun Yang wrote:
> 
> Over recent events, I've taken a closer look at how our community's governance
> operates, only to find that there's remarkably little public information available
> about those informal groups. 

There's quite a bit of information available in the Linux Kernel
documentation.  For example:

* https://www.kernel.org/doc/html/latest/process/security-bugs.html
* https://www.kernel.org/doc/html/latest/process/code-of-conduct.html
* https://www.kernel.org/code-of-conduct.html

Ultimately, though, governance model that we've used since the
founding of the Benevolent Dictator model.  For a description of this,
see:

* https://wiki.p2pfoundation.net/Benevolent_Dictator

The reason why this model works for Open Source projects is that
ultimately, the license allows the code to be forked, and someone
could decide to take the Linux Kernel sources, and declare some new
version, say: "Tedix".  However, if I was delusional enough to do
this, it's very likely no one would pay attention to me, and consider
me a random madman (of which there are many on the Internet).  

Ultmately, though, the reason why Linus continues to serve as the
leader of the Linux is that there is a very large number of people
that respect his judgement and technical acumen.  And unlike in
physical space where a dictator could (hypothetically) order tanks to
fire on college-aged students, ultimately no one can force developers
or companies to continue use or develop Linux.

Everything else follows from this.  So for example, a maintainer or
maintainer team can refuse to accept patches from a particular source.
If someone disagrees with a decision, whether it is not accepting a
patch, or request a patch that it be reverted, they can appeal to
Linus.  Linus ask the Maintainer for their reasons, or can decide to
override the decision by accepting the patch into his tree, or
reverting a patch.  Ultimately, Linus can decide to relieve a
maintainer of their duties by simply refusing to accept pull request
from that maintainer, or by remoing the subsytem entirely from his
sources.

As another example, the Code of Conduct committee has no inherent
power to sanction developers, other than to make recommendations to
people who actually do the work --- namely, Linus Torvalds, other
maintainers, the people who run the mailing lists, etc.  Like with
Maintainers, their "power" comes from the respect that individuals on
that body have with Linus and the other maintainers.

Yet another body which you didn't mention is the Linux Foundation
Technical Advisory board.  That body is elected, but the TAB has
always made it clear that the primary power comes from the reputation
and moral authority of the people who are elected to the TAB.  Sure,
The TAB chair has an at-large seat on the Linux Foundation board, but
any influence that the TAB through the TAB chair might have is more
because of their work and the force of their arguments.


More broadly, the model that I like to use is "servant leadership",
and that's why I tell people who want to pursue taking up leadership
roles in Linux.  Most of the senior leadership spend a huge amount of
their personal time, and have often made career choices that have
prioritized working on Linux and other Open Source projects over
monetary renumeration.  Speaking for myself, I could have progressed
farther in terms of position and salary.  I made choices that traded
the freedom and ability to work on Linux because that was more
important to me, and there is an awful lot of what I do as a leader is
to serve those people in the ext4 development community.

This is not true just in Linux; previously, I've served on the
Security Area Advisory Group for the IETF, the standards body for the
internet, and as working group chair for the ipsec working group when
the IPSec protocols were first being standardied.  Sure, I was part of
the "governance" of the IETF, but one of the things you learn very
quickly is that as a volunteer leader, your primary power is to stop
things from happening.  Hopefully, you're only stopping bad things
from happening, and you can try to encourage and cajole volunteers
spend time on what's necessary to make forward progress.  And of
course, you can spend your own personal time smoothing the way to
enable the members of the community to make forward progress.  And
that takes us back to "servant leadership".

Cheers,

					- Ted

P.S.  Note that when I say "volunteer', I'm using this in a fairly
broad/informal fashion.  Yes, some members of the community have
companies that pay our salaries to work on Linux.  But as the ext4
maintainer, I don't have magement authority over the ext4 developer.
I can refuse to take a patch; I can spend time creating testing
infrastruture to make it easier for ext4 contributors to test their
work; I can point out ways that some particular design might be good
for ext4, and good for their company's business objectives, to the
extent that I know their companies goals or they are willing to share
those goals with me.  But I can't *force* someone at SuSE or Oracle or
IBM or Huawei to work on some particular ext4 feature or bug.
Ultimately, either individuals (who might be hobbists) or companies,
voluntarily choose to contribute to ext4, or the IPSec standard.  And
so that's why I call Linux and the IETF have much in common with a
pure 100% volunteer organization, such as Doctors without Borders.

Powered by blists - more mailing lists