Slashdot Mirror
Alan Cox Leaves Red Hat
ruphus13 writes "Alan Cox — one of the lead Linux kernel developers at Red Hat — is leaving the company after 10 years and is heading to Intel, where he can focus on more low-level development tasks. Some are speculating whether this is indicative of a shift to a more 'application-centric' vision at Red Hat. From the article: 'Red Hat is integrating more application related, user- and enterprise-centric tools into its well-established "low-level," "core" development and support tools. It'd be more worrisome if Red Hat neglected to strike out in this direction. Cox was with Red Hat for ten years, and regardless of any suspected change of course within the company, that's a fair amount of time.'"
I wish Alan the best in his new position. Redhat have lost a great developer, and Intel have gained a fantastic resource. It's also great to see that the leaving was very amicable as well. This should be a win-win for Linux as a whole.
- This sig deliberately left blank. Nothing to see, move along.
Where does there always have to be speculation, from completely uninformed people? From my little knowledge of Alan Cox, from mailing lists, he always seems like the kind of guy who likes the lower-level details, and I imagine that few companies will be more interested in tweaking and improving the low levels than Intel. If they saw his obvious talent, and offered him a better job at better pay, then why not move? Alan Cox leaving Redhat doesn't have to say anything bad about them, maybe it says something good about Intel, and the things they are getting more involved in?
Combination - fun iPhone puzzling
Who's he?
If he gets a higher salary, why not? People have been motivated for less.
If the Intel position allows Cox to do more of the type of development that interests him, or simply offers a different view from the cafeteria windows...
As an Intel employee, I have to say that if you're choosing to work at Intel for the view or the cafeteria, you have made an incredibly poor life choice.
When you look at it, Red Hat is the wrong place to develop drivers. They should be developed by the vendors of the drivers, not the O/S packager.
It has been necessary so far to develop drivers at Red Hat simply to bootstrap the O/S. But now, Linux is becoming more popular every year, most enterprises have plans to deploy Linux in annually increasing scopes, and the "upward spiral" that Bill Gates (ghost-)wrote about 10 years ago in "The Road Ahead" is happening for the GNU/Linux system.
Red Hat doesn't develop devices. Device vendors develop devices, and it's their expertise in how their own devices function that makes them best qualified to write device drivers for the whatever O/S.
This move is really more a reflection of the continuing maturity of the Linux Operating System!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
What I have observed about Alan Cox in the lkml:
1. Does not buy into hero worship of kernel developers no matter how senior.
2. Does not get nasty when outsiders address him in the mailing list.
3. Is a champion of 'perfect is the enemy of the good' principle.
4. Does not froth at the mouth when someone mentions business reasons for needing a particular addition or change.
There are many on that list with big names that stumble on one or more of the above.
My guess is, a bit north of $100K. The top of the engineering ladder is not all that high, and gurus don't make all that much more than bumblers with equal years of experience. (I'm not talking about RedHat in particular, just my observations of engineering in general.)
I talked to him too and he said he really likes Oreos.
I doubt Intel would be too hurt by his departure either. You greatly over-estimate how important he probably is to Intel. He'll likely do what they ask; he is being paid by them, you know? Unless you think he's some kind of unprofesional crybaby..
When you look at it, Red Hat is the wrong place to develop drivers. They should be developed by the vendors of the drivers, not the O/S packager. ... This move is really more a reflection of the continuing maturity of the Linux Operating System!
God help us if linux gets as, ahem, MATURE as Windows. Microsoft's crappy OS code is only exceeded by the unbelievably crappy driver code turned out by OEMs.
Tracking down (bug-ridden) drivers for everything is the single factor that makes Windows' out of box experience a living Hell (And accepting them only on floppies is the single factor that will eventually kill off XP).
The contrast with linux is eye opening to former benighted Windows users. Not only are all your drivers right there, but all the apps you need are a (free) click away.
Anyway, it's not OS packegers who develop linux drivers; its kernel developers - who are exactly the people with the skills to do the best job.
One of the nice benefits of having driver source available is that the kernel developers can fix them if they understand the device itself. The original designer of the device is always in the best position to write at least the initial driver code.
One of the big rules in kernel development is that "if you break it, you have to fix it."
Having a good-quality original driver from the manufacturer means that the driver will be ported to new kernel versions, and any incompatibilities introduced are fixed by the person on the kernel team who made them break.
In engineering, it's pretty easy to get $80-90k with relatively little experience, or with a not-so-great track record of performance, just by moving around a little. If you're a star performer, in fact, you'd be lucky to get raises sufficient to make much more than new hires who left their previous job because they didn't get any raises (i.e. not great performers), and the new company wants to pay them "market rate". Typically, you'll only match the new hires with your raises. So what, exactly, is the incentive to be a star performer? There is none. You can be a total slacker instead, just change jobs every few years, and do just as well as the guys putting in 90 hours/week and doing the work of several lesser engineers.
This is absolutely true... where I work, the pay ranges that I know of for all north american sites, as of last year, were:
MTS: 103k-168k
SMTS: 115k-187k
I'd say roughly MTS means 7+ years of experience, and SMTS means 9+ years, give or take.
Of the people that were brought in at their current level, most (say around 80%) are around the median of those ranges, tending to be a bit higher. Of the people that were promoted to those levels, most are in the bottom 25% of the salary range.
Now, there is certainly significant correlation between compensation and performance, but only when looking within each of the {hired, promoted} groups. But when looking at the whole group (everyone reporting under our director at least), there are several cases of people ranked in the bottom 25% of performers having salaries 30-40% higher than the top ranked engineers. Just from the salary data, it's very easy to tell who's been around for a while.
And you're right, there's no incentive to be a top performer really, other than having a better shot at escaping the layoff axe when it comes around...
"onward!" cried the copper man, little knowing brass corrupts...