|
|
Subscribe / Log in / New account

Statistics for the 3.3 development cycle

By Jonathan Corbet
March 6, 2012
As of this writing, the 3.3 development cycle is at 3.3-rc6 and things are starting to look pretty stable. So it must be about time for our traditional summary of interesting statistics for the 3.3 kernel. It has been an active cycle, with some 10,350 changesets merged from just over 1,200 developers. Some 563,000 lines of code were added to the kernel, but 395,000 lines were removed, for a net growth of about 168,000 lines.

The most active developers this time around were:

Most active 3.3 developers
By changesets
Mark Brown2812.7%
Mauro Carvalho Chehab2712.6%
Axel Lin2402.3%
Al Viro2002.0%
Tejun Heo1231.2%
Tomi Valkeinen1011.0%
Russell King1001.0%
Matthew Wilcox991.0%
Ben Skeggs940.9%
Johannes Berg930.9%
Stanislaw Gruszka930.9%
Kuninori Morimoto920.9%
Eliad Peller900.9%
Takashi Iwai880.9%
Eric Dumazet870.8%
Dan Carpenter860.8%
Franky Lin770.8%
Kalle Valo740.7%
Lars-Peter Clausen730.7%
Artem Bityutskiy680.7%
By changed lines
Greg Kroah-Hartman8866411.7%
Stanislaw Gruszka380125.0%
Mathieu Desnoyers259683.4%
Mauro Carvalho Chehab210632.8%
Alan Cox209482.8%
Kumar Gala120831.6%
Aurelien Jacquiot99981.3%
Mark Brown92081.2%
Evgeniy Polyakov79791.1%
David Daney76841.0%
Manuel Lauss73161.0%
Kuninori Morimoto71150.9%
Dmitry Kasatkin68800.9%
Jussi Kivilinna68610.9%
Ben Skeggs66990.9%
Axel Lin62510.8%
Jesse Gross59400.8%
Takashi Iwai51400.7%
Rob Clark49620.7%
Bart Van Assche47110.6%

Mark Brown regularly appears in the list of top contributors; for 3.3, he contributed large numbers of patches in the sound and multi-function device subsystems. Mauro Carvalho Chehab is usually better known for routing vast numbers of Video4Linux2 changes into the kernel; this time, he wrote a substantial portion of those patches himself. Axel Lin's contributions were also in the sound subsystem. So, in other words, the top three contributors to the 3.3 kernel were all working with multimedia which is, clearly, a area with a lot of development going on. Al Viro is not a media developer; his work was mostly cleaning up interfaces deep within the virtual filesystem layer. Tejun Heo continues to dig into code all over the kernel; this time around he fixed up the memblock allocator, made a number of process freezer improvements, reworked the CFQ block I/O scheduler, and made a number of control group changes.

In the lines-changed column, Greg Kroah-Hartman heads the list again. This time around, almost all of his changes were deletions; a lot of code was removed from staging this time around, often because it graduated to the mainline kernel. Stanislaw Gruszka made a lot of changes to the iwlegacy network driver. Mathieu Desnoyers made the list for having added the LTTng tracing subsystem; unfortunately, that code was subsequently removed and will not appear in the 3.3 release. Alan Cox made the top five for his work with the gma500 graphics driver and its move out of the staging tree.

Just over 200 companies have been identified as having supported contributions to the 3.3 kernel. The most active companies this time around were:

Most active 3.3 employers
By changesets
(None)132212.9%
Red Hat129012.6%
Intel8978.8%
(Unknown)5245.1%
Novell4504.4%
Texas Instruments4224.1%
IBM3573.5%
Wolfson Microelectronics2822.8%
Qualcomm2492.4%
(Consultant)2432.4%
MiTAC2402.3%
Broadcom2312.3%
Samsung2162.1%
Google2112.1%
Oracle1831.8%
Freescale1631.6%
Wizery Ltd.1111.1%
Parallels1081.1%
Renesas Electronics1041.0%
(Academia)1021.0%
By lines changed
Novell11391015.1%
Red Hat11133814.7%
(None)8113310.7%
Intel683789.0%
Texas Instruments356964.7%
Samsung272203.6%
EfficiOS259903.4%
Freescale222662.9%
(Unknown)193072.6%
(Consultant)185292.5%
IBM160262.1%
Wolfson Microelectronics136881.8%
Qualcomm117361.6%
Broadcom111801.5%
Mellanox88561.2%
Cavium79031.0%
Renesas Electronics75741.0%
Google71350.9%
MiTAC64910.9%
Nicira Networks60040.8%

