[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <480c8a05-d73b-4cd8-8470-2ac7b4574cec@app.fastmail.com>
Date: Sun, 27 Oct 2024 10:26:47 +0000
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Theodore Ts'o" <tytso@....edu>
Cc: linux-kernel@...r.kernel.org,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, shuah@...nel.org,
lee@...nel.org, sashal@...nel.org, "Jonathan Corbet" <corbet@....net>
Subject: Re: Concerns over transparency of informal kernel groups
在2024年10月27日十月 上午1:14,Theodore Ts'o写道:
> On Sat, Oct 26, 2024 at 05:33:16PM +0100, Jiaxun Yang wrote:
>> That being said, I'll try to improve the documentation on these things
>> based on my observations. My background perhaps makes me particularly
>> sensitive to some ambiguous language, especially where "constructive
>> ambiguity" might be involved. Recent events make me started to look
>> into those aspects in border community.
>
> Well, make no mistake, there *is* a lot of ambiguity, because we don't
> really have a centralized governance structure other than Linus has
> the benvelent dictator. The general philosophy is to have just as
> much structure as necessary, but no more. We do need to have a legal
> organization to sign contracts with hotels, caterers, etc., for the
> purposes of organizing conferences. That is one of the roles of the
> Linux Foundation. But just because the Linux Foundation organizes
> conferences, and accepts corporate donations, and pays Linus's salary,
> *doesn't* mean that they get to dictate to Linus what he does, or
> anything about what code does or doesn't get accepted into the Linux
> kernel. As Jim Zemlin, the Executive Director of the Linux Foundation
> has been known to have said, he works for Linus, and not the other way
> around.
Thanks Theodore for making all those comments.
I perfectly understand why we don't have any "binding rules". However, I
see the problem from a different perspective.
As someone who's a bit of a Linux advocate in real life, the recent events
have led to quite a few questions coming my way from outsiders: things like,
"What happens if someone uses inappropriate language in the Linux community?"
"How do you make sure no one slips in a backdoor in the same manner?" and
"How do you prevent security issues from being swept under the rug?"
I tried to answer by referencing kernel documents, but honestly, I found a lot
of ambiguity, some of it even felt like it was left vague on purpose.
So my answer was always "Oh I trust Linus and other folks out there, they are
all decent people." and point them to some stories like Linus vs NSA [1].
While I believe this is the real answer to those questions, I found this
is not really convincing to outsiders. It's easy for people to judge our
leadership based on one-hot behaviour because they didn't experience the
process where our mutual trust was built.
That got me wondering, "What if we wrote down some of these unspoken stuff?",
but found myself not really qualified to make those documentations changes.
I reached some kernel maintainer personal friends and found we are at a similar
position, thus the post.
Maybe I should rephrase my original post to sound less forceful. My intension was
never "changing the system" but to improve the transparency so people (outsiders
and maybe some community members) can gain more confidence to Linux.
Perhaps we are far beyond the stage that attracting users based on ideology
is necessary to spend people's bandwidth .... I don't know... I'm very lost
recent days...
>
> This is not the only way to organize an open source project, of
> course. For example, the Rust community has a lot more structure
> process. I will note that this has not reduced the amount of
> organizational drama and contrversy. In fact, some might argue that
> their governance structures may have caused some of the more recent
> drama that lead to some people stepping down from official leadership
> roles....
>
> Or you can take a look at some of the BSD projects, which early on had
> a lot of drama and some of the BSD forks based on who was officiallty
> part of the core team, and who wasn't (or who was thrown off of the
> core team). It's perhaps because of that drama in the early 90's that
> some of us who were around during that era rather consciously rejected
> the formation of anything like the BSD formal core team model, because
> we saw the dysfunction that could result from it.
>
> There are limits to the informal model, of course. One of the ways
> that we have tried to make it scale is that there is great value in
> making sure that the kernel developers have face time with each other.
> It's one of the reasons why I organized the Linux Kernel Summit, which
> later morphed into the Maintainer's Summit. It's why there are many
> people who spend a huge amount of time organizing the Linux Plumbers
> Conference and other workshops, whether it's the Linux Security
> Symposium, or the Linux Storage, File Systems, and MM workshop, or
> Netconf. The ability for us to see each other face to face, and break
> bread together, makes the human relationships real in a way that
> avoids e-mail conversations alone can turning into flame wars.
>
> More recently, some subsystem teams have started regular video chats.
> They aren't a substitute for in-person meetings, but they still are
> valuable in terms of having that higher bandwidth conversation where
> the non-verbal cues can humanize the personal connection.
>
I'm a bit too young to know the old BSD stories first-hand, but I've seen
plenty of drama in other projects and have read The Cathedral and the Bazaar
more times than I can count. Maybe it's not my place to comment, but I have
to say, our current model seems to be working well for its purpose.
>From my experience at a few Kernel events, I've also found that a bit of beer
often serves as the perfect development lubricant :-)
> Of course, like all things, there are tradeoff and limitations.
> Attendance at in-person meetings can be hampered by real-world
> considerations such as the cost of travel, or the need to get travel
> visas, or for people for whom English is not their primary language,
> they might be able to use Google Translate for e-mail, but that
> doesn't work that well for in-person meetings or video conferences.
> Some of these can be mitigated; the Linux Foundation has a travel
> scholarship fund for people who can't get corporate sponsorship for
> their travel, and many conferences now have a hybrid option for people
> who can't attend in person for whatever reason. But the language
> barrier can still be an issue for some. Maybe someday we will have
> something like Star Trek's universal translator...
As a non-native speaker living in an English-speaking country, I want to
say that the kernel community is one of the most inclusive spaces I've
encountered. People here are remarkably patient with non-native speakers,
far more so than average people I met in my life. When misunderstandings
arise due to language or cultural differences, everyone makes a genuine
effort to reach a mutual understanding. I truly appreciate everyone's
open-mindedness here.
I really hope recent events don't signal a turning point for this inclusive
culture, though I'm starting to notice some worrying signs.
>
> The bottom line, though, that any organization is made up of *people*,
> and so there is no substitute for personal relationships and trust.
> If you don't have that, I doubt any amount of organizational structure
> can save you, and in fact, to the extent that some people might try to
> game the formal rules/structure, it might actually make things worse.
Well said, I believe none of us is looking for bureaucratic here. Even
if there are formal rules being setted, it's still people doing judgements.
That's why I believe it's always important to know the people behind things.
People Makes /* Glasgow */ Linux!
>
> Cheers,
>
> - Ted
Thanks
[1]: https://www.theregister.com/2013/09/19/linux_backdoor_intrigue/
--
- Jiaxun
Powered by blists - more mailing lists