6 ms·

Graying Linux developers look for new blood

38 points by tanglesome 13y ago

uuilly 13y ago
Being a little more friendly could help their cause.
- jamesaguilar 13y ago
  Careful, keep talking like this and you're liable to be informed that cursing someone out is efficient communication by the HN crowd. It's hard, but I think what needs to happen here is a culture of mentoring like in most successful software companies. If there is such a thing for aspiring Linux devs, I've never heard of it.
  - anonymous 13y ago
    Well, it is efficient if you want to minimise the number of people who aren't star programmers with hard heads and don't care how many star programmers with manners you turn away. If your supply pool is big enough, you will have great success. Hypothetically though - would it be that much better if Linus et al. were turning away people politely with words like "this code doesn't meet our standards of quality because X Y Z" instead of "your code is shit, see X Y Z"? Also, for people at the lead, you need those who can say "no", know when to say "no", aren't going to compromise just because the patch was sent by so-and-so and won't hold back from saying where they see a problem. You also want them to be good at communicating with people in a civil manner. The two are unfortunately orthogonal qualities. It seems to me that we should first take the people who are definitely good enough in the engineering aspect to understand and lead the project, then select the best communicator, rather than seeking someone with a best average score at engineering and communicating. You might get impolite people at the top, but you will guarantee the project won't get worse.
    - takluyver 13y ago
      > would it be that much better if Linus et al. were turning away people politely with words like "this code doesn't meet our standards of quality because X Y Z" It seems quite reasonable to imagine that more of those people would come back and try again if they were treated politely. Working with new contributors takes time at first, but it's an investment that you hope will pay back when they're productive core developers.
      - SEMW 13y ago
        See https://lwn.net/Articles/559061/ https://lwn.net/Articles/559061/ for a recent discussion about the tone of LKML.
  - zanny 13y ago
    Come on, Linus curses out one guy a year and it always hits HN front page. It isn't like your kernel commits are going to get you an angry veto with 90% explitive vocabulary density on a daily basis, it is the exception that people like to point out.
  - bitwize 13y ago
    When Linux curses someone out, it is usually someone who's been in the community for a while and should have known better than to push the crappy code they pushed. If you're a kernel n00b, chances are you will not be submitting your patches to Linus himself but someone two or three levels down from him, the maintainer of some driver or FS or virtual memory subsystem, who will tell you in nicer terms what you did wrong and how to fix it. By the time you get to the submitting to Linus stage, it is assumed that you will have your shit in one sock, code-wise; violating that assumption is what earns you the Finnish-obscenity-laden opprobrium.
    - jlgreco 13y ago
      Exactly right; this notion that people here have of kernel devs spewing vitriol with reckless abandon at anybody not in their club is pure fantasy. Why does it persist? Because normal conversations from kernel dev mailing lists are boring while the occasional directed vitriol is very amusing and spawns lots of heated discussions on Slashdot and HN. That, and because calling people out for "things", whether those "things" are cursing, or any other number of things on other days, makes people feel good and superior. See? I'm doing it right now. ;)
- munin 13y ago
  seriously, why subject yourself to that kind of acidic ridicule when you can make more public contributions working on things closer to the frontend. doing the systems engineering work to make the kernel go is very important, but unless you're at the very very top (linus) nobody is going to care about you.
  - uuilly 13y ago
    That depends a lot on your industry. At most places I've worked, nobody knew what node.js or bootstrap was. At all those places being a journeyman kernel dev would look REALLY good.
  - jlgreco 13y ago
    "Padding your resume" is not a priority shared by everybody. Many people contribute to projects that are not visible because they see an inadequacy and they believe they have a solution. Or you know, for fun. Fun is pretty independent of visibility, if it wasn't then single-player video-games wouldn't exist.
- rubiquity 13y ago
  Since when is Linus the only middle aged person working on Linux? Your comment reeks of ignorance and cargo culting.
  - pyre 13y ago
    Are you suggesting that Linus is the only person in FOSS that cusses people out?
    - chatman 13y ago
      Linus is against free software [0]. Linus publicly abuses fellow developers for making mistakes [1] Linus representing "FOSS" just doesn't sound right. Look at RMS for a real leader. [0] - www.youtube.com/watch?v=bw58LZTuZjA [1] - news.ycombinator.com/item?id=5107386
      - pyre 13y ago
        I'm aware of Linus' thoughts on Free Software. Regardless of those thoughts the Linux kernel is a Free Software project, and by extension Linus is a "person in FOSS."
    - rubiquity 13y ago
      No I'm saying the exact opposite.