This table has yielded few surprises in recent years; for the most part, the companies listed here remain the same from one cycle to the next. The continued growth in contributions from companies in the mobile and embedded areas is worth calling out, though. These companies are not just contributing support for their hardware; increasingly, they are also contributing to the core kernel and driving its evolution in the directions needed for their particular market. Once upon a time, it was common to hear that Linux kernel development was dominated by the needs of large enterprise deployments; few people make that claim now.

One other trend your editor has noted over time is a slow decline in the percentage of changes coming from people working on their own time. Here is a chart showing the numbers for all kernels since 2.6.25:

[Volunteer contributions]

The numbers are somewhat noisy, but the trend over the last four years suggests that volunteers are not contributing as much as they once were. It is unclear why that might be. One possibility is that the kernel has reached a point where there are few easy jobs left; the complexity of contemporary kernel development may be discouraging volunteers. Or it may simply be that anybody who demonstrates an ability to get code into the kernel tends not to remain a volunteer for long unless that is what they really want to be; all the rest end up getting hired. The truth may be a combination of both - or something else altogether.

Volunteer developers are important; they help tie the kernel to the wider community and some of them will become next year's professional developers and subsystem maintainers. A kernel that is unattractive to volunteers may find itself short of developers in the future. Thus far, there is nothing to suggest that any such developer shortage is happening; the 3.3 kernel, with 1,200 contributors, is as strong as any in that regard. That said, this trend is worth watching.

As a whole, though, the kernel remains a fast-paced and seemingly healthy project. The 3.3 release should happen sometime in mid-March, right on schedule. There is already a lot of interesting code lining up for merging in 3.4; expect to see another set of big numbers when the 3.4 version of this article appears in roughly 80 days time.

Index entries for this article
KernelReleases/3.3


to post comments

Statistics for the 3.3 development cycle

