Torvalds: "People Who Start Writing Kernel Code Get Hired Really Quickly"
alphadogg writes Now more than ever, the development of the Linux kernel is a matter for the professionals, as unpaid volunteer contributions to the project reached their lowest recorded levels in the latest "Who Writes Linux" report, which was released today. According to the report, which is compiled by the Linux Foundation, just 11.8% of kernel development last year was done by unpaid volunteers – a 19% downturn from the 2012 figure of 14.6%. The foundation says that the downward trend in volunteer contributions has been present for years. According to Linus Torvalds, the shift towards paid developers hasn’t changed much about kernel development on its own. “I think one reason it hasn't changed things all that much is that it's not so much unpaid volunteers are going away as people who start writing kernel code get hired really quickly,” he said.
You can handle a little verbal abuse?! Welcome aboard!
Most linux users don't know this, but the man pages were named after Chuck Norris. Chuck Norris fsck'ing hates noobs!
I would like to contribute to the kernel, but seriously I don't have the time and I don't think I'm alone. And the kernel is also a big project. Almost every time I run into a bug or something that I could fix, some engineer at Intel or something has already fixed it and it's not merged yet. It's not that people that write kernel code gets hired, it's that now you more or less have to be hired in order to write kernel code. Yeah I know you don't have to, but it's not 1998 anymore and anyone can write kernel code just for the fun of it.
Although, in fairness, adding loads of printk(KERN_WARNING "Hire Dave! He's really qualified!\n"); was a pretty great feature.
Many years ago I worked on several parts of the kernel. But I got hired by a start-up and simply had no time, so I had to step away.
But I still fondly remember meeting all of the people involved. When I was doing things, I don't recall Linus being verbally abusive. Maybe it happened and I don't remember.
I can think of at least one friend who made contributions with that intention
This has always been true.
When I was graduating from college I actually had grand designs to rewrite Linux's sound system back at the turn of the century (before ALSA and PulseAudio) and openly told that to recruiters. I ended up deciding that kernel programming was too hard and ended up becoming a PHP developer instead.
In hindsight, I should have plowed ahead since everyone thought the steaming heap PulseAudio was was great.
People who are qualified to modify or create code for the Linux kernel are going to be pretty damn good coders. If they weren't, well they wouldn't be contributing for long. So basically this is saying unpaid, good coders find jobs quickly because companies are completely fucking stupid.
I can think of at least one friend who made contributions with that intention, before abandoning his work.
Your anecdote does not help make your point. Your friend's attempt to leverage this career-improving "exploit" failed, because kernel development isn't something some trivial resume-padding you can pick up in a weekend. It's not Python.
If you have the skills to work on the linux kernel legitimately, you don't really need to pad your CV. You'll very rapidly have more work than you want.
As Linus makes clear, there is no decrease in non-paid contributions. They are a smaller percentage becasue more professionals are now being paid to develop Linux. That is a good sign becasue it means more businesses see Linux development as something worth investing in. And it's probably the same people doing the programming. Previously they would have to do it for free but now they get paid. Nothing wrong with that.
"He took a duck in the face at 250 knots." -- William Gibson, Pattern Recognition
I frequently work with people who are terrified to touch anything related to kernel. Many are "professional" Linux-developers, but to them, all they know is user-space code.
I am the go-to guy with anything kernel related at my work, as I'm not only not afraid of the kernel, but I embrace the opportunity to dig deeper. I've learned that this is a rare and valuable skill in some technology circles. People seem to regard me as some kind of wizard (because I maintain tool chains and do all the integration stuff and similar). I did not exactly actively seek this position. The only real difference is that I've never been afraid to learn. Now I'm quickly becoming the in-house expert and I don't care. I can leverage that to death when looking for other jobs.
Community developers write useful things then get hired by the WMF to work on stuff nobody wants.
So wait, I guess not like MediaWiki.
Your hair look like poop, Bob! - Wanker.
Device driver writing is some "trivial resume-padding you can pick up in a weekend", tbh.
Rewriting a kernel subsystem, on the other hand...
Despite 2015 not being the year of Linux on the Desktop, it IS the year of Linux in just about every embedded device, board and SOC on the market. This means that there are more developers being paid to work on Linux, presumably including the Linux kernel.
The summary is full of percentages. 11.8% seems to be about 19% less than 14.6% but that just serves to obfuscate. I'm not willing to dig into the "fill-in-the-form-to-read" article, but would assume that the total number of paid developers has increased accounting for the change in percentages.
Well, I guess that opens a philosophical discussion of whether writing device drivers counts as "kernel coding" at all.
Yes. Because code gets accepted into the kernel that isn't very good, and was only written to try to bolster ones CV. Brilliant conclusion.
writing device drivers is debatable; the kernel side of it is frequently just cut and paste from elsewhere and most of the "real work" is on the device side. A strong argument can be made that maintaining them in the longer term is true kernel coding as there's a bigger need to track changes to the kernel side of things.
Then again, it might've gotten easier. I haven't maintained drivers since the 1.3/2.0 days.
Log in or piss off.
As a person with software development skills, I could:
1) spend time writing kernel code, and get a sense of fulfillment from it.
2) spend time writing some other code, and get a sense of fulfillment from it, and get paid too!
3) Play WoW.
The incentives speak for themselves.
Linus comment is out of context, I hope.
Getting hired really quickly changes nothing. You are still an unpaid volunteer unless the new job pays you to contribute to the kernel. Lots of people contribute to open source projects on their own time while drawing income from other work. That does not make them paid developers in the context of the open source project.
So what if it gets pulled into the kernel, than its kernel coding; at least in Linux land because driver code can touch memory belonging to other parts of the the kernel. If we are talking about Minix or something it might not be.
And So what if he did it to pad his resume. Drivers are useful to anyone who has the kit they are written for. Even if he abandons it quickly a working or mostly working driver is still useful because someone else can maintain it. Its way easier for me take your driver for 3.0.19 and tweak it build on 3.0.22 or whatever than it is to work out the hardware details.
He wins and the community wins.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Well, I guess that opens a philosophical discussion of whether writing device drivers counts as "kernel coding" at all.
Well, kernel-space drivers have the ability to poop all over the system so I'd say being able to write those without people yelling at you indicates some skill. Doing a little tweak so your obscure USB webcam that is 99% similar to all the other webcams work probably not so much. Though if all you're looking for is a one-liner to get your name on the list that might not matter much, I did run into a crash bug on a -rc1 kernel that was simply a missing description causing a null pointer kernel panic but unfortunately I was a few hours short of being the first one with that exact device ID and a patch. Just for the "kernel hacker" title.
Live today, because you never know what tomorrow brings
I'm a senior in CS, I haven't taken operating systems. I've never seen the code for a kernel and don't know what's involved. However, everything I've seen heard or read about kernel programming sounds painful and difficult.
I think this is the problem. Maybe kernel writers do get snapped up fast... but it feels like there is an extreme lack of approachability and perhaps lack of information on what's involved. Add to that the lack of approachability of open source in general ... and it's no wonder that they have no volunteers. (oh and torvald's temper)
esd wasn't nothing, it just didn't obey the generic network-able "everything is a file" type of *nix attitude. There were lots of sound servers, but they all took a windows-type attitude of wanting to take over the sound card for exclusive use, and also had low quality and incomplete APIs. PulseAudio was included by distros about 3 years too early, for reasons having to do with implementation bugs, and the wide variety of hardware bugs in sound cards. (because sound cards are cheap hardware, they get less engineering and need more software workarounds)
Before it was really ready, turning off PulseAudio was the second thing I did to a new install. (right after turning off NetworkManager) But once the bugs shook out, the reality is that it is much better than what came before, and properly interfaces with the rest of the ecosystem.
The real point of his point was, people with weak programming skills can improve anything, especially any software they interact with that is in a difficult problem space and therefore has low-appearing fruit. That turns out to be "too hard." And instead of learning to be less credulous of wild complaints, he learned that his mistake was not to charge ahead into the problems that were too hard for him, merely because he saw others who had the background to take on the problems have some amount of difficulty, or at least he heard people say bad things about them.
It is all very typical. He abandoned kernel dev while at the height of the Dunning-Kruger curve, before having even started to take something on, and realized it was just too hard for him. Had he actually tried to push forwards and write code,(just a detail, or the real part?) he'd have quickly found the bottom of that curve.
Ideas are worthless, even good ideas. I've got notebooks full of ideas, and nobody cares. If I had notebooks full of implementations, I'd be famous.
Why does the Linux Foundation force its website visitors to submit a form before they can read this report?
First Name
Last Name
Email
Company
Job Title
Really? Why can't we have a regular download link or at the very least a 'skip this' option?
Disappointing. Now I'm sad. :(
Li-nucks?! Are there apps for it?!
I look back on many years of writing assembly code for 680x0 and PPC, Strong knowledge in Hardware and System development of certain architectures as well as C programming. I even have written an hobbyist Kernel and an Action Replay like software (WinIce for Windows guys). Sadly I am not able to find a job offer here in germany. Most of the time I deal with mid management people who know shite about programming at all. They see you as a toy who can be hired cheaply.
Over the years I found a company named CSC (Computer Sciences Corporation) who hired me as an application developer for surface and subsurface realtime systems (Military services). At least that's what's written on the paper. The reality ended up that I did normal consultancy shite like building up PC's, lot of travelling, systems integrations and other things NOT RELATED to my job description. After 6 years I quit the job because it wasn't satisfying. I wanted to leave earlier but unfortunately the current economic situation didn't allow me to quit the job and become unemployed.
After a while they started treating me with all kind of dirty company stuff like warnings and other things only to enforce me to continue the way "they" saw me. This ended up in me resigning from the job.
After that I wasn't able to find another job anymore because over the 6 years I did so many different tasks, that I ended up doing everything half or on a broad ranger rather than staying the expert that I was before I joined the company.
Now 5 years have passed where I resigned from my job and from then on depend on germans wellfare system.
I wasn't hired anymore. No one want's my knowledge and no one wants to hire a "foreigner" (my parents are migrants).
So far mr. Linus Torvalds. I respect you but you are wrong. The indepth skills one have are worth nothing. The only thing matters is a) you are young, b) you are cheap and c) you are no fucking migrant.
Device driver writing is some "trivial resume-padding you can pick up in a weekend", tbh.
Rewriting a kernel subsystem, on the other hand...
Sortof, except that even if the majority fit that description, the majority are also written before you even know they exist. A person in the position of needing to pad their resume doesn't own pre-release promotional copies of all the latest hardware. By the time the device is in the store and they know to check for a driver, the patch is already a month old on a mailing list. Even if you're reading the mailing lists, the process is not normally, "gosh people there is no driver for this device, will somebody please write one, here I'll mail you the hardware." The first you'll hear about the new hardware needing a driver is when the patch gets paraded on the list.
All the missing device drivers are for very expensive hardware that very few gainfully employed developers have access to, and the things that are hard because of missing or intentionally incorrect proprietary information.
It would be a lot more effective a resume pad to just re-implement a few kernel wheels, not even submit them, and present them as an appendix of working code samples. It saves all the wasted years hunting, hunting, hunting for that elusive easy-but-unimplemented driver. Heck, even just reading the friendly manual during those years would be more productive.
New kids aren't interested because they think "code" is Java and Objective C and application/GUI code and think that the rest is all "hardware". Many aspiring coders don't even realize that there is more complex code under the hood which makes everything easy for them. They take this stuff for granted as if it happens by magic and have no concept that someone actually wrote their OS and frameworks in C or C++.
These people are very easy to identify as they'll be the idiots spewing things like "no one programs in C anymore".
See my anon comment above about people fearing kernel code.
You sir, are one of them. It's a psychological barrier, not a technical one. It really, really isn't hard to get a start on kernel development, especially if you're only talking about things like simple mods and drivers. If you're the type who needs an IDE to get anything done, then yes, it probably is hard, but you're also not a skilled programmer.
As far as documentation goes, to me it's duplicate effort and introduces risk of out-of-date docs. The code and headers should be all you need. Docs are for non-technical managers who like feature lists.
The only important docs are how to configure and compile a kernel, and that's documented to death and rarely changes.
People just think it's hard and won't even try.
Maybe it's the "CS" title. I am more familiar with the engineering world.
I ended up deciding that kernel programming was too hard and ended up becoming a PHP developer instead.
Sounds to me like he made the right call.
And where is the Dice link ?
Why do they do this? On the one hand, they may have some profitable use for the Linux kernel, but on the other hand, Linux is GPL'ed, so they are effectively giving away the work to the world at large. That may be fine for Joe Average volunteer kernel developer, but why would a company want to contribute to a public project like so?
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
I do think it's important to get working but I'd say some of these kernel devs just stopped for other reason - like increased taxes and a need to work more for actual money..
Programming PHP is easier than programming a kernel.
Maintaining PHP, not so much.
...some of real world cases are much messier than Linux.... google for spaggeti :)
Plus, OS kernels are not that complicated... that's the whole point, after all.
Too bad typical app developers have very little clue of how kernels work.
Programming PHP is easier than programming a kernel.
Plus, programmers for either language make the same salary.
practically no one hires kernel programmers, linux took care of that.
- former kernel programmer
Old kernel C guy here. I still hack on things.
I work in a senior position for government now. I don't do anything directly related to technology, and you'd be a fool to get involved. I make three times what I did as a developer and can retire when I want now.
Play with code, but don't expect it to make you money. If you're smart enough to hack kernel code, go hack finance and MBA circles instead until you're rich enough it doesn't matter anymore. Then you can do what you want. ..bitter old 40-something who wishes he studied emergency medicine instead of getting a EE ticket.
Can someone please point me to the statistics for total devs in each of the years between 2012-14. More importantly, did the numbers stay the same, increase, or decrease? This would signify the true aspects of the downturn as specified in the article if it were made more transparent.
While I look at other code for the details, such as looking at a function I plan to call, some "big picture" documentation is extremely valuable in order to know where to start. It's best to understand how it's supposed to all fit together and you can't see that by looking at individual lines of code in a codebase of millions of lines.
Also a sample HelloWorld module is very useful. What functions are REQUIRED for a kernel module? Reading over an existing module won't answer that; a sample helloword.so will answer that and many more in a compact form.
I found the Apache Modules book very useful for these reasons. The functions in the Apache API can be understood, but the big picture of the architecture is much clearer after reading the book.
Here's where he posted it... personally I think it's hysterical and am not at all offended. :)
https://groups.google.com/forum/?fromgroups#!msg/fa.linux.kernel/Dd6OHskaUPI/dsGFoZCO_woJ
Nice try Torvalds. If that were the case, you wouldn't have to bring it up the subject as an enticement.
The supposed fact that kernel developers are knee deep in job offers would encourage enough people to undertake the self training.
However that does not appear to be the case....here Torvalds (and the community also does this) lures neophytes into supplying
YEARS of FREE expertise and labor in the (false) hopes of finally being welcomed into some secret inner circle
of six figure open source development jobs. Alas, the few such jobs are already taken, and there really isn't any demand for
commecial linux development that isn't being met already (between the few closed shops and the glut of freely supplied labor that is
given in false hopes of "going pro").
Insidious, isn't it???
WTF?
If writing hello world in C is too hard, PHP is for you.
PHP is for amatuers, by amateurs.
What a waste of an eduction.
Loser