- Demiurge 13y ago
  Rewriting linux from scratch in a cool language like Go would also help a lot.
  - deleted 13y ago
    [deleted]
    - deleted 13y ago
      [deleted]
  - pyre 13y ago
    Yes. The Linux kernel should be entirely rewritten every 5-10 years so that it can be in the latest "trendy" programming languages.
  - vikas0380 13y ago
    Or in java or any other language
    - Demiurge 13y ago
      As long as it's cool and has goroutines and interfaces and no semicolons.
  - greenyoda 13y ago
    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 13y ago
      I thought it was obvious that it was a joke motivated by the recent headlines on HN...
  - bifrost 13y ago
    I think it should be rewritten in assembler, because its so old its retro and now will become the new hotness.
- anigbrowl 13y ago
  Or user-friendly for that matter. I think it's pointless to keep using utilities with titles like man, cp, ls, fsck, grep etc., which are are extremely unintuitive to most people. We're not using 300 bps dumb terminals any more, but the Unix command line remains about as friendly as a leopard. I hated this ~20 years ago when I first learned Linux, but it was the price I had to pay to set up my own domain and hey, a free Unix clone. But two decades later, it's still pretty unfriendly, and a there's still a lot of command-line snobbery that seems dedicated to preserving this unintentional but obsolete obscurantism, like thoroughbred horse breeders who refuse to acknowledge the market's preference for cars and bicycles.
  - zanny 13y ago
    I agree with this. A lot of the limitations of 1980s unix no longer exist, yet we still constrain our terminals to obtuse nomenclature and bad syntax like we only have 80 characters before the terminal auto-returns.
  - kragniz 13y ago
    I believe we're talking about kernel development here, not GNU utilities. However, what naming scheme would you prefer? The command line is fairly unintuitive as it is. I would argue it is preferable to have short, memorable and fast to type names.
    - nsmartt 13y ago
      To be fair, it's entirely possible to create aliases with more intuitive names and dump a "you can type ____ for short" message on each run.
      - jlgreco 13y ago
        Which leads me to suspect that if there were a demand for "a big file to source in your bashrc to alias 'cp' to 'copy'", it would exist. It is not exactly a difficult thing to do, but nobody actually cares enough to do it (probably because it is not actually a problem).
penguindev 13y ago
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.
samspenc 13y ago
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 13y ago
  What course was that you took and from which school? That sounds like a really awesome OS course!
  - zanny 13y ago
    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.
- pavel_lishin 13y ago
  What sort of changes did you and your classmates end up making? Were you contributing to the kernel codebase, or just modifying it for personal/class use? Sounds like a pretty interesting and practical assignment.
  - samspenc 13y ago
    This was years ago, so I can't remember any of the assignments, but I remember they were mostly simple changes to the kernel - but we had to actually re-compile the Linux kernel, make sure it booted up and worked the way it was supposed to! :) In some cases it was data structure changes, in some, it was small improvements to some algorithms. Quite challenging in the beginning, but by the end, I was actually having fun playing with the Linux kernel and watching a custom kernel boot up and work perfectly!
joe_the_user 13y ago
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 13y ago
  Considering something like 85% of kernel work is already sponsored... Short snippet: https://www.linux.com/learn/tutorials/560928-counting-contributions-who-wrote-linux-32 https://www.linux.com/learn/tutorials/560928-counting-contri... Full document: http://go.linuxfoundation.org/who-writes-linux-2012 http://go.linuxfoundation.org/who-writes-linux-2012
  - joe_the_user 13y ago
    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.
- chatman 13y ago
  This post is not about desktop GNU/Linux applications. There are plenty of upcoming developers in and a lot of buzz around GNOME, for example. This post is only about the Linux kernel of the GNU/Linux operating system.
