Recent searches
Search options
As a long-standing open source contributor and in various capacities maintainer, I have a bunch of thoughts following Rust4Linux and Asahi developments...
1) Humans are going to complain, and in a world w/ social media do so on social media, about public & persistent frustrations in their lives. Not super useful to ask them not to do that.
2) Brigading is a big deal, and not a term that should be used lightly. It specifically means *intentionally* creating a coordinated group harassment campaign. Don't call stuff brigading without very clear evidence of intent. People who _are_ intentionally brigading people are actively engaging in organized and serious harassment. It can escalate easily and is _unacceptable_ behavior.
3) Both those said, people with large online followings are somewhat responsible for any group-harassment or full-on brigading that their following does, even when they're not directly involved. If informed, they need to take very active steps to end this and prevent it going forward. There is no "well _I_ wasn't doing any harassing" excuse nonsense.
4) Telling someone with a large following "you're brigading me" when their followers were doing something independently isn't a great way to let them know what's going on and get (3) to kick in. Especially folks in powerful, leadership positions should be *much* better at communicating than that. Tell them what is happening, by whom, and what you're hoping they can do. Ya know, like you would otherwise.
5) Last, but *far* from least: the behavior allowed on LKML is ridiculously toxic. This predates Asahi, R4L, and probably Rust. It is incredibly unsurprising for folks to be frustrated about this and posting about that frustration. There's a long line of previous posts from a wide range of authors (who weren't accused of brigading). I would suggest that improving this is a better focus for leadership of the Linux Kernel, and has been for a long term.
6) Culture problems in open source communities _are_ ultimately the responsibility of leaders in those communities. Harassing leaders because of culture problems will _not_ improve things. But talking about these problems and how leadership can and must step up to address them is an essential component.
@chandlerc maybe
7) LKML is social media, too.
@goedelchen No, I think it is importantly different...
LKML is certainly *public*, and a very loud and far reaching public platform at that.
But it isn't a platform for any one person's personal social discussion. It's a shared community forum.
For example, it wouldn't be at all reasonable to just complain and vent in an unconstructive (but not in any other way inappropriate) manner your personal frustrations (even about the Linux kernel) on LKML. It's not *your* personal platform to share such complaints. Subscribers didn't subscribe to a personal feed. Not even from Linus.
But your personal social media is all of these things. It doesn't have some overriding purpose beyond being authentically your chosen social persona.
@chandlerc IMHO the sad truth is (in the case Linux at least) the leadership is unwilling to take those steps. I always hear about the email biggest barrier to entry I have to disagree with that. It’s the leadership and old maintainers who seem to never be held accountable. It’s tiresome be frank, the kernel seems to be a kingdom with maintainers jealously protecting their fiefdoms.
@0xAnita I agree about the leadership, but not the maintainers.
First, while perhaps unintended, I think the term "old maintainers" is both agist and if understood in terms of their personal age inaccurate.
One problematic aspect here is the maintainers being entrenched in their position, both failing to respond to changing needs and failing to step aside to allow a different maintenance approach. This could be fixed by changing either end.
And the lack of change to either aspect is really a consequence of the next thing you said: the maintainers aren't being held accountable. I don't think it's reasonable to expect maintainers to reliably and consistently do a good job without being held accountable.
And it is *leadership* that has to hold them accountable.
So that remains where the problem lies. Not the community (clearly), nor even the maintainers directly, but the leadership that creates a system to foster hostile communication and failure to change when needed, and leadership that doesn't hold the maintainers accountable to living up to that standard.
Culture has to flow from the top. Culture change requires change at the top, in one form or another.
Maybe that can happen for Linux, dunno. But probably not because of my post. I'm not really trying to broadcast this to Linux leadership. But to all the other leaders of open source communities, and all the folks who will in the *future* become leaders in these communities. Hoping to help this broader group avoid ending up where the Linux kernel now seems to be.
@chandlerc to be clear I don’t mean old maintainers as in they’re old I mean they’re entrenched in their position and been there for a long time. I found that even in the proprietary corporate world people who’ve been in their positions for a very long time tend to be either the most insightful or obstructionist the in between space seems to be very few.
@0xAnita I figured, but good to avoid the term -- even unintended, it likely hurts folks, and even those it doesn't may get the wrong idea.
Regarding being in a position for a long time .... I'm not gonna launch stones from my 16 year and counting efforts around compilers and PL. ;] But hopefully I'm not in the obstructionist group too often.
@chandlerc there is an odd thin line that’s not talked about enough about between conservative approach versus a obstructionist approach this is speaking as a former obstructionist ;P I do agree, though that the tone is set from the top and I’ve spoken to too many friends who’ve been burned by the kernel process to think that it’s not flawed at a fundamentally toxic level. Like. Granted several things can be true.
@chandlerc So I think Linus' position is strange. In the early days Alan Cox's Linux tree was the one to follow. We've now evolved into distributed version control but in Linux you have these maintainer gate keepers to landing changes and Linus is acting as an uber maintainer gate keeper. If you touch something Linus is touching then you will get blasted if it doesn't work how he expects, but for the majority of things he admits to having deferred responsibility.
@chandlerc maintainers must show a high degree of survivor bias. As most companies don't understand Linux, but they understand a letter of recommendation from Linus, there is a huge motivation to just always try to keep Linus happy - but imo Linus isn't always right. So it is pretty clear there are huge power dynamics involved, at the same time stakes are low for those not directly impacted by an issue and so things can be bitter.
@chandlerc My feeling is the most broken thing is that landing patches in the kernel is ridiculously slow. For example, work done prior to Google Summer-of-Code by a contributor got maintainer review 9 months later and a year later it is still awaiting landing with new issues having been discovered. If you're a student reviews/landing taking over a year, it just doesn't work. For companies, OKRs just don't fit this model. I think we got to this place due to the culture.
@chandlerc There's an odd overlap with Linux and Python in LWN. R4L may be is something of the scale of Python's global interpreter lock, the difference I see in the community is that Guido is in the room for GIL discussions.