'It's hard to find maintainers': Linus Torvalds ponders Linux's future

'It's hard to find maintainers': Linus Torvalds ponders Linux's future
theregister.com

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.

Microsoft has arrived and is rescuing linux

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.