Torvalds Says It's No Picnic To Become Major Linux Coder

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.""

Comments

I gave up a few times

[EmbeddedJanitor]

I considered, and once tried, pushing a file system into Linux. Unfortunately the fs does not have the right coding style and a few other things which make it hard to put into mainstream. Instead it just sits independently as a big patch which is pretty easy to apply by running a simple script.

This suites everyone that uses it pretty fine, except for the purist "it's got to be in the mainline" folks. Realists just pull it from a public cvs and apply it with minimal effort.

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.

Re:I gave up a few times

[Anonymous Coward]

I considered, and once tried, pushing a file system into Linux. Unfortunately the fs does not have the right coding style and a few other things which make it hard to put into mainstream. Instead it just sits independently as a big patch which is pretty easy to apply by running a simple script.

This suites everyone that uses it pretty fine, except for the purist "it's got to be in the mainline" folks. Realists just pull it from a public cvs and apply it with minimal effort.

Honestly, you don't sound like a developer who just developed this great file system that everybody needs. If it doesn't follow the kernel coding style, it was most likely developed for a completely different operating system, and you just tried to get it merged after it was open sourced. And a script is needed to merge it? Nope, not even trying to get it merged. If you're doing development outside the kernel tree, people really need to be able to "git pull" your latest updates. People doing development "in-tree" can get away with regular patches (not scripts!), but for a file system, that's simply not going to work. Look at Reiser FS. The kernel was always behind, and often far behind. Because it came as big chunks.

It's easy to get involved.

[MostAwesomeDude]

Just walk in, sit down, and lurk. Don't write code, just read code. Analyze what patches do. Start small.

You don't have to be friends with developers, but you shouldn't be trying to make enemies. You're dealing with highly rational people here, so keep a level head. Don't bug a developer about what a piece of code does until you study it thoroughly, and don't be surprised if they'd rather tell you about what it's supposed to do instead of what it currently does.

~ C.

Re:It can't be THAT hard

[One Louder]

Too bad "malloc" and "free" aren't C keywords.

Re:huh

[fishbowl]

>Would you let a doctor fresh out of med school slice and dice in heart surgeries?

Yes, if that was their residency specialty. Do you know much about med school matriculation?

Matching culture is a serious challenge

[mkcmkc]

Although coming up to speed technically can involve a lot of work, it is at least a fairly predictable process. The larger and more mysterious challenge is figuring out how to get things done within a project's culture and bureaucracy. This entails figuring out who the powers-that-be are for different aspects of the project, what their preferences are (whether justified or capricious whim), and what kinds of submissions they will accept.

Recall, for example, the Linux CML2 fiasco. Eric Raymond is a bit on the obnoxious and arrogant side, IMO, but even without looking closely at CML2, I'm ready to believe that it was probably a worthy improvement to the Linux kernel. But nonetheless it got nixed, and apparently not for technical reasons. I'm sure he found this quite frustrating.

In my experience with Open Source projects, I notice that I often have luck getting patches that fix clearcut bugs in. Patches that fix broken design points, even exceedingly minor ones, are more problematic, perhaps because they're not seen as worth the bother, or because the PTB are simply used to the way things are, NIH syndrome, etc.

Major changes are even worse, as they present a serious challenge to the self-evaluation of the people that created the system being changed. I'm reminded of a quote: Don't worry about people stealing your ideas. If your ideas are any good, you'll have to shove them down people's throats.

Re:huh

[BPPG]

http://janitor.kernelnewbies.org/

Maybe this will answer some of your questions. But yes, and it's good that the linux kernel doesn't operate like wikipedia, for obvious reasons.

Re:huh

[moderatorrater]

Verifying bugs submitted by customers and QA, going through older bugs to see if they're still present in the latest release of the application, and trying to get up to speed so that I can code here in a few weeks.

Re:huh

[awrowe]

I think what BPPG was getting at is that its probably a good idea that the code in Linus' tree can't just be randomly changed by anyone, like the content on wikipedia can be. Basically he was saying exactly what you said, but with less words, using a language device called a metaphor. Being literal is good, but using metaphors sometimes means you can convey meaning with elegant simplicity. What the hell am I doing, I'm replying to an AC?