- zanny 13y ago
  I'm one of those young developers in the Linux space that doesn't go near the kernel with a 10 foot pole, for four reasons: 1. It is a monolith. The actual kernel parts that matter for an executing preemtive virtual memory virtual fs operating system are probably 1/100th the code base - most of it is device drivers. That core stuff has been chizzled to a fine point, and I'm not a device manufacturer so I'm not working on drivers. If I were to get involved in any part, I'd have to worry about leaking into other parts, and interacting with a massive developer web. 2. It is C. As a C++ guy, whenever I have to write out each type handler of a function I'd rather write as a template I want to beat my face on the keyboard. i just can't write C anymore because every 3 lines there is some productivity boon or maintainability gain I could have from modern C++ I miss too much. In the general case, not many young developers want to write C. They either like their Rubies and Pythons, or want a broader native language to work with than strict imperative. 3. I can better invest time and make a difference in more modern projects. I contribute a lot to KDE and game emulator projects, rather than try to fix the low level stuff that other developers are significantly more well versed in than me. Which also (in the LInux world) is also all written in C. Except GCC, but they have guidelines on what C++ features you are allowed to use which really limits the utility of the language in some places. 4. The learning curve is a mountain. I had a project in my BS to implement a simple system call and compile a custom kernel, but anything beyond that has broad reaching effects and a requirement to read thousands of lines before even starting, at least in the capacity I would feel safe writing code for something executing in the highest proecessor state with complete system access without worrying about mucking it up. I'm wondering if in, say, another 10 years, we see a microkernel with userspace drivers pop up the way LLVM has become popular against GCC not only because of the licensing and Apple backing but also because it is deeply modular and much easier to implement new langauges on compared to GCC. Maybe the magnitude and pressure in Linux might one day become unbearable and force a transition to something in the same capacity.
hackula1 13y ago
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 13y ago
  > 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 13y ago
    While I completely agree with your underlying point, your tone is a bit silly in a not good way.
    - bifrost 13y ago
      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.
  - Ygg2 13y ago
    Well then why does the foundation attempt to extend to hobbyist programmers? You can't have it both ways - having hobbyist/web programmers and highly educated in the ways hardware works.
null_ptr 13y ago
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 13y ago
  No, just work at Red Hat or Google, they pay plenty of people to actively contribute to kernel development.
  - pyre 13y ago
    IBM did at one point too. Have they stopped?
atmosx 13y ago
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 13y ago
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 13y ago
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. :-)

38 points by tanglesome 13y ago

uuilly 13y ago

Being a little more friendly could help their cause.

jamesaguilar 13y ago
Careful, keep talking like this and you're liable to be informed that cursing someone out is efficient communication by the HN crowd. It's hard, but I think what needs to happen here is a culture of mentoring like in most successful software companies. If there is such a thing for aspiring Linux devs, I've never heard of it.
- anonymous 13y ago
  Well, it is efficient if you want to minimise the number of people who aren't star programmers with hard heads and don't care how many star programmers with manners you turn away. If your supply pool is big enough, you will have great success. Hypothetically though - would it be that much better if Linus et al. were turning away people politely with words like "this code doesn't meet our standards of quality because X Y Z" instead of "your code is shit, see X Y Z"? Also, for people at the lead, you need those who can say "no", know when to say "no", aren't going to compromise just because the patch was sent by so-and-so and won't hold back from saying where they see a problem. You also want them to be good at communicating with people in a civil manner. The two are unfortunately orthogonal qualities. It seems to me that we should first take the people who are definitely good enough in the engineering aspect to understand and lead the project, then select the best communicator, rather than seeking someone with a best average score at engineering and communicating. You might get impolite people at the top, but you will guarantee the project won't get worse.
  - takluyver 13y ago
    > would it be that much better if Linus et al. were turning away people politely with words like "this code doesn't meet our standards of quality because X Y Z" It seems quite reasonable to imagine that more of those people would come back and try again if they were treated politely. Working with new contributors takes time at first, but it's an investment that you hope will pay back when they're productive core developers.
    - SEMW 13y ago
      See https://lwn.net/Articles/559061/ https://lwn.net/Articles/559061/ for a recent discussion about the tone of LKML.
- zanny 13y ago
  Come on, Linus curses out one guy a year and it always hits HN front page. It isn't like your kernel commits are going to get you an angry veto with 90% explitive vocabulary density on a daily basis, it is the exception that people like to point out.
