Andrew Morton:
There is a great amount to learn, and you don't learn it by reading the
code, or by reading the mailing list. You have to actually get in
there and change something. It's only when you try to do the hands-on
things that you realize how much you don't know.

And to get hands-on, you need a *reason*.

Profile the kernel, try to fix a performance bottleneck.

Pick a neglected bug report off the kernel list, work it with the
originator, see if you can fix it.

Pick a neglected device driver or filesystem, try to improve it.

There are new block and net driver interfaces coming through in 2.5 -
pick a driver for which you have hardware and take care of it.

Don't spout off opinions on the kernel mailing list.

Ignore what the kernel developers say about C++.

If you need to write, say, a net driver then don't! First, take an
existing one and make it beautiful, or more correct, or twice as fast,
or add a feature. Then take that knowledge to the new driver.

One hot tip: if you spot a bug which is being ignored, send a
completely botched fix to the mailing list. This causes thousands of
kernel developers to rally to the cause. Nobody knows why this
happens. (I really have deliberately done this several times. It works).

Write a really good filesystem and VM performance measurement suite
which models real-world workloads. The existing ones are almost
useless for this, and this gap in the toolset makes it much harder to
tune filesystems, and to discover performance improvements and
regressions.

There are many things to do, and Linux doesn't really need thousands
of people adding even more code.