Terence EdenFeb 16, 2025

Young folks: Please can we contribute using modern git-based workflow rather than email?
Old farts: No.

👶: OK, but can we at least use modern memory-safe languages?
👴: Also no.

👶: Perhaps we could modernise our language & attitudes to be more inclusive?
👴: LOL! No.

👶: Could we at least consider addressing some long-standing community issues?
👴: What part of "no" are you having trouble understanding?

⏳ ⌛

👴: Why aren't there any new people contributing to our project? Truly a mystery. 🙃

Show threadJonathan CorbetFeb 16, 2025
@Edent So this appears to be a lightly disguised criticism of the kernel project ... the project that is working hard to incorporate Rust into a 30+-year-old code base, is (slowly) developing new contribution tools, and sees 2-300 new contributors in each and every one of its nine-week release cycles.

There are plenty of problems in kernelland, but they will not be improved by a distorted view like this.
Show threadLuis Villa
@corbet @Edent from an outside view, the Rust thing appears to be suffering active sabotage that Linus is making little effort to stop.
Feb 16, 2025 at 4:24pmWeb
Show threadLuis VillaFeb 16, 2025

@corbet @Edent On the contributor numbers, obviously hard to consider the counterfactual but ~1000 new contributors per year sounds very small compared to the size of the codebase, and the very limited turnover of lieutenants suggests they aren’t progressing very far.

Do we have data on how many of those folks actually remain active? Wikipedia has done a lot of work to define and measure new editor retention and it’d be interesting to see some of that borrowed.

Show threadJonathan CorbetFeb 16, 2025
@luis_in_brief @Edent I looked at longevity a bit one year ago: https://lwn.net/Articles/956765/ . I should run those numbers again. The brief answer is that some of those people obviously drop their one patch and move on, but others do indeed stick around for the long term.
Some 6.7 development statistics [LWN.net]

Show threadBinder🅅Feb 18, 2025

@luis_in_brief @corbet @Edent

Not quite...
There are methods for maintaining dual language codebases like this. The rust folks don't want to follow those method and would rather steamroll the whole process. IMO they were correct to push back... happy to chat more indepth on this one.

Show threadJonathan CorbetFeb 18, 2025
@binder @luis_in_brief @Edent Strange, I have not seen much "steamrolling" going on, certainly not on the part of the Rust folks. But, if you have thoughts on how things could run more smoothly, joining the mailing-list discussion with constructive comments might be a good thing to do.
Show threadBinder🅅Feb 18, 2025

@corbet @Edent @luis_in_brief

"steamrolling" being a strong term.

More they were pushing for code where it wasn't wanted. Maintainers should not be "forced" to accept code, and indeed, rust code should 'generally' be kept separate. This of course causes a whole lot of other issues, but that is what you get for having a dual language codebase.

The technical methods to handle these sorts of projects are not complex, the political aspects of course are not.

Many years of OSS have taught me what my strengths are, and political issues are not among them.

If I could give advice (which would not be accepted)... it would be to look at how enterprise handles multi language codebases.