Of course. This video is a long, unedited monologue, so I've extracted the core arguments. As far as I can tell, the speaker is correct about the general nature of the kernel contribution process, though his frustration is probably higher than average.
Abstract:
René Rebe, maintainer of the T2 Linux distribution, delivers a detailed critique of the Linux kernel's upstream contribution process, arguing it is prohibitively "expensive" in terms of time and effort. He posits that his initial estimate of a 10x time multiplier for upstreaming a patch versus a local fix is a significant underestimate, with real-world cases approaching a 100x multiplier. The core of his argument is demonstrated through a lengthy case study of a simple one-line fix for a Ugreen NAS watchdog timer. This minor patch devolved into a multi-day, multi-version ordeal involving extensive rewrites based on terse, pedantic, and sometimes incorrect feedback from a kernel maintainer. Rebe highlights a culture that is unwelcoming to contributors, focusing on trivialities like typos and commit message formatting while demanding significant, uncompensated labor without offering thanks or even proper credit. He contrasts the broken state of drivers for common hardware (Steam Deck, Mac Pro, Microsoft Surface) in mainline Linux with their long-fixed status in his own distribution, attributing the disparity directly to this high barrier to entry. Despite the immense frustration, he announces a new personal project to attempt to upstream one patch per day.
The High Cost of Open Source Contribution: A Kernel Developer's Frustration
0:49 The Core Claim: Upstreaming is Prohibitively Expensive: René Rebe, developer of T2 Linux, explains why he rarely submits his fixes to the official Linux kernel. He always estimated it takes 10 times the effort to "upstream" a patch compared to fixing it locally, but recent experience suggests it's often 100 times more work.
3:11 An Inefficient and Unwelcoming Process: He characterizes the kernel contribution process as "way too inefficient" and culturally unwelcoming. Maintainers are described as pedantic, rude, and often unhelpful.
6:09 Case Study: A One-Line Fix Becomes an Ordeal: The primary example is a simple patch to disable a watchdog timer on a new Ugreen NAS that would otherwise reboot every four minutes, making installation of most Linux distros impossible.
8:37 The Back-and-Forth: His initial one-line patch was immediately rejected by maintainer Günther Röck with the terse comment "wrong solution." This began a long exchange where Rebe was required to completely rework the patch based on minimal, and at one point, incorrect, guidance.
12:17 Pedantic and Thankless Culture: Rebe expresses frustration with the focus on trivialities. He was chastised for a single typo ("You misspelled default") and for his description of a "broken BIOS option," all while receiving no thanks for his hours of free labor investigating and fixing the bug.
15:17 The Copyright Insult: After being forced to rewrite significant portions of the driver, he added his copyright notice to the file. He was immediately told to remove it, highlighting how contributors are expected to perform major work without credit. I don't care about copyright, but this is clearly a flawed incentive structure.
18:25 Why Mainstream Linux Stays Broken: This frustrating process is presented as the direct reason why bugs on popular hardware—like the Mac Pro headphone jack (broken for 10+ years), Microsoft Surface audio (8+ years), and Steam Deck temperature sensors (2+ years)—remain unfixed in mainline Linux, even though he fixed them in T2 long ago.
32:25 More Work for Commit Messages: Maintainers often demand contributors spend hours bisecting the kernel's history (a process of compiling and testing dozens of old versions) just to identify the exact commit that introduced a bug, simply for a "Fixes:" tag in the commit message.
44:54 The New Mission: Despite the frustrating experience, he has resolved to try and upstream one of his hundreds of local patches every day for the next year.
1:11:04 Critique of ARM/RISC-V Ecosystem: He concludes by arguing that the ARM and RISC-V hardware ecosystems are failing because they lack the rigid hardware and driver compatibility that made the x86 IBM PC clone market successful. Every new SoC is an island of proprietary, non-standard drivers, creating immense and unnecessary work.