We are the "thin blue line" that is trying to keep the code high quality

Related: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43036904">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43036904</a>

Being an upstream maintainer is incredibly under-appreciated. It’s an unfathomably hard, and somewhat thankless, job (at least if you do it well). A friend of mine was in a cab with Ted Ts’o at a conference and he was reviewing patches on his phone to keep up with the workload (or maybe he was bored who knows).<p>Despite incredible effort from maintainers, getting necessary changes into Linux can take forever. In the subsystem I depend on (and occasionally contribute to directly) it’s kinda assumed it will take at least a year (probably two) for any substantial project to get merged. This continuously disappoints PMs and Leadership. A lot of people, understandably, chafe against this lack of agility.<p>OTOH, I’ve been on the other side of kernel bugs. Most recently, a memory arithmetic bug was causing corruption, and took my team at least an engineer year to track down. This makes me quite sympathetic to maintainers demands for quality.<p>I’ve also been on the other side of the calibration discussions where Open Source work goes under appreciated. The irony never stops (“They won’t merge our patches!” “Are you having your engineers review theirs?”). That and the raw pipeline issues for maintainers (it takes a lot of experience to be a maintainer, which implies spending a lot of a bright engineer’s time on reviewing and contributing upstream to things unrelated to immediate priorities).

The factors at play are all obvious. The old-school guys want to keep things old-school. The new-school guys want to make things better in a new way. Has there been any new rewrite without a BFDL who himself is of the new school? The vim&#x2F;neovim schism happened and perhaps that&#x27;s how it ends. I personally like Neovim and I&#x27;m glad to be in backers.md and it&#x27;s a tremendously larger amount of work than to have just changed vim. But c&#x27;est la vie.<p>Egcs vs. gcc was a big deal back in the day and in the end we ended up with gcc by the egcs guys and that was it. When you win, everyone forgets the &#x27;drama&#x27; existed. When you lose, everyone remembers you as just the drama guy. RMS had the drama label for decades. Things are not even different. They&#x27;re the same again. It&#x27;s like when you&#x27;d buy those Chinese NES dupes and they&#x27;d have 999 levels of Mario but half the levels would be the same but with different colour bricks. Isomorphic to original but distinct. That&#x27;s this story.

A fundamental problem here not yet discussed directly here is how few maintainers there really are for a software project of this magnitude and importance. Further, the fact that so many of those maintainers are purely on volunteer time.<p>Now it is <i>certainly</i> somewhat the fault of the maintainers themselves for turning off thousand if not tens of thousands of eager, well-intentioned wannabe contributors over the decades, if not through their attitudes and lack of interpersonal skills, then through impenetrable build systems and hostility towards ergonomic changes.<p>But forget the eager amateurs - it is unconscionable that major technology companies &amp; cloud providers don&#x27;t each have damn near an army helping out with Linux and similar technologies - even the parts that do not directly benefit them! - instead of just shoving it into servers so they can target ads for cheap plastic crap 0.000000001% better than they did last week.

&gt; But what isn&#x27;t appreciated, is that it is precisely because people who are long-term members of the community are trusted to stick around and will support code that the have sponsored.<p>Ok. But if you make it too difficult for new developers to contribute, and the experience too stressful, then no one new will stick around to be long time maintainers, and when the old ones retire or die, there won&#x27;t be anyone to replace them.

&gt; One of the things which gets very frustrating from the maintainer&#x27;s perspective is development teams that are only interested in their pet feature, and we <i>know</i>, through very bitter experience, that 95+% of the time, once the code is accepted, the engineers which contribute the code will disappear, never to be seen again.<p>This was painful for me to read as someone who has seen how corporations think about “Open Source” - he isn’t wrong at all

&gt; the engineers which contribute the code will disappear<p>From the other side, as a very occasional contributor, I&#x27;d actually want to deal with fixes or reviews around the code I contribute.<p>But it&#x27;s usually edge cases on otherwise stable and mature libraries, so hopefully it probably won&#x27;t happen more than say once in a decade. If I got a mention on a PR I&#x27;d reappear, but that doesn&#x27;t sound like the standard way, I never got involved again on anything submitted.<p>I feel like either the maintainers are doing an incredibly good job at vetting the PRs, or got used to deal with the aftermath another way and just don&#x27;t need the original code submitter to reappear most of the time ?<p>Am I missing some bigger part of it ?

