
'It's hard to find maintainers': Linus Torvalds ponders Linux's future - ASVVVAD
https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
======
aboringusername
For me, this is one of _the_ most interesting aspects to the development of
Linux, and one I've been studying for _years_ at various levels.

Even though I don't understand a lick of most of the code, watching the lkml
and the process itself is very quite interesting, however, there are a few
ways to try and put the kernel in a better position in the future.

Each major release can be considered a "story", for example, the journey of
WireGuard from inception to submitting it to the kernel, that's an _entire_
process, involving many, many steps and employs an unlimited number of tools;
meeting in person, email, VoIP, Slack and anything you can think of.

Conversations that turn into code are a vital part of kernel development, but
I feel is less well known (after all, we just see code shuffling about git
repos).

Each bit of code is possibly hours of work, represents many conversations, and
yet, git cannot (and does not), preserve the history of how code reaches
Linus' tree.

So, how can we improve this situation?

Document, document, document!!

I'd love to see someone like Greg Kroah-Hartman, David Miller, Stephen
Rothwell et al document, extensively, how they do their work.

I'm talking about high resolution; screen captures, text, images, audio and
anything else that we can preserve going forward, perhaps all neatly tucked
away in a git repo and backed up many, many times.

Seriously, we're at risking of losing a core vital understanding of _how_
people do their work, especially those who are core to the Kernel. Of course,
people may develop new methods, but I feel the kernel is quite mature and the
processes in theory are quite stable too (such as how Greg actually releases a
stable kernel once a week).

Of course, not everything can be documented, older software gets older, and
someone's favorite email client may not be transferable, but the general
process can be.

So yes, this is something to think about and prepare for, otherwise it may hit
the kernel quite hard.

~~~
ritwikgupta
I think the heart of what you're getting at lays in the world of
ethnographies. Perhaps a cultural anthropologist would take a hand at
documenting the process of developing for the Linux kernel, its rich history,
and all the minutiae that go into it.

~~~
rgfvdcxz
Read up on the field on Science and Technology Studies (STS). STS researchers
do this kind of work all the time, since the 1970s.

