Management
Technology
- Applications
- Business Intelligence
- Development
- Hardware
- Mobile & Wireless
- Networking
- Internet
- Operating Systems
- Security Products
- Servers & Datacentre
- Storage
Toolbox
Training
Books
White Papers
Webcast
Resource Centre
July 02, 2007
Are top Linux developers losing the will to code?
Core Linux developers are finding themselves managing and checking, rather than coding, as the number of kernel contributors grows and the contributor network becomes more complex.
By Don Marti
Core Linux developers are finding themselves managing and checking, rather than coding, as the number of kernel contributors grows and the contributor network becomes more complex.
Advert
That is the view of Greg Kroah-Hartman, maintainer of USB and PCI support in Linux and co author of online book Linux Device Drivers.
In the latest kernel release the most active 30 developers authored only 30% of the changes, while two years ago the top 20 developers did 80% of the changes, he said. Kroah-Hartman himself is now doing more code reviewing than coding. "That's all I do, is read patches these days," he said during a discussion at the Linux Symposium in Ottawa last month.
In theory the kernel development process involves changes going from the original author through a file or driver maintainer, to the maintainer of a major subsystem such as PCI or SCSI, to Andrew Morton for testing and finally to Linus Torvalds for a kernel release. But Kroah-Hartman said the process was much more complicated: "I tried graphing that, and that's not what happens. It's a mess. There's routing all over the place."
A graph of all the developers involved in the upcoming 2.6.22 release, as well as of the relationships of who reviewed whose patches, extends to a 40 foot print out with names in small type. The graph is on display at the Ottawa event.
The "mess" results in innovative features becoming integrated into Linux distributions much more quickly, according to Jonathan Corbet, author of the camera driver for One Laptop Per Child and another writer on Linux Device Drivers.
Previously, when developers maintained both "stable" and "development" kernels, it could have been two to three years before a feature made it from development to mainstream users. Today, by contrast, the newly released Fedora 7 distribution has the power saving tickless kernel functionality, which came out in the 2.6.21 kernel in April.
Enterprise Linux distributions that pick a single kernel.org release and maintain it for five to seven years are another reason for the complexities. Instead of waiting for a stable upstream release and then modifying it to include new functionality from development kernels, an enterprise distribution can support any of the 2.6 releases, which come out every two and a half months. Corbet said: "The patch loads carried by the distributors have shrunk quite a bit."
Jump to page : [ 1 ] [ 2 ] [ 3 ]
Follow highlights from ComputerworldUK on Twitter
Sign up for our Daily Newsletter
The UK IT News widget Get it for your site!
« prev article | more development news-analysis articles | next article »
Advert
Email this article to a friend or colleague:
PLEASE NOTE: Your name is used only to let the recipient know who sent the story, and in case of transmission error. Both your name and the recipient's name and address will not be used for any other purpose.
- This article is now being printed.
What are your views on this subject? Use the form below to post a comment on this article up to 1000 characters.
Click below to add 'Are top Linux developers losing the will to code? - Software Development - ComputerworldUK' to your blog.
If you do not have a ComputerworldUK Account and would like to use this feature, please Register.
If you are a registered, logged-in user, this will post the title and first paragraph of this story to your blog to share with your readers.
Advert
Newsletters
Sign up to our Weekly Round-Up for the past week’s not-to-be-missed news analysis and insight delivered straight to your inbox.
WHITE PAPERS
-
Legal risks: Employee use of the internet and email
Exploring the challenges facing IT Mangers today and vital steps to ensure safe internet an email use by employees. -
Phishing for victims
This White Paper examines the phenomenon of phishing. It explains the potentially catastrophic threat it presents to all kinds of organisation. Exploding some widespread myths, it lights up the murky waters where phishing first emerged and where it continues to evolve. But it also highlights what your business can do to blunt the threat.
Comments received
gg said on Monday, 02 July 2007
No where in the article is it mentioned that the top developers are losing the will to code. It sounds like they just don't have time. I'd appreciate more accurate headlines.
The "will" to code?!! said on Monday, 02 July 2007
You have GOT to be kidding me, passing off a headline like that as even vaguely relevant to the story. That kind of crap headlining is obviously designed to freak people out enough to drive traffic to the story AND get it listed on slashdot for yet more traffic, instead of actually simply attempting to report about an event. That kind of effort at emotional manipulation is insulting to readers' intelligence, and does not flatter the author.
windbourne said on Monday, 02 July 2007
Hmmm. so, is it more productive for them to help and train a number of other coders, or is it better for them to keep coding?
Tony Jones said on Monday, 02 July 2007
I think it is probably better that these guys check code rather than write it. Nothing wrong with asking a question in the headline either. This is a real issue for us all. Once you get good at the job it is hard not to end up managing or supervising - and sometimes it is your responsibility to do just that. There is nothing wrong with teaching others...
Dave said on Monday, 02 July 2007
I really don't have a comment on either the speed at which Linux improves or it's obvious quality, I think it does very well in both these catagories.
My issue is something else that is discussed by this article. Mainly, with so many different builds and maintainers it nigh impossible to know if an issue that your having has been "fixed". It's even harder for a non programmer such as myself to figure out "who" may be working on "fixes" to get a chance find information on what progress is being made, since there is no chance I can fix it myself.
Simon said on Monday, 02 July 2007
Interesting. Someone needs to write an article that says... "Journalists losing the will to write."
Jon Philpott said on Tuesday, 03 July 2007
Did anyone forget that the title of the article is a question not a statement?
strokfen said on Tuesday, 03 July 2007
This is good news, not bad news. It means now the Linux kernel [development process] is mature enough.
dave_ said on Tuesday, 03 July 2007
Are readers losing the will to comment?
strokfen said on Tuesday, 03 July 2007
@Jon Philpott: Actually I love the title, but, technically speaking, using a question is always the most convenient (i.e. manipulative) way to state something so that, whenever needed, you might always deny ever having stated it. It's the best way to doublespeak.
dkim said on Tuesday, 03 July 2007
Now show us some story on developers losing will to code. :-\
gyaresu said on Tuesday, 03 July 2007
"You have GOT to be kidding me, passing off a headline like that as even vaguely relevant to the story. That kind of crap headlining is obviously designed to freak people out enough to drive traffic to the story AND get it listed on slashdot for yet more traffic, instead of actually simply attempting to report about an event. That kind of effort at emotional manipulation is insulting to readers' intelligence, and does not flatter the author."
- Agreed
juga said on Wednesday, 04 July 2007
For your next headline, can I suggest: "Are top Linux developers defecting to Windows?" That should get you some traffic.
rhundt said on Saturday, 07 July 2007
I agree that the headline suggests, even though stated as a question, that there is a dwindling participation in Linux development. I was heartened to read that the reverse was, in fact, the case.
However, someone who'd only scanned the headline and not read the content might be forgiven for thinking otherwise - it was only out of mild horror that I actually read it. Not a pleasant sensation.
I would have read the article anyway if the headline reflected the content.