The problem is aging code sours like milk.<p>I empathize but we need to have people take over these initiatives and refactor them into something easier the maintain. Not saying introduce a new language or anything but change how we fundamentally look at “The Kernel”. I think reducing scope and making it so hardware providers must maintain their drivers is a good start. If your toolchain doesn’t suffice, create a new tool.<p>If rust is so much better, create a new kernel in rust and force a paradigm shift. I think we can do better than bicker and fight over it and post email chains about it. Bring solutions. Tech debt is just OpEx to everyone else.

More shots fired at Linus (justifiably so) <a href="https:&#x2F;&#x2F;lore.kernel.org&#x2F;lkml&#x2F;6e3e26c7-002a-49c6-a3a8-1cc1b8941f57@kkx.one&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lore.kernel.org&#x2F;lkml&#x2F;6e3e26c7-002a-49c6-a3a8-1cc1b89...</a>

If comments as benign as &quot;thin blue line&quot; causes fragile entryist&#x2F;activists to flee, I say Ted and the kernel team are doing the right thing. Projects as critical as the Linux kernel shouldn&#x27;t be battlegrounds for the grievance of the week, nor should they be platforms for proselytizing. Others like him leave long paths of destruction in their wake. Lots of projects have been turned upsidedown by the drama they seem to bring with them everywhere. The salient point is contributors need to be more than &quot;drive by&quot; submitters for their pet projects. This isn&#x27;t specific to Rust in the kernel, look at how much of an uphill battle bcachefs was&#x2F;is.

gcc vs. egcs, emacs vs xemacs, <i>bsd vs </i>bsd, bsd vs att, etc, etc, etc.<p>FOSS evolves past its chokepoints by forking.<p>So, a credible group of Rustaceans and their backers need to come up with a plan to do it.<p>It doesn&#x27;t have to be antagonistic -- it&#x27;s exploratory. If it works out well, it&#x27;s a lot easier to adopt once the imagined issues are resolved or evaporated.<p>Subsystem by subsystem would be my suggestion. And just do it. And sooner or later, it will be (a) good enough that it&#x27;s pulled into -next, or (b) they&#x27;ll give up because it&#x27;s not worth the effort.<p>I&#x27;d be pretty surprised if, for instance, one of Google&#x2F;Amazon&#x2F;Meta&#x2F;Microsoft&#x2F;Cloudflare&#x2F;Netflix&#x2F;etc wasn&#x27;t interested in an ABI-compatible kernel written in Rust. Get a few biggish backers, and LF would possibly even adopt it.

I would be more likely to want to listen to T&#x27;so if he hadn&#x27;t done the following:<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=WiPp9YEBV0Q&amp;t=1529s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=WiPp9YEBV0Q&amp;t=1529s</a><p>There was a reasonable discussion about Rust, and then T&#x27;so drops the bombshell:<p>&quot;I suspect part of the problem here is you&#x27;re trying to convince everyone to switch over to the religion as promulgated by Rust and the reality is that ain&#x27;t going to happen because we have 50 plus file systems in Linux they will not all be instantaneously converted over to rust&quot; [26:05]<p>He pretty much shouts at the Rust developers, denigrates their efforts and when they explain what they are trying to do which is to understand the semantic changes.<p>And then T&#x27;so then starts yelling at him even more. He wonders why people are not happy with his attitude - then perhaps he should consider how he communicates. The Rust guy is trying to be constructive and T&#x27;so was not.

Ted&#x27;s a great guy. I haven&#x27;t interacted with him for over 20 years, but IMHO, he&#x27;s a rock star.

Calling yourself the “thin blue line” like a reference to police really doesn’t seem like a way to have an enduring community. Police don’t serve the community; I guess they think in the same way then.

That seems like a fundamental misunderstanding of policing.<p>Maintainers seem more like HOA boards than police.

I like to think of us at the thin blinking cursor.

They couldn&#x27;t have used a worst name if they tried.

why cannot more people learn about git and branching<p>you want your merges in? patch it in your own branch<p>the real crux of the issue is the quality of &quot;<i>the</i> offical version&quot;, the real issue, then, is about official branding.<p>I remember back in the day there were multiple kernel versions by different mantainers.... then again I&#x27;m probably missing the forest for the trees or something

not the phrase I&#x27;d choose to associate with, even metaphorically

Pre-supposes existing high quality, a fact not in evidence.