Graying Linux developers look for new blood
zdnet.com
zdnet.com
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).
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...
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.
You can't have it both ways - having hobbyist/web programmers and highly educated in the ways hardware works.
I mean also to be honest, I also just don't want to work in C.
Some of it is some fairly esoteric stuff that's not all that interesting unless it happens to be the kind of thing you're interested in. A lot of it is just more hardware support and drivers, which is of course only interesting if you have that particular hardware.
But some of it is really great new stuff; cgroups for dividing processes up into groups and being able to control them together, monitoring and limiting resources on a whole group basis. Namespaces (user, PID, network, etc), which together with some userspace tools give you containers for lightweight virtualization (this is what trendy things like Docker use to provide you with instant and easy containers for deploying apps). There are a couple of distributed filesystems (Ceph and Lustre) which have landed in the kernel recently, and there's btrfs which is developing rapidly as Linux's next-gen filesystem, supporting snapshots, checksums, integrated volume management and RAID, and so on. There's reshaping support in the software RAID system, allowing you to change RAID layouts on the fly (going from a 2-disk RAID 1 to a 3 disk RAID-5 to a 6 disk RAID-6, say). There are new SSD caching options, allowing you to use both an SSD and large but slow spinning disk, caching random reads and writes on the SSD, getting the best of both worlds. There are new sandboxing tools that give you the ability to run BPF filters on attempted system calls, giving you fine-grained sandboxing support (used by Chrome to better sandbox the renderer).
There's lots going on in the kernel space if you pay attention. You do have to be interested in infrastructure; if you're just interested in applications, you mostly wait until whoever provides your platform (Amazon or Heroku, or Google in the case of Android, or Canonical, or Red Hat) packages these up into a nice, easy to use platform, and you may not ever realize what kernel changes went on underneath to allow these new services. But there sure is a lot going on, and I at least think it's pretty interesting.
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.
Short snippet: https://www.linux.com/learn/tutorials/560928-counting-contri...
Full document: http://go.linuxfoundation.org/who-writes-linux-2012
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.
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.
Network engineering is always nice too, but it depends so much in the user-land packager choices... or in "alpha" patches...
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.
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.
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.
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.
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. ;)
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
Not to mention that a language that relies on its own automatic memory management (garbage collection) might not work so well for kernel programming.
These names are short, but not memorable or easily discoverable.
Great examples of Unix command line idioms that are needlessly baroque: find, ifconfig, route, netstat, lsof.
To use the unix command line you have to get your head around a bunch of key concepts, say, globbing, i/o redirection, pipes, etc. After that, whether it's 'grep' or 'brian' isn't going to get in your way much.
This sort of jargon is pretty typical, though, and I think it's a fairly small barrier. Want to learn some LISPy language? Here come the entirely meaningless car, cdr, cons, s-expression. Functional processing of sequences? Well you can map, you can reduce, you can zip, you can fold. Building your first RoR app? Don't forget to railtie your merb to the phusion gem of the sinatra rack, but not before you've raked your capistrano with a cucumber. You can probably safely rename every JS framework to an MMM (Marklar, Marklar, Marklar) framework given the liberties they take with the meaning of the things M, V and C stand for.
You can give, say, 'cat' or 'tee' magically and perfectly clear names but than in itself won't make anyone understand things like 'unix utilities have one input and two output streams' any better.
I agree with man. It makes sense technically because of "manual"...except that "man" is its own word. Every time I type man, I feel like I'm typing the gender, and it's weird.
cp bothers me because they shortened a four-letter word, the same with ls and list. Despite the original terminal constraints, they couldn't spare two characters?
Really, I think that with an OS designed in the late 1960s, brutally reducing commonly-used commands to the shortest recognizable form was a very good idea.
Storage capacity (both RAM and persistent), processor speeds, and bandwidth for internal and network transfers were all many orders of magnitude less than today's systems. Extra bytes had a real cost.
http://alt.folklore.computers.narkive.com/7q9reknM/1950s-at-...
Author of that post is Tom Van Vleck, who ought to know.
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.
Sounds like a pretty interesting and practical assignment.
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!
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.
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.
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.
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. :-)