Security Bullet In
Communiques from the security front, sir
Friday 15 August 2008, 5:23 PM
How to survive Linux coding
The Linux Foundation published a guide for new Linux coders on how to navigate through the processes involved, which I wrote an article about.
The man who wrote the guide is Linux developer and lwn.net editor Jonathan Corbet. While I was writing the article, I sent him some questions, which he replied to. His answers where really interesting, so I thought I'd reproduce the email here, along with the questions I sent.
Q.Is it difficult to get code into the Linux kernel? If not, why is it necessary to publish a guide?
A. It can be difficult, of course, in that kernel programming can be challenging and the standards for code quality in the kernel are high.
The reason for the guide, though, is a bit different. Like any large, organized activity, the kernel community has developed its own set of processes and procedures. These processes differ significantly from what normally happens in corporate software development environments.
The result is that developers coming from other environments can encounter a sort of impedance mismatch when they try to contribute code to the kernel.
Another way to put it might be this way: getting around in London is not particularly hard. But it can still be a challenge to travelers who do not know their way around; many Americans who travel there come back with stories of near-death experiences resulting from looking the wrong way before crossing a street. Near-death experiences are rare in the kernel community, fortunately, but life is still a lot easier if you know how things are done there.
Q. Are some developers being alienated by the development process? If so, roughly how many become frustrated and cease to participate?
A. It certainly happens that some developers decide that they do not want to work in that environment anymore. A classic, high-profile example is described here:
http://lwn.net/Articles/242765/
Some developers get frustrated because they cannot get their code accepted, for various reasons. Others dislike the environment on the kernel mailing lists; it has gotten much better over the years, but the discussion can still get a bit harsh and abrasive at times. Kernel development is not for everybody.
As for how many, I really wouldn't know. A lot of developers come and go, but most of them, presumably, are just moving on to their next task.
Q. Is the number of Linux developers becoming too unwieldy to be effective?
A. The kernel certainly has a large development community. Back in the early days of the 2.4 and 2.5 development cycles, it was most certainly becoming unwieldy, to the point that it threatened to collapse under its own weight. It works much more smoothly now, though, thanks to improved processes and much better tools. So I do not think that the development community is too large at this time; it works quite well.
The man who wrote the guide is Linux developer and lwn.net editor Jonathan Corbet. While I was writing the article, I sent him some questions, which he replied to. His answers where really interesting, so I thought I'd reproduce the email here, along with the questions I sent.
Q.Is it difficult to get code into the Linux kernel? If not, why is it necessary to publish a guide?
A. It can be difficult, of course, in that kernel programming can be challenging and the standards for code quality in the kernel are high.
The reason for the guide, though, is a bit different. Like any large, organized activity, the kernel community has developed its own set of processes and procedures. These processes differ significantly from what normally happens in corporate software development environments.
The result is that developers coming from other environments can encounter a sort of impedance mismatch when they try to contribute code to the kernel.
Another way to put it might be this way: getting around in London is not particularly hard. But it can still be a challenge to travelers who do not know their way around; many Americans who travel there come back with stories of near-death experiences resulting from looking the wrong way before crossing a street. Near-death experiences are rare in the kernel community, fortunately, but life is still a lot easier if you know how things are done there.
Q. Are some developers being alienated by the development process? If so, roughly how many become frustrated and cease to participate?
A. It certainly happens that some developers decide that they do not want to work in that environment anymore. A classic, high-profile example is described here:
http://lwn.net/Articles/242765/
Some developers get frustrated because they cannot get their code accepted, for various reasons. Others dislike the environment on the kernel mailing lists; it has gotten much better over the years, but the discussion can still get a bit harsh and abrasive at times. Kernel development is not for everybody.
As for how many, I really wouldn't know. A lot of developers come and go, but most of them, presumably, are just moving on to their next task.
Q. Is the number of Linux developers becoming too unwieldy to be effective?
A. The kernel certainly has a large development community. Back in the early days of the 2.4 and 2.5 development cycles, it was most certainly becoming unwieldy, to the point that it threatened to collapse under its own weight. It works much more smoothly now, though, thanks to improved processes and much better tools. So I do not think that the development community is too large at this time; it works quite well.
PreviousComments on this post
Sounds like they've either run-off the newer programmers or pissed them off enough to make them leave.
If its like other volunteer projects I've been involved with, the newbies have a long road to catch up and the group dynamic can be "why should we listen to you? You haven't done anything yet. Or You weren't here when we really needed the help". etc.
Co-operative projects have serious inertia and the "impedance" is the older guys elbowing the newer guys out since they already know who to pay attention to and who to ignore.
