9 ms·

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

82 points by ASVVVAD 6y ago

kerng 6y ago
Microsoft will come to the rescue
- abriosi 6y ago
  Ahaha. Let me corrected that. Microsoft has arrived and is rescuing linux
  - johnlorentzson 6y ago
    "rescuing"
    - stallmanite 6y ago
      Like the US “rescued” Iraq.
- pjmlp 6y ago
  I thought that Google did it first.
aboringusername 6y ago
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 6y ago
  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 6y ago
    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
- imtringued 6y ago
  I always wonder why most projects don't have an onboarding process where you get in touch with the maintainers and discuss the roadmap and how to help even if you personally don't have a specific issue you want to work on. For me I submit pull requests to open source projects when I personally need them and then leave once the work is complete. That's basically the opposite of what it takes to retain maintainers. Maintainers usually write code for the sake of others and not for themselves and they stay for much longer periods of time.
- nujabe 6y ago
  These are some very good suggestions. I think they should take note on how the Kubernetes project operates, with the various interest groups, Slack channels, meeting notes + their recordings on Youtube. I think those channels catch a large part of the history of the development. I'm not sure if Linux uses anything beyond mailing lists.....
kyran_adept 6y ago
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.
- ssivark 6y ago
  Keep in mind that linux is a 25+ year old project with established practices which might well outlast fads of web-driven development which might change every few years. Yes, Github/etc provide a friendlier interface for newbies (and might well be worth considering seriously) but note that there is almost no open source project that is on the same scale of collaboration complexity as the linux kernel, and it is far from obvious that they would be well served by popular platforms. Not to mention the whole Bitkeeper SNAFU that came out of becoming dependent on a platform they did not control; they would be very reluctant to put themselves in such a vulnerable position again. Github can decide on a whim to de-platform certain projects/customers/users (and has demonstrated a willingness to do so).
  - vlovich123 6y ago
    I'd put LLVM/Clang, Chrome, and AOSP into those categories. They all have more modern development tools than e-mailing patch-sets around.
  - Barrin92 6y ago
    There's no need to rely on a third party provider given that it's possible to host say, Gitlab yourself. For a project of the size of the linux kernel that's more than a worthwhile investment.
    - ssivark 6y ago
      In this context it’s wise to move conservatively. Gitlab has “come of age” only in the last few years. We see that KDE is now moving. If that works well, I wouldn’t be surprised if other OSS projects slowly start migrating. Remember that there is heavy organizational inertia and culture on the LKML. Moving to Gitlab is practically akin to gutting that and beginning a fresh project with forked code — the kind of cultural makeover that most companies don’t survive, and won’t do unless they’re forced to. And maintaining starting culture is even more crucial for volunteer-driven projects than for corporate projects with very different incentives.
aSplash0fDerp 6y ago
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 6y ago
  Linux is successful because of: "WE DO NOT BREAK USERSPACE". It is Linus policy and work with community that made it most popular OS.
  - aSplash0fDerp 6y ago
    Well, with all of the swinging C.o.C. puns available, I'll tread safely and just point out L.T. never seemed to be about compromising quality over making people happy. Solid state does not have squeaky wheels.... Somethings amiss here....
  - yencabulator 6y ago
    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.)
bitwize 6y ago
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 6y ago
  Why would Red Hat want to maintain all of kernel subsystems? They care about some of them, not all.
type0 6y ago
> 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 6y ago
  (Serious reply to joking question...) No, the bootloader is locked.
ta17711771 6y ago
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
pjmlp 6y ago
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 6y ago
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_kroahhartman_linux_kernel_developer_ama/ https://www.reddit.com/r/linux/comments/fx5e4v/im_greg_kroah...
jgamman 6y ago
'It's hard to find maintainers' (that will work for free)
asfarley 6y ago
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.

82 points by ASVVVAD 6y ago

kerng 6y ago

Microsoft will come to the rescue

abriosi 6y ago
Ahaha. Let me corrected that. Microsoft has arrived and is rescuing linux
- johnlorentzson 6y ago
  "rescuing"
  - stallmanite 6y ago
    Like the US “rescued” Iraq.
pjmlp 6y ago
I thought that Google did it first.

aboringusername 6y ago

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 6y ago
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 6y ago
  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
imtringued 6y ago
I always wonder why most projects don't have an onboarding process where you get in touch with the maintainers and discuss the roadmap and how to help even if you personally don't have a specific issue you want to work on. For me I submit pull requests to open source projects when I personally need them and then leave once the work is complete. That's basically the opposite of what it takes to retain maintainers. Maintainers usually write code for the sake of others and not for themselves and they stay for much longer periods of time.
nujabe 6y ago
These are some very good suggestions. I think they should take note on how the Kubernetes project operates, with the various interest groups, Slack channels, meeting notes + their recordings on Youtube. I think those channels catch a large part of the history of the development. I'm not sure if Linux uses anything beyond mailing lists.....

kyran_adept 6y ago

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.

ssivark 6y ago
Keep in mind that linux is a 25+ year old project with established practices which might well outlast fads of web-driven development which might change every few years. Yes, Github/etc provide a friendlier interface for newbies (and might well be worth considering seriously) but note that there is almost no open source project that is on the same scale of collaboration complexity as the linux kernel, and it is far from obvious that they would be well served by popular platforms. Not to mention the whole Bitkeeper SNAFU that came out of becoming dependent on a platform they did not control; they would be very reluctant to put themselves in such a vulnerable position again. Github can decide on a whim to de-platform certain projects/customers/users (and has demonstrated a willingness to do so).
- vlovich123 6y ago
  I'd put LLVM/Clang, Chrome, and AOSP into those categories. They all have more modern development tools than e-mailing patch-sets around.
- Barrin92 6y ago
  There's no need to rely on a third party provider given that it's possible to host say, Gitlab yourself. For a project of the size of the linux kernel that's more than a worthwhile investment.
  - ssivark 6y ago
    In this context it’s wise to move conservatively. Gitlab has “come of age” only in the last few years. We see that KDE is now moving. If that works well, I wouldn’t be surprised if other OSS projects slowly start migrating. Remember that there is heavy organizational inertia and culture on the LKML. Moving to Gitlab is practically akin to gutting that and beginning a fresh project with forked code — the kind of cultural makeover that most companies don’t survive, and won’t do unless they’re forced to. And maintaining starting culture is even more crucial for volunteer-driven projects than for corporate projects with very different incentives.

aSplash0fDerp 6y ago

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 6y ago
Linux is successful because of: "WE DO NOT BREAK USERSPACE". It is Linus policy and work with community that made it most popular OS.
- aSplash0fDerp 6y ago
  Well, with all of the swinging C.o.C. puns available, I'll tread safely and just point out L.T. never seemed to be about compromising quality over making people happy. Solid state does not have squeaky wheels.... Somethings amiss here....
- yencabulator 6y ago
  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.)

bitwize 6y ago

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 6y ago
Why would Red Hat want to maintain all of kernel subsystems? They care about some of them, not all.

type0 6y ago

> 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 6y ago
(Serious reply to joking question...) No, the bootloader is locked.

ta17711771 6y ago

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

pjmlp 6y ago

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 6y ago

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_kroahhartman_linux_kernel_developer_ama/ https://www.reddit.com/r/linux/comments/fx5e4v/im_greg_kroah...

jgamman 6y ago

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

asfarley 6y ago

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.