Posted Mar 8, 2012 7:48 UTC (Thu) by airlied (subscriber, #9104) [Link] (4 responses)

hey should Novell now be SuSE?

and is Greg's work going to LF now or unknown?

Statistics for the 3.3 development cycle

Posted Mar 8, 2012 8:47 UTC (Thu) by arnd (subscriber, #8866) [Link] (3 responses)

It's pretty clear from the numbers that Greg's contributions are counted for Novell/SUSE, but that also seems correct, given that he did most of those changes while he was still there.

Same thing for Kumar: while he is now at TI, all his patches that made it into 3.3 are still for Freescale.

Unfortunately, Linaro does not show up in the list, presumably because the assignees are mostly accounted to their employers. According to my count, there are 218 non-merge changesets from Linaro in 3.3, which would put us in front of Samsung (counting everyone who posts from @linaro.org, plus myself from arndb.de, and I'm probably missing a few more). I'm sure it would mean a lot to our beancounters if that could be fixed in the next statistics.

I would personally like to see merge changesets included in the stats as well, mostly because it I consider merging just as important as doing the patches to start with, but also because it would put me in the list. ;-)

Linaro

Posted Mar 8, 2012 14:15 UTC (Thu) by corbet (editor, #1) [Link]

I have asked around in the past, and the word I have gotten from Linaro assignees is that it's best to credit their work to their actual employers. If feelings have changed, the accounting can be changed too.

About merge commits - if we counted those, we'd have to let Linus back onto the list...:)

Statistics for the 3.3 development cycle

Posted Mar 8, 2012 14:58 UTC (Thu) by broonie (subscriber, #7078) [Link] (1 responses)

The statistics for people doing review that get published from time to time are also pretty interesting and probably at least as important from a global point of view.

Statistics for the 3.3 development cycle

Posted Mar 9, 2012 21:24 UTC (Fri) by patrick_g (subscriber, #44470) [Link]

Statistics for the 3.3 development cycle

Posted Mar 8, 2012 9:47 UTC (Thu) by intgr (subscriber, #39733) [Link] (1 responses)

> Greg Kroah-Hartman heads the list again. This time around, almost all of
> his changes were deletions; a lot of code was removed from staging this
> time around, often because it graduated to the mainline kernel

If it was simply files moving from one directory to another, wouldn't git's automagic rename tracking reduce these diffs to 0 lines?

Statistics for the 3.3 development cycle

Posted Mar 8, 2012 14:16 UTC (Thu) by corbet (editor, #1) [Link]

For whatever reason, staging graduations tend not to be done as renames. Instead, a new driver is added in mainline, followed by the removal from staging later.

Statistics for the 3.3 development cycle

Posted Mar 8, 2012 10:16 UTC (Thu) by dunlapg (guest, #57764) [Link] (2 responses)

The numbers are somewhat noisy, but the trend over the last four years suggests that volunteers are not contributing as much as they once were.

There's a lower percentage, but are they actually fewer on an absolute scale -- either in number of individual contributors, lines changed or # of changesets? Or is it possible that because there are more companies contributing (e.g., mobile device manufacturers), that it's just the relative percentage that's going down, and the actual amount contributed by volunteers is remaining steady, or even growing?

Statistics for the 3.3 development cycle

Posted Mar 8, 2012 11:28 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

How about instrumenting the kernel to give contribution by CPU time? Although unfortunately that would reward authors of slower code...

Statistics for the 3.3 development cycle

Posted Mar 10, 2012 2:27 UTC (Sat) by bronson (subscriber, #4806) [Link]

Maybe LOC divided by CPU time?

Although I guess this would cause everybody to needlessly unroll their loops.

Statistics for the 3.3 development cycle

Posted Mar 9, 2012 1:31 UTC (Fri) by laptop006 (guest, #60779) [Link] (1 responses)

The numbers are somewhat noisy, but the trend over the last four years suggests that volunteers are not contributing as much as they once were. It is unclear why that might be. One possibility is that the kernel has reached a point where there are few easy jobs left; the complexity of contemporary kernel development may be discouraging volunteers. Or it may simply be that anybody who demonstrates an ability to get code into the kernel tends not to remain a volunteer for long unless that is what they really want to be; all the rest end up getting hired. The truth may be a combination of both - or something else altogether.
One additional factor would be that employers see value in being acknowledged and request their employees contribute @company.com instead of personal mail accounts.

Statistics for the 3.3 development cycle

Posted Mar 17, 2012 16:47 UTC (Sat) by janschulz (guest, #82047) [Link]

It would be interesting, if the absolute value is also declining or if it's simple that the companies have increased their output (by hiring the volunteers :-) ) and the volume of changes from volunteers stayed the same.

Average age?

Posted Mar 17, 2012 10:54 UTC (Sat) by Celest (guest, #69372) [Link]

What about average age by kernel? Is it stable? If it's not maybe that suggest either the kernel needs more and more experienced programmers or that there is difficulty to recruit young programmers which could be a problem in a few years from now.

Statistics for the 3.3 development cycle

Posted Mar 17, 2012 17:18 UTC (Sat) by jspaleta (subscriber, #50639) [Link]

One comment about the volunteer participation.

You charged that as percentage of activity. Any way you can plot that in terms of a raw metric... like number of lines changed or number of commits.

I'd like to know if the decline in the percentage is actual volunterr falloff or is just showing up because the employed activity has increased significantly. Just graphing the percentage doesn't tell us that. It could be that both are going upwards in terms of the amount of actual work being done, its just employeed activity is rising faster. Subtle but important.

-jef


Copyright © 2012, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds