
Graying Linux developers look for new blood - tanglesome
http://www.zdnet.com/graying-linux-developers-look-for-new-blood-7000020026/
======
hackula1
1) Worst reputation for verbal abuse of any open source project around

2) Actively cultivated reputation for being esoteric and difficult to get
started in

3) Few "big wins" left. Young devs want to work where there is plenty of land
to conquer. This often leads to a jump towards new platforms with plenty of
low hanging fruit (node.js is a great example of this in action at the moment,
and I say this as a node.js guy in his twenties).

~~~
bifrost
> 2) Actively cultivated reputation for being esoteric and difficult to get
> started in

You're kidding, right? Kernel programming is not like sitting down and bro-ing
out some code to make a webapp, its actually fairly difficult to get right. It
should be hard to get code into the kernel, because you know, its a vitally
important part of how your computer runs.

This is actually a big part of the problem with Linux in the first place, for
quite some time it was much too easy to get bad code into the kernel and
stability and security suffered. Now that its finally becoming important to
people, you don't get /dev/beer added in a week...

~~~
NegativeK
While I completely agree with your underlying point, your tone is a bit silly
in a not good way.

~~~
bifrost
My tone is fine.

While I appreciate enthusiasm for projects, enthusiasm without skill is a net
loss for everyone working on the project, and thats what the author was
proposing. Its a horrible idea and it hurts the entire community to suggest
that inclusiveness increases productivity because it does not.

------
joe_the_user
I doubt there's going to be a real problem or that this is something that open
source advocates should worry about.

The Linux Kernel is behind a lot of real software that makes real money. If
Google wants, say, a better kernel to put underneath Android, it can pay for
the developers and the development involved, just for one example.

It's true that the desktop in particular might be more like a charity case.
But Kernel development seems only peripherally connected and peripherally
concerned with this.

If any younger developers want to donate their time to a worthwhile open
source project, there are many other projects that probably won't get
attention unless someone donates time.

~~~
sliverstorm
Considering something like 85% of kernel work is already sponsored...

Short snippet: [https://www.linux.com/learn/tutorials/560928-counting-
contri...](https://www.linux.com/learn/tutorials/560928-counting-
contributions-who-wrote-linux-32)

