source mgt. requirements solicitation

[Nathanael Nerode]

Linus said:
>Naah. It's simple - kernels are just sexier.
That I believe. :-)

>Seriously, I think it's just that a kernel tends to have more different
>_kinds_ of problems, and thus tend to attract different kinds of 
>people, and more of them.
I really don't think so.  A kernel has more easy problems, in a 
certain sense: more problems that can be started by people with little 
background.  A compiler has *lots* of different types of problems, but 
they're almost all rather complicated and hard to start on, for a reason 
I mention at the end of this.

>people who are interested in one of them. So you'll find people who 
>care about filesystems, 
We got that in compilers...

>or people who care about memory management, or 
We got that...

>people who find it interesting to do concurrency work
We got that...

>or IO paths.
We got that...

Heh.  I think the real reason why fewer people work on compilers is 
one of abstraction.  To oversimplify, a kernel just *does* things.  
A compiler is one level more abstract; it takes input and converts it 
into code which does things.  It takes some practice to get comfortable 
with, and good at, that style of coding, and it's significantly harder 
to debug.  While I'm sure there's some kernel code like that, *most* 
compiler code is like this.  Given GCC's design, we even have two 
levels of abstraction: the build system compiles and runs programs 
to generate a compiler for a specific host-target pair.  This is code 
to generate code to generate code.

--Nathanael