- bitwize 13y ago
  When Linux curses someone out, it is usually someone who's been in the community for a while and should have known better than to push the crappy code they pushed. If you're a kernel n00b, chances are you will not be submitting your patches to Linus himself but someone two or three levels down from him, the maintainer of some driver or FS or virtual memory subsystem, who will tell you in nicer terms what you did wrong and how to fix it. By the time you get to the submitting to Linus stage, it is assumed that you will have your shit in one sock, code-wise; violating that assumption is what earns you the Finnish-obscenity-laden opprobrium.
  - jlgreco 13y ago
    Exactly right; this notion that people here have of kernel devs spewing vitriol with reckless abandon at anybody not in their club is pure fantasy. Why does it persist? Because normal conversations from kernel dev mailing lists are boring while the occasional directed vitriol is very amusing and spawns lots of heated discussions on Slashdot and HN. That, and because calling people out for "things", whether those "things" are cursing, or any other number of things on other days, makes people feel good and superior. See? I'm doing it right now. ;)
munin 13y ago
seriously, why subject yourself to that kind of acidic ridicule when you can make more public contributions working on things closer to the frontend. doing the systems engineering work to make the kernel go is very important, but unless you're at the very very top (linus) nobody is going to care about you.
- uuilly 13y ago
  That depends a lot on your industry. At most places I've worked, nobody knew what node.js or bootstrap was. At all those places being a journeyman kernel dev would look REALLY good.
- jlgreco 13y ago
  "Padding your resume" is not a priority shared by everybody. Many people contribute to projects that are not visible because they see an inadequacy and they believe they have a solution. Or you know, for fun. Fun is pretty independent of visibility, if it wasn't then single-player video-games wouldn't exist.
rubiquity 13y ago
Since when is Linus the only middle aged person working on Linux? Your comment reeks of ignorance and cargo culting.
- pyre 13y ago
  Are you suggesting that Linus is the only person in FOSS that cusses people out?
  - chatman 13y ago
    Linus is against free software [0]. Linus publicly abuses fellow developers for making mistakes [1] Linus representing "FOSS" just doesn't sound right. Look at RMS for a real leader. [0] - www.youtube.com/watch?v=bw58LZTuZjA [1] - news.ycombinator.com/item?id=5107386
    - pyre 13y ago
      I'm aware of Linus' thoughts on Free Software. Regardless of those thoughts the Linux kernel is a Free Software project, and by extension Linus is a "person in FOSS."
  - rubiquity 13y ago
    No I'm saying the exact opposite.
Demiurge 13y ago
Rewriting linux from scratch in a cool language like Go would also help a lot.
- deleted 13y ago
  [deleted]
  - deleted 13y ago
    [deleted]
- pyre 13y ago
  Yes. The Linux kernel should be entirely rewritten every 5-10 years so that it can be in the latest "trendy" programming languages.
- vikas0380 13y ago
  Or in java or any other language
  - Demiurge 13y ago
    As long as it's cool and has goroutines and interfaces and no semicolons.
- greenyoda 13y ago
  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 13y ago
    I thought it was obvious that it was a joke motivated by the recent headlines on HN...
- bifrost 13y ago
  I think it should be rewritten in assembler, because its so old its retro and now will become the new hotness.
anigbrowl 13y ago
Or user-friendly for that matter. I think it's pointless to keep using utilities with titles like man, cp, ls, fsck, grep etc., which are are extremely unintuitive to most people. We're not using 300 bps dumb terminals any more, but the Unix command line remains about as friendly as a leopard. I hated this ~20 years ago when I first learned Linux, but it was the price I had to pay to set up my own domain and hey, a free Unix clone. But two decades later, it's still pretty unfriendly, and a there's still a lot of command-line snobbery that seems dedicated to preserving this unintentional but obsolete obscurantism, like thoroughbred horse breeders who refuse to acknowledge the market's preference for cars and bicycles.
- zanny 13y ago
  I agree with this. A lot of the limitations of 1980s unix no longer exist, yet we still constrain our terminals to obtuse nomenclature and bad syntax like we only have 80 characters before the terminal auto-returns.
