Name: Hanging out with Linus Torvalds
Uploaded: 2026-02-22T21:32:15.000Z
Duration: 10 min 34 s
Description: Thousands of YouTube videos with English-Chinese subtitles! Now you can learn to understand native speakers, expand your vocabulary, and improve your pronunciation...

Modal verbs - A2

I actually did have a question for you that could be interesting on camera.

Past simple

A friend of mine had some kernel experience writing drivers for amd.

And he heard you say a little while ago that there's not enough contributors or you're having a hard time finding contributors.

And he wondered where to start to look into what he could do.

So I think that probably came not so much from contributors as we have a hard time finding.

We have a harder time finding maintainers.

So the problem is there's a lot of programmers, a lot of them actually getting paid to do Linux kernel work, but

it's much harder to find the kind of person who stays around for years.

When you're a maintainer, it's not just that you have to know coding.

You have to have enough of a background that people know, you know, coding.

There has to be some mind, like knowledge about you and you can't come from nothing.

And the other thing is you have to be pretty good at communication too.

I think it's harder to find maintainers than it is to find people to code.

I mean, we have tons of developers who like doing the coding part.

I think people are kind of scared of taking the next step.

People think that it's harder or think that the expectations aren't necessarily higher than they.

The only thing you have to do is you have to step up.

You have to have done enough that people recognize your name.

Then you have to just step up and say, hey, I'd like to help maintain this area.

And if you do that, the answer almost certainly is going to be yes, we want people who help maintain an area.

Is it that you're going to be contributing and passing up the chain first?

Yeah, yeah, you do have to basically start.

It's kind of like a lot of companies have this policy that you grow from within, that everybody starts at the bottom.

And it doesn't have to be bottom bottom, but

you have to start out being a programmer that writes code, or not necessarily even code documentation is the exact same is true of do implementation tests and stuff like that.

We have maintainers for all of those areas.

You can't just say, show up and say, hey, I'd like to help.

What you have to do is you write some code so that people get to know.

And then when they know you, when you Say, hey, I'd like to help maintain and help carry like spread the burden around of maintenance.

Sorry, I'm not going to sneak in and grab.

I know I'm the one who put you guys here.

We have a ton of people who I'm sure would have more people reviewing patches.

So when you say that, you have to see how shy they are.

I just spent the last two hours with you though, so I experience they can't come from nothing.

Do you mean with the Linux project specifically, with just coding in general?

I mean, yes, you probably have experience from other sources too.

Maybe you had other projects, maybe you were doing commercial.

But in order to get that name recognition where people know who you are.

Because that's, I think like personal trust is a big deal in open source.

It's like you got hired, you're working at the same company, so we trust you kind of thing.

You're part of the team now because our manager put you on the team.

Gone through the process, we verify and in open source, that's not how it works.

Open source, it's like, I trust you because I seen you around.

Doesn't necessarily take very long, right?

I mean, they've been around for ages now, but

there are maintainers who became maintainers in a couple of months because they just, they showed that, hey, they know what they're doing, they were being helpful and doing the right things.

And everybody said, yes, please, come on.

I say it's not that hard, but I only see the other side of it.

So I may not see all the people who struggled and never put in.

So getting your foot in the door is like showing up and communicating with people who are on the project, seeing where you can lend a hand reviewing documentation, reviewing.

That's probably the first thing to do even before you start reviewing.

Because in order for people to know that your reviews are worthwhile, they need to kind of know that your code is worthwhile.

I mean, that's one of the advantages of the URL.

There are tons of different areas, right?

Find the device or the architecture or whatever that you are interested in.

Sometimes it could be files, it could be encryption, it could be whatever.

There's a lot of code and find something that you care about and that you think you know something about and that you can see something proving you find something you don't like, fix it, you send a patch, you communicate with the maintainer, the existing maintainer of that problem, and

that's how you kind of get the communication going.

Find something you've got a real itch for.

I mean, the kernel may be a high profile project and one of the biggest ones around there, but

let's be honest, there's thousands of open source projects and kernels are kind of.

I think kernels are the most interesting ones.

Realistically we do have 35 years code, so quite often if there's something new that needs new code, it's often like new hardware support.

So that's, that's quite often how people get into kernel maintenance, because that's where they're.