5 ms·

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 inste

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.
    - franga2000 6y ago
      I really don't see a reason to not use both. Even right now, a maintainer of some subsystem could conceivably create a repo on Gitlab* and accept PRs there, which they could then (rebase-?)merge in and sync with git.kernel.org with Linus never having to know about it. The problem is cultural, as well as organizational. Firstly, I doubt any of the current maintainers would be willing to do that, especially without Linus's blessing and secondly, without a fully managed Gitlab* instance that takes care of sync and whatever else automatically (provided by the Foundation), this would be an unreasonable burden on the maintainers.
      - RMPR 6y ago
        > I really don't see a reason to not use both. Even right now, a maintainer of some subsystem could conceivably create a repo on Gitlab* and accept PRs there, which they could then (rebase-?)merge in and sync with git.kernel.org with Linus never having to know about it. FWIW that's already happening with the BPF subsystem https://github.com/libbpf/libbpf https://github.com/libbpf/libbpf
  - ta17711771 6y ago
    Or Gitea!
kevsim 6y ago
I suspect he also deserves some of the “blame” but maybe not for the reasons you list. He has not exactly made the Linux kernel community a warm and welcoming place historically. Many people can probably think of more fun things to do than get publicly brow beaten by Linus
finnthehuman 6y ago
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.
- kstenerud 6y ago
  If there were a better way to learn guitar, everyone would jump on it. Software doesn't have to be so difficult and tedious to use, as has been demonstrated by a decade of u/x in the UI space. Nowadays, nobody would ever consider gordian knot for their video editing, and I don't blame them. This idea that one must suffer to learn is as outmoded as alchemy. You don't need to take the good with the bad; learn from the bad and make more of it good. I lived though the old times, and they sucked! Nowadays, if the developer doesn't give any thought to u/x, people won't give any thought to his creation, and rightly so. The days of cryptic incantations and tedious rituals are largely over.
  - u801e 6y ago
    > If there were a better way to learn guitar, everyone would jump on it. This type of assertion is made in a lot of contexts, but I don't believe it holds true. I believe that there are a subset of people who are willing to learn a new skill. Of those people, there are very few who are willing to learn a new skill but won't because of some perceived barrier to learning it. The vast majority of that subset will learn the new skill despite the perceived barrier. Of the people who aren't in the set of people who are willing to learn a new skill, there will be very few people who will be movitated to learn the new skill because the perceived barrier to learning it has changed in some way.
Havoc 6y ago
Flip side is there is something to be said for the Kernel not jumping on whatever platform is hot this month. Plus I suspect the crowd capable of contributing meaningfully is quite comfortable with low level old school tech.
u801e 6y ago
> Making kernel development and maintaining more accesible to younger people would increase the pool of potential maintainers. Is there an established open source project out there that originally used a mailing list or some other review software like gerrit, reviewboard, or phabricator, that transitioned to Github or Gitlab and actually increased the number of contributors and maintainers?
- TomJansen 6y ago
  I could be wrong but ReactOS?
ThrowawayR2 6y ago
Surely you jest. Compared to digging around in the kernel and device drivers, the current PR process is probably the most user-friendly and simple-to-use thing that kernel developers deal with in their work.
pklo 6y ago
Of course Linus wrote git, so it's not like he's against modern workflow. There are kernel forks of course, I think that not using web front end is partly due to reluctance to become dependent on an commercial service that Linux people don't control, and partly due to the fact that they like to keep their hands in the mud.
effie 6y ago
Modern does not mean better. Email-based collaboration is most welcoming to new people and good enough for the regular participants. I for one do not want to create an account and learn how some slow web application works for each project when I can do with sending an email.
- icelancer 6y ago
  >> Email-based collaboration is most welcoming to new people What? Aren't new collaborators way more likely to be younger and acquainted with Web-based tools like GitHub/GitLab?
  - effie 6y ago
    New wannabe collaborators maybe. But does the project want to attract only young people who don't care about corporate control creep over free software? Or does it want to attract all able young people including those who understand the benefits of the email based collaboration, which is being the only convenient, decentralized, non-corporate-controlled and the most equitable way for strangers to communicate over the Internet?

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.
  - franga2000 6y ago
    I really don't see a reason to not use both. Even right now, a maintainer of some subsystem could conceivably create a repo on Gitlab* and accept PRs there, which they could then (rebase-?)merge in and sync with git.kernel.org with Linus never having to know about it. The problem is cultural, as well as organizational. Firstly, I doubt any of the current maintainers would be willing to do that, especially without Linus's blessing and secondly, without a fully managed Gitlab* instance that takes care of sync and whatever else automatically (provided by the Foundation), this would be an unreasonable burden on the maintainers.
    - RMPR 6y ago
      > I really don't see a reason to not use both. Even right now, a maintainer of some subsystem could conceivably create a repo on Gitlab* and accept PRs there, which they could then (rebase-?)merge in and sync with git.kernel.org with Linus never having to know about it. FWIW that's already happening with the BPF subsystem https://github.com/libbpf/libbpf https://github.com/libbpf/libbpf
- ta17711771 6y ago
  Or Gitea!

kevsim 6y ago

I suspect he also deserves some of the “blame” but maybe not for the reasons you list. He has not exactly made the Linux kernel community a warm and welcoming place historically. Many people can probably think of more fun things to do than get publicly brow beaten by Linus

finnthehuman 6y ago

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.

kstenerud 6y ago
If there were a better way to learn guitar, everyone would jump on it. Software doesn't have to be so difficult and tedious to use, as has been demonstrated by a decade of u/x in the UI space. Nowadays, nobody would ever consider gordian knot for their video editing, and I don't blame them. This idea that one must suffer to learn is as outmoded as alchemy. You don't need to take the good with the bad; learn from the bad and make more of it good. I lived though the old times, and they sucked! Nowadays, if the developer doesn't give any thought to u/x, people won't give any thought to his creation, and rightly so. The days of cryptic incantations and tedious rituals are largely over.
- u801e 6y ago
  > If there were a better way to learn guitar, everyone would jump on it. This type of assertion is made in a lot of contexts, but I don't believe it holds true. I believe that there are a subset of people who are willing to learn a new skill. Of those people, there are very few who are willing to learn a new skill but won't because of some perceived barrier to learning it. The vast majority of that subset will learn the new skill despite the perceived barrier. Of the people who aren't in the set of people who are willing to learn a new skill, there will be very few people who will be movitated to learn the new skill because the perceived barrier to learning it has changed in some way.

Havoc 6y ago

Flip side is there is something to be said for the Kernel not jumping on whatever platform is hot this month. Plus I suspect the crowd capable of contributing meaningfully is quite comfortable with low level old school tech.

u801e 6y ago

> Making kernel development and maintaining more accesible to younger people would increase the pool of potential maintainers. Is there an established open source project out there that originally used a mailing list or some other review software like gerrit, reviewboard, or phabricator, that transitioned to Github or Gitlab and actually increased the number of contributors and maintainers?

TomJansen 6y ago
I could be wrong but ReactOS?

ThrowawayR2 6y ago

Surely you jest. Compared to digging around in the kernel and device drivers, the current PR process is probably the most user-friendly and simple-to-use thing that kernel developers deal with in their work.

pklo 6y ago

Of course Linus wrote git, so it's not like he's against modern workflow. There are kernel forks of course, I think that not using web front end is partly due to reluctance to become dependent on an commercial service that Linux people don't control, and partly due to the fact that they like to keep their hands in the mud.

effie 6y ago

Modern does not mean better. Email-based collaboration is most welcoming to new people and good enough for the regular participants. I for one do not want to create an account and learn how some slow web application works for each project when I can do with sending an email.

icelancer 6y ago
>> Email-based collaboration is most welcoming to new people What? Aren't new collaborators way more likely to be younger and acquainted with Web-based tools like GitHub/GitLab?
- effie 6y ago
  New wannabe collaborators maybe. But does the project want to attract only young people who don't care about corporate control creep over free software? Or does it want to attract all able young people including those who understand the benefits of the email based collaboration, which is being the only convenient, decentralized, non-corporate-controlled and the most equitable way for strangers to communicate over the Internet?