- kragniz 13y ago
  I believe we're talking about kernel development here, not GNU utilities. However, what naming scheme would you prefer? The command line is fairly unintuitive as it is. I would argue it is preferable to have short, memorable and fast to type names.
  - nsmartt 13y ago
    To be fair, it's entirely possible to create aliases with more intuitive names and dump a "you can type ____ for short" message on each run.
    - jlgreco 13y ago
      Which leads me to suspect that if there were a demand for "a big file to source in your bashrc to alias 'cp' to 'copy'", it would exist. It is not exactly a difficult thing to do, but nobody actually cares enough to do it (probably because it is not actually a problem).

penguindev 13y ago

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.

samspenc 13y ago

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 13y ago
What course was that you took and from which school? That sounds like a really awesome OS course!
- zanny 13y ago
  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.
pavel_lishin 13y ago
What sort of changes did you and your classmates end up making? Were you contributing to the kernel codebase, or just modifying it for personal/class use? Sounds like a pretty interesting and practical assignment.
- samspenc 13y ago
  This was years ago, so I can't remember any of the assignments, but I remember they were mostly simple changes to the kernel - but we had to actually re-compile the Linux kernel, make sure it booted up and worked the way it was supposed to! :) In some cases it was data structure changes, in some, it was small improvements to some algorithms. Quite challenging in the beginning, but by the end, I was actually having fun playing with the Linux kernel and watching a custom kernel boot up and work perfectly!

joe_the_user 13y ago

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 13y ago
Considering something like 85% of kernel work is already sponsored... Short snippet: https://www.linux.com/learn/tutorials/560928-counting-contributions-who-wrote-linux-32 https://www.linux.com/learn/tutorials/560928-counting-contri... Full document: http://go.linuxfoundation.org/who-writes-linux-2012 http://go.linuxfoundation.org/who-writes-linux-2012
- joe_the_user 13y ago
  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.
chatman 13y ago
This post is not about desktop GNU/Linux applications. There are plenty of upcoming developers in and a lot of buzz around GNOME, for example. This post is only about the Linux kernel of the GNU/Linux operating system.
zanny 13y ago
I'm one of those young developers in the Linux space that doesn't go near the kernel with a 10 foot pole, for four reasons: 1. It is a monolith. The actual kernel parts that matter for an executing preemtive virtual memory virtual fs operating system are probably 1/100th the code base - most of it is device drivers. That core stuff has been chizzled to a fine point, and I'm not a device manufacturer so I'm not working on drivers. If I were to get involved in any part, I'd have to worry about leaking into other parts, and interacting with a massive developer web. 2. It is C. As a C++ guy, whenever I have to write out each type handler of a function I'd rather write as a template I want to beat my face on the keyboard. i just can't write C anymore because every 3 lines there is some productivity boon or maintainability gain I could have from modern C++ I miss too much. In the general case, not many young developers want to write C. They either like their Rubies and Pythons, or want a broader native language to work with than strict imperative. 3. I can better invest time and make a difference in more modern projects. I contribute a lot to KDE and game emulator projects, rather than try to fix the low level stuff that other developers are significantly more well versed in than me. Which also (in the LInux world) is also all written in C. Except GCC, but they have guidelines on what C++ features you are allowed to use which really limits the utility of the language in some places. 4. The learning curve is a mountain. I had a project in my BS to implement a simple system call and compile a custom kernel, but anything beyond that has broad reaching effects and a requirement to read thousands of lines before even starting, at least in the capacity I would feel safe writing code for something executing in the highest proecessor state with complete system access without worrying about mucking it up. I'm wondering if in, say, another 10 years, we see a microkernel with userspace drivers pop up the way LLVM has become popular against GCC not only because of the licensing and Apple backing but also because it is deeply modular and much easier to implement new langauges on compared to GCC. Maybe the magnitude and pressure in Linux might one day become unbearable and force a transition to something in the same capacity.

hackula1 13y ago

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 13y ago
> 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 13y ago
  While I completely agree with your underlying point, your tone is a bit silly in a not good way.
  - bifrost 13y ago
    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.
- Ygg2 13y ago
  Well then why does the foundation attempt to extend to hobbyist programmers? You can't have it both ways - having hobbyist/web programmers and highly educated in the ways hardware works.

null_ptr 13y ago

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 13y ago
No, just work at Red Hat or Google, they pay plenty of people to actively contribute to kernel development.
- pyre 13y ago
  IBM did at one point too. Have they stopped?

atmosx 13y ago

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 13y ago

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 13y ago

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. :-)