Full document: [http://go.linuxfoundation.org/who-writes-
linux-2012](http://go.linuxfoundation.org/who-writes-linux-2012)

~~~
joe_the_user
Sure,

Seems to go with what I posted above.

If these sponsors want younger developers, I would assume they have the money
to recruit them. Otherwise, things seem to be going fine for the Kernel as it
is.

------
uuilly
Being a little more friendly could help their cause.

~~~
Demiurge
Rewriting linux from scratch in a cool language like Go would also help a lot.

~~~
greenyoda
Go doesn't even support all of the architectures on which Linux runs, for
example, IBM mainframes.

Not to mention that a language that relies on its own automatic memory
management (garbage collection) might not work so well for kernel programming.

~~~
Demiurge
I thought it was obvious that it was a joke motivated by the recent headlines
on HN...

------
samspenc
Modifying the Linux kernel was part of my undergrad OS course; I wonder if
schools should start more advanced Linux kernel courses and encourage students
to really work on the Linux kernel.

IMHO, its also good for the resume; I would think having contributed to the
Linux kernel would be a significant plus on anyone's resume.

~~~
netvarun
What course was that you took and from which school? That sounds like a really
awesome OS course!

~~~
zanny
I had a project in my OS 300 level class to implement a false IO device with
supporting system calls on a custom kernel. In practice, it was 3 - 4 .c files
and around 200 lines total.

------
null_ptr
Say I'm a 20-something with strong C and systems programming skills. Can I
earn a living contributing to the Linux kernel? Would the Linux Foundation
invest in training and mentoring me for a year or two until I become self-
sufficient and am able to do the same for the next novice?

~~~
fantnn
No, just work at Red Hat or Google, they pay plenty of people to actively
contribute to kernel development.

~~~
pyre
IBM did at one point too. Have they stopped?

------
penguindev
I have been wondering about the demographics of software developers in
general, and if there is going to be a larger per-year number of retiring
senior people in the coming years than there have been in the past, due to
programming being a young industry overall.

That could stabilize the total number of workers in the field - instead of
growing it - but could also start an additional per-year drain on senior
knowledge.

It's just my uninformed imagination, though.

------
atmosx
That's fair enough:

Programming is a considerably new craft. Linux kernel gets more and more
advanced, people need experience to write code. Experienced are older. That's
all there is to it.

20 years back you couldn't have 8.000 40-year old C/ASM developers working on
an open source project. Now you can and they happen to write _better code_
than younger developers, which makes sense, that's all there is to it imho.

------
txutxu
At the beginning, we had to listen: "Linux? bah, that's 4 hippies..."

Now this fact seems to be based on real data.

"Linux? bah, that's 4 grandpas..."

Hippies or grandpas, thanks to all, by each commit.

------
tytso
My comment which I made on SVN's G+ page:

I'm not actually worried about the demographics in the sense of the Bitergia
analysis. If you actually look at the number of newcomers showing up in each
of the graphs (the 0-1 year bar), you'll see that it's generally growing, not
shrinking. And of _course_ over time some people will move on to other
projects (example: Jeff Garzik was invited to the Kernel Summit before he
started as a freshman at MIT, but he's now moved on to work on the bitcoin
project). So you would expect that over time, the number of people in
successive generations will start dropping off. So their analysis is actually
quite sloppy as far as I'm concerned. If the total number of developers
submitting patches is growing, and we have a constant supply of new people
joining the project, it's all good.

Right now, the sense that I get is that companies are having problems finding
high quality kernel developers. So people who are hobbyists and who
demonstrate great skill tend not to stay hobbyists for very long; they will
get hired, unless they have other reasons for staying put. (Example: if I had
joined Red Hat or SuSE much earlier, before the IPO mania, instead of staying
at MIT working on Kerberos and IPSEC and doing standards work for the IETF,
and only doing Linux has a hobby until 1999, my financial situation today
would probably be quite different; not that I'm complaining, mind you! The
things that I got to work on while I was MIT was interesting, and I made a
conscious choice to stay there.)

So to the extent that finding good engineers is hard for many companies, it's
not surprising that we're trying to make sure we can attract new talent. That
being said, those of us who were on the Kernel Summit program committee who
decided that doing an explicit call for hobbyists did not consult with Amanda
and Angela who decided to hold a Newcomer's reception. There was no grand
plan; like many things in the Linux world, we have a decentralized command and
control, and this was not the result of any kind of central planning. The
senior engineers on the program committee, and the staff at the LF who have
much greater contact with the executives at their member companies may have
been reacting to similar observations about the job market for highly skilled
developers, but we made our decisions on our own. So what you saw was emergent
behavior; it wasn't an conscious decision by any one person to have an
integrated campaign.

That being said, a bigger concern I have is not really the greying of the
community, but what's our next challenge. We get the most innovation, and new
developers (whether they be engineers employed by companies, or hobbyists)
when we are responding to a new challenge. For example, for a while, we had a
huge effort making Linux better for enterprise computing and enterprise
servers. That tailed off, and then cloud computing and mobile/embedded Linux
started taking off, and folks who had previously worked for HP and IBM have
migrated to other companies, and there aren't as many people focused on making
Linux better for enterprise servers. So the question is what's the next
challenge?

What part of the I/T industry will Linux be disrupting next? What interesting
technical problems will there be for us to tackle as engineers? What business
opportunities will cause companies to increase their investment in Linux, and
thus hire engineers to work on improving Linux so they can make a healthy
return on their investment? What new set of companies will be the next
generation of platinum sponsors for the Linux Foundation?

The opportunity to make Linux better-suited for the cloud and mobile/embedded
computing won't last forever. So long as we can find that next opportunity,
I'm really not worried about the health of the Linux kernel development
community. We will continue to have technically interesting challenges, which
will keep the hobbyists and as well as professional engineers engaged; and
there will be opportunities to make money, which will keep companies
continuing to invest in Linux, and people like me employed. :-)﻿

