Torvalds Says It's No Picnic To Become Major Linux Coder 222
Jack Spine writes "Linus Torvalds has given an interview to ZDNet.co.uk about the trials and tribulations of becoming a Linux kernel developer. 'Torvalds said that, while it is relatively easy for coders and organisations to contribute small patches, the contribution of large patches, developed in isolation, could lead to both new and established contributors becoming frustrated.
"It's definitely not easy to become a 'big contributor'," wrote Torvalds. "For one thing, the kernel is quite complex and big, and it inevitably simply takes time to learn all the rules — not just for the code, but for how the whole development environment works. Similarly, for a new developer, it will take time before people start recognising the name and start trusting the developer to do the right things.""
huh (Score:3, Insightful)
In other words, it's hard because I make it hard.
This goes for every OS/FOSS project out there. (Score:5, Insightful)
And considering the widespread usage plus amount of people that rely on the Linux kernel to be stable and not explode in a horrible firestorm I can certainly understand that Linux kernel development requires a Stalinist approach.
Allegiances (Score:5, Insightful)
What happens if:
1. Batman is more or less responsible for a big chunk of the kernel, e.g. the scheduler.
2. Torvalds knows Batman, and knows that Batman is employed by Redhat to work on the scheduler.
3. The Joker writes a new improved scheduler which has the potential to replace the old one.
Now, how does Torvalds react? It would be hard to tell Batman that he's no longer in charge of the scheduler. Batman's job might be on the line - why would Redhat keep paying Batman if he suddenly had a lot less work to do? Maybe Torvalds met Batman a few times and had a beer with him, making it even harder to replace his work because it becomes personal. Torvalds could harm Batman's career.
Surely this makes it hard to become a big new contributor? All the existing contributors already know eachother and they won't want to dump eachother's work.
Am I right or am I right?
Still easier than coding the Windows Kernel (Score:5, Insightful)
Qualify "luck". It seems to me that any large distributed development effort is going to require some sort of process - the anarchic development model isn't terribly successful.
With that in mind, developing the Windows kernel requires you to be employed by Microsoft etc, whereas developing for the Linux kernel just requires you to follow some established open processes.
What's the problem with that?
Re:I gave up a few times (Score:4, Insightful)
Although I might consider mainlining it again, for the moment the effort just is not worth it. The current model is workable for those that use it.
It sounds like your FS serves mostly a niche that isn't served by the mainline FSs. Call me a "purist", but I just don't have the time or inclination to re-compile my kernel. I did it many years ago to save a few kilobytes of memory when it was at a premium, but these days, why? If you don't care about keeping up on kernel patches and have some specific needs that aren't supplied by the mainstream kernel, then re-compiling is fine. But if not, then the mainstream kernels (vendor provided) wind up being a lot easier to work with.
Re:Learning the rules (Score:5, Insightful)
Yes, but trick is that since you can't constantly be bugging Linus for all the answers, you have to know what his opinion is without asking him. That's the tough part.
Re:huh (Score:5, Insightful)
Nope.
It is hard because.
1. Programming is hard.
2. System's programming is even harder.
3. Kernel code is mission critical code which is really hard.
4. When you are the new person it takes time before people trust that you know what you are doing.
In other words it is just like everything else. The difference is that if you want to make changes to your Kernel you can. If you want to put up a site with your patches you can.
If you want your code adopted in the "official" kernel you have to play by the rules and write good code.
So it works exactly as it should and really can not work any other way.
Re:Allegiances (Score:5, Insightful)
Am I right or am I right?
You're a tautology.
But let's take your unproven hypothetical as given for a second. If these sorts of decisions are being made, which provide technically inferior solutions for the Linux kernel.. then over time it will become obsolete.
But way before then we'll all be using the nuLinux kernel which has all of "The Joker"s fancy code.
In other words, F/OSS can take care of itself; we're just the dumb monkeys hitting random keys.
Re:Andy's revenge (Score:1, Insightful)
Short answer: no
Re:huh (Score:5, Insightful)
Wisdumb (Score:5, Insightful)
It's no picnic to become a major anything. Major people are people who have differentiated themselves from minor people. The means by which they've done that is to do something that's more difficult, which the other people cannot do. This is a tautology masquerading as wisdom.
Re:huh (Score:5, Insightful)
Nothing in open source has ever guaranteed that you get to contribute directly to a specific project. When a specific group of developers is maintaining a release (Linus et al, in this case) it's absolutely up to them what code gets in and what doesn't, and who they will accept contributions from. What open source guarantees is that when they make that release, you're free to take the source code they've created and modify it in any way you choose. You're free to fork the project and maintain releases just as strictly as they did, or open it up to all newcomers.
I think you'll find, though, that opening it up to any unknown person right off the bat will trash your project pretty quickly. The problem is, there are hugely varying ideas of what constitutes "correct" code and architecture, and it's just a fact that it takes time to prove that you understand what that means in terms of a large project such as this.
Re:huh (Score:5, Insightful)
I disagree. I think you have the wrong idea about what "open source" means.
Open source pertains to the code base, not to any particular repository of the code. You are quite free to read, modify, and redistribute (with modifications) the code. You cannot compell Linus to incorporate your changes into his version, any more than he can compell you to revert a change from your version.
That Linus has a widely-respected "official" version is a moot point. It really just means he has an audience for his product (i.e. the version of the code he/his team host), and you may not have one for yours (a modified version you create but which isn't accepted as part of his product).
Much like free (as in speech) speech, open source doesn't guarantee you that anyone will listen (where "listen" in this context means "run your version of the code").
As for MS -- well, getting a job at MS isn't the same as getting a job that lets you make major modifications to the Windows kernel. I'd say the sitaution with regard to the high-profile products (i.e. Windows on oen hand, the "official" Linux kernel on the other) is about the same. The difference is that you can't modify Windows without being part of the official team. Not to distribute (even if you can find an audience for your work). Not even for your own personal use. That's the difference between open and closed source.
Re:huh (Score:5, Insightful)
Re:huh (Score:5, Insightful)
One additional point: don't try to take over a whole subsystem in one rewrite. Contribute small patches that are easily reviewed to get your feet wet and get noticed. Then, as you're better known and respected within the community, start scaling up your contributions.
It works the same way in any open source community. The new guy who rewrites half the code all at once isn't going to get a review of his code. Show that you can do the small changes right first.
Actually, it works this way in almost any cooperative group. You don't show up to your first meeting at Kiwanis, the Jaycees, or the Lions and start making resolutions. You don't sit in on drums once for a band and start telling them how to write songs. The US Senate even has a rotating term cycle so that there are always Senators with more experience to get the junior Senators acquainted with how things work.
People who think they should suddenly be in charge of a large portion of an established organization they've just joined are showing signs of detachment from society or megalomania. If you've never contributed anything worthwhile, you're nobody special compared to the people who have been doing the work. Don't expect to be a big part of a group without being a small part first. Some people move up the ranks faster than others through skill and hard work, but everyone pays some dues.
Re:Still easier than coding the Windows Kernel (Score:3, Insightful)
By the time you are working on the Linux kernel as a contributor, you'd have accumulated enough knowledge/experience to get employed at Microsoft. I think at that point, it's more a matter of ideology.
At Microsoft, working on the kernel pays as a fulltime job, while you still have to find a way to get money if you're just working on the Linux kernel as a hobby. And if you can get employed by some corp to get paid working on the Linux kernel, I'd think their employment standards would be comparable to MS's.
Re:huh (Score:5, Insightful)
And the honest truth is that.
Unless you are some kind of super prodigy or have years of experience writing systems code odds are your complete subsystem rewrite is total junk.
It takes time to be good at anything.
Batman sometimes has an ego (Score:3, Insightful)
Actually, the parent was slightly overgenerous, because he mentioned only the case of Batman being a wholly nice guy (implied).
The bigger problem occurs when Batman is a regular human with a large ego and a dislike for NIH code (or worse, Not Invented By Me code), rather than an objective engineer fully willing to accept that another developer has come up with something better.
Although we heard about one high-profile case recently where this happened, with an outcome that was more political than based on engineering merits, in a project that receives patches from thousands of developers on every release this must be happening *A LOT*. Developers with egos are fairly common after all.
It's a sad indictment of people, and while "F/OSS can take care of itself" is a common response, it doesn't really address the fact that some good ideas are being lost or marginalized by lead developers' occasional small-mindedness, and that as a result, overall kernel progress is less good than it might be. "Stability" is a very worthwhile goal and can be a good reason for rejecting a contribution, but sometimes the same word is used to hide a very ugly personal failing of the assessor.
Re:huh (Score:5, Insightful)
I am no kernel developer, but I think Linus is getting at why "it works exactly as it should and really can not work any other way" has some demerits, and that it not being able to work any other way is why we are in a fix.
In other words, it works as it should, but it is very slow, so how can we improve the process and make better patches faster?
If the answer is that there is no better way, then that is a sad awakening for a lot of us, because it means precisely that Linux isn't going anywhere sooner than it has since the current state has been established.
But there has to be a better way, and I think Linus is trying to find it, as are many others.
Re:Still easier than coding the Windows Kernel (Score:5, Insightful)
http://www.desktoplinux.com/news/NS8745257437.html [desktoplinux.com]
Anyway he didn't start small at all. Go Ego
Re:huh (Score:1, Insightful)
Ladies and gentlemen, this is why I read Digg for the articles and Slashdot for the comments.
Sadly, logging in AC due to the irrepressible sappiness of my post.
Re:Andy's revenge (Score:4, Insightful)
If that's the problem, wouldn't it be easier to work on it if it was a microkernel?
Yes. Fortunately linux is half way to being a microkernel now. I can personally attest that writing a user-space file system (eg in FUSE) is vastly easier and quicker than hacking (let alone writing) a filesystem in the kernel.
The evidence is on my side. Look at how many filesystems Linux supports, and count how many are in FUSE, versus how many are in the kernel.
Re:huh (Score:3, Insightful)
IAAMD. When you start doing surgery there is a more senior surgeon standing right there, watching your every move, and ready to take over if necessary.
Re:huh (Score:5, Insightful)
I think the problem with Linux / Linus isn't so much the patch resistance, but the attitude. Countless times there have been well-written and widely-used patches that were stubbornly rejected by Linus, with little or not explanation as to why. This paints him as a fussy dictator, which may or may not be true - I don't know him personally so I can't say.
It's perfectly valid to reject bad code, and he should continue to do so, to ensure the quality and reliability of the kernel. What would be important, at least in my opinion, is to give some sort of constructive criticism to help that developer improve their code, or maybe point to a similar patch where the developers could join heads.
It's the whole "this sucks, you suck, fuck off" attitude that has built up Linus' reputation as an ego-tripper - so much that his programming ability has taken a back seat to the drama.
Re:I gave up a few... - Build Linux because we can (Score:3, Insightful)
disabling build of unneeded functionality improves stability and security.
I'd have to disagree here. It only improves stability and security if you're willing to keep up with all the endless patches and devote a lot of time towards understanding each patch (and possibly back porting it yourself). Do YOU want read every single kernel patch and decide if it's relevant to you? I don't. That job is best left to people devoted to kernel maintenance, like a team of people at (insert distribution).
Re:huh (Score:2, Insightful)
And if you are a super prodigy, save yourself the heartache and just write your own OS. It's better than slowing yourself down to the same speed as the rest of the retards writing patches.
Re:huh (Score:3, Insightful)
That's an interesting observation. Unfortunately, there are two major parties which reinforce their duopoly and have for decades. Both are largely corrupt, so the system would seem to have failed.
The discouraging of banning together for sinister purposes is indeed listed as one of many reasons for rotating Senate classes on the Senate's own history page [senate.gov]. Other included less popularist views, a longer view of issues, more stability, and more continuity. By having a group that served longer than the terms of presidents or members of the House, a turnover in the governing bodies would not leave the federal government completely fresh and inexperienced.
Re:Batman sometimes has an ego (Score:3, Insightful)
Although we heard about one high-profile case recently where this happened, with an outcome that was more political than based on engineering merits
One of the worst things that could happen to a system is to be neglected. If someone's been around and doing their job ok for a long time, then you push him out for a someone new you want to be certain they'll take over the daily maintenance. As long as you're the "new subsystem" there's news, discussions, benchmarks, attention and glory. What happens when your system is established and accepted and there's just hard work and gritty detail? If you've been working for a while, you're bound to run into the archetype that throws everything up in the air, sets a few things right and manages to leave with a good reputation before the paint falls off and odd corners become apparent. Particularly with OSS it's "at-will" work, maybe not with whoever you're employed with but to the community at large it is. Sometimes you take a short-term hit to ensure that you have long-term commitment. Of course it could just be a human flaw too, but there's more points to be scored in a job interview than engingeering skill.
Linus vs Andy, take 4 (Score:2, Insightful)
Perhaps Linus will change his mind about monolithic vs micro kernels. He's basically making Tannenbaum's case for him.
He's right. But still... duh? (Score:3, Insightful)
'scuse me, but does this have to be said? You don't come into a new project and take the lead of a critical component. Duh. Really? Usually I hand the guy of who I know nothing but some nickname the responsibility of making-or-breaking my project...
Is that some sort of consultant thing? Everyone knows that it's right, but it has no merit until His Holyness blessed it?
Re:huh (Score:3, Insightful)
And if you are a super prodigy, save yourself the heartache and just write your own OS. It's better than slowing yourself down to the same speed as the rest of the retards writing patches.
The thing is that the Linux kernel (and in fact most other major FOSS projects) is packed with super prodigies. Each and every one of them has had to prove their chops before being handed the keys to the kingdom.
There's an optimum level of ego in programmers. For example, if I didn't think I was one of the best, I wouldn't be able to do my job as brilliantly as I do. Still, once you pass that level you turn into someone like Hans Reiser. His personal problems aside, he was clearly an excellent programmer who failed to recognize that his peers were equally gifted. This caused him to time and again branch off with his own world-changing codebases. Unfortunately, they were so huge in scope that they were routinely rejected - and justly so. He never seemed to grasp the concept of making small, useful, standalone changes that stood a chance of being accepted by the community whose approval he wanted.
Re:huh (Score:3, Insightful)
INo, it's not political at all. It's pragmatic.
Let's use your analogy. If you develop your mass-marketable flying car prototype, you shop the prototype around to people in the car or aviation industries who might produce it (like Ferrari). You don't accept big changes to its design from high school kids you didn't ask for advice. The reason you trusted Ferrari is that they have some provable experience. The reason they trust you is that you have a working prototype.
The reason you don't trust Anonymous Cowherd to send you a new blueprint for your entire fuel distribution system is that you have no idea who the fuck he is, what he knows about building flying cars, or what his real interest in your flying car is. If he sends you a small tweak that works out, then you might trust a bigger design change later and may even solicit his input.