More specifically, check out the work of Matt Ratto, who defended his 2003
dissertation on this exact topic:
[https://bit.ly/2YQL1yf](https://bit.ly/2YQL1yf)

------
aSplash0fDerp
A few points irk me on "the beginning of the end" conjecture in modern
technology, rather than focusing on "as one door closes, another one opens"
philosophies that keep it all going.

If I were to do coffee with Linus, I would tell him to fork the kernel and
cleancode a kernel for the future (and take the reins), while letting the
complexities of the current kernel continue to flourish in its present form
(possibly seen as letting the rope go in the middle of a heated tug-of-war,
which needs to happen on a public stage more often).

The "in between the lines story" on Linux over the years looks like [they]
have been thrust into a role of placating the miserable, instead of writing
brilliant code (its happening outside of tech too).

As far as switching gears to salaried maintainers, OSS should start an ISP
(core function) similar to AOL (maybe aspergers online) and be a HUB for
accessing the fruits of their labor. It would be like bringing the
earthlink/mindspring 110% support model back to life (a reputation for being
stewards of all open tech, in addition to top notch support).

Just having an ad-free network as an option would be worth the price of
admission.

~~~
Chyzwar
Linux is successful because of: "WE DO NOT BREAK USERSPACE". It is Linus
policy and work with community that made it most popular OS.

~~~
yencabulator
I believe the way to "next generation" while keeping the Linux userspace
compatibility promise is basically gVisor running on a non-Linux kernel.

If it runs your container just as well, well, it's "Linux" as far as your app
is concerned.

Case in point: 1% of Google Cloud Run could just as well run on Fuchsia today
and you just wouldn't know. All you see is the inside of the gVisor sandbox --
yet at the same time it'll run pretty much any http-serving docker image.

(Of course, in the real world Linux rules because of its huge collection of
drivers, filesystems, etc.)

~~~
aSplash0fDerp
Don't quote me on this, but I hear:

creeps like other users data

I think the next billion uses (not users) of the linux kernel will be on bare
metal (or bare SOCs, wtcmb), so storage yes, but no networking or cloud
required for optimal operations.

------
kyran_adept
I think Linus is at fault here. Having a PR process that requires sending a
patch over email, email threads done with super old mailing list software, etc
instead of the more modern workflow of using forks, PRs in a web UI, etc is
tedious and annoying. Making kernel development and maintaining more accesible
to younger people would increase the pool of potential maintainers.

~~~
finnthehuman
I'm often confused as to how many people really have a potential future where
they become motivated long term participants, but a few bumpy roads at the
onset turn them off. And I don't just mean in kernel development, learning the
guitar isn't fun either.

Who gets into software as a profession, and then lets a bad UI turn them away
from a project? When so much of the valuable skillset in programming is
understanding and navigating a possibility space where the UI isn't built yet?
(And I'm sure some kernel contributors would argue it's more _unusual_ than
actively _worse_).

I know this paints me as old and out of touch. I know this. But I think it
still applies. When I look at my interns, the good developers tend not to be
the ones tripped up by onboarding to systems and workflows that aren't exactly
like the trendy development tools or what they saw in school.

~~~
qchris
I don't think this is an entirely fair comparison. I thinks it's closer to the
Post Office being worried about finding enough new drivers for their mail
routes, but refusing to upgrade any of their delivery trucks from a manual
transmission to an automatic one.

Sure, you can argue that learning to drive a standard isn't that hard, and if
you want to do a valuable public service like delivering mail, then learning
to drive one is a small price to pay. But it's a barrier to entry for most
young drivers because automatic transmissions are far, far more common.
Besides, not only is the constant starting/stopping like a mail truck does
usually hardest part of driving a manual, but isn't even fundamentally coupled
to the act of delivering mail.

There's plenty of competent drivers who might be willing to deliver mail using
an automatic (or developers to maintain the kernel on a platform with a decent
UX), and that kind of process overhead isn't something that should just be
waved away.

Edit: Changed accidentally repeated phrasing in middle paragraph

~~~
pjmlp
> automatic transmissions are far, far more common

The Post example doesn't work in Europe or Africa post.

------
pjmlp
Interesting point of view,

> Is C, the language the kernel is for the most part written in, being
> displaced by the likes of Go and Rust, such that there is "a risk that we're
> becoming the COBOL programmers of the 2030s?" Hohndel asked. "C is still one
> of the top 10 languages," answered Torvalds. However, he said that for
> things "not very central to the kernel itself", like drivers, the kernel
> team is looking at "having interfaces to do those, for example, in Rust...
> I'm convinced it's going to happen. It might not be Rust. But it is going to
> happen that we will have different models for writing these kinds of things,
> and C won't be the only one."

------
RMPR
For people asking why the mailing list, among other things, GKH did an ama
session[0] a couple of weeks ago, worth reading before jumping to conclusions
too quickly.

0:
[https://www.reddit.com/r/linux/comments/fx5e4v/im_greg_kroah...](https://www.reddit.com/r/linux/comments/fx5e4v/im_greg_kroahhartman_linux_kernel_developer_ama/)

------
bitwize
If Linus wants a maintainer he can just sign kernel maintainership duties over
to the entity that will end up with them anyway: Red Hat.

~~~
effie
Why would Red Hat want to maintain all of kernel subsystems? They care about
some of them, not all.

------
asfarley
This kind of reminds me of a similar article I saw, saying that Ruby needed
maintainers/contributors.

I contacted the Ruby development team, and was told: "find something to
improve, maybe do an optimization" with no further guidance. So, I moved on to
other things.

------
jgamman
'It's hard to find maintainers' (that will work for free)

------
type0
> Apple is now likely to deliver the kind of Arm-based machine Torvalds has
> been waiting for. ®

But the question is, will it run Linux® ?

~~~
ReverseCold
(Serious reply to joking question...)

No, the bootloader is locked.

------
kerng
Microsoft will come to the rescue

~~~
abriosi
Ahaha. Let me corrected that.

Microsoft has arrived and is rescuing linux

~~~
johnlorentzson
"rescuing"

~~~
stallmanite
Like the US “rescued” Iraq.

------
ta17711771
Speaking of! Any Android devs interested in helping maintain/build out planned
features for:

GrapheneOS (most secure AOSP variant) Vanadium browser Auditor
(attestation.app)

Get in touch by commenting here, or GrapheneOS.org

