[ssivark]

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).

[Barrin92]

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]

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]

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]

> 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

[ta17711771]

Or Gitea!

[vlovich123]

I'd put LLVM/Clang, Chrome, and AOSP into those categories. They all have more modern development tools than e-mailing patch-sets around.