Some 3.18 development statistics

As of the 3.18-rc6 release, 11,186 non-merge changesets have been pulled into the mainline repository for the 3.18 development cycle. That makes this release about 1,000 changesets smaller than its immediate predecessors, but still not a slow development cycle by any means. Since this cycle is getting close to its end, it's a good time to look at where the code that came into the mainline during this cycle came from. (For those who are curious about what changes were merged, see 3.18 Merge window, part 1, part 2, and part 3).

1,428 developers have contributed code to the 3.18 release — about normal for the last year or so. The most active developers were:

Most active 3.18 developers

By changesets H Hartley Sweeten 237 2.1% Mauro Carvalho Chehab 179 1.6% Ian Abbott 162 1.4% Geert Uytterhoeven 121 1.1% Hans Verkuil 100 0.9% Ville Syrjälä 98 0.9% Navin Patidar 98 0.9% Sujith Manoharan 83 0.7% Johan Hedberg 82 0.7% Eric Dumazet 77 0.7% Lars-Peter Clausen 75 0.7% Antti Palosaari 72 0.6% Fabian Frederick 71 0.6% Daniel Vetter 70 0.6% Florian Fainelli 70 0.6% Felipe Balbi 70 0.6% Benjamin Romer 68 0.6% Laurent Pinchart 64 0.6% Andy Shevchenko 62 0.6% Malcolm Priestley 61 0.5%

By changed lines Larry Finger 74831 10.2% Greg Kroah-Hartman 73298 10.0% Hans Verkuil 22266 3.0% Alexander Duyck 16617 2.3% Greg Ungerer 11981 1.6% Linus Walleij 10628 1.5% John L. Hammond 10269 1.4% Navin Patidar 8148 1.1% Philipp Zabel 7149 1.0% Martin Peres 6890 0.9% Mark Einon 6771 0.9% Mauro Carvalho Chehab 6520 0.9% Ian Munsie 5773 0.8% H Hartley Sweeten 5134 0.7% Alexei Starovoitov 4505 0.6% Yan, Zheng 4485 0.6% Antti Palosaari 4181 0.6% Roy Spliet 3785 0.5% Christoph Hellwig 3765 0.5% Juergen Gross 3745 0.5%

As is usually the case, H. Hartley Sweeten tops the by-changesets list with the epic task of getting the Comedi drivers into shape in the staging tree. Mauro Carvalho Chehab, the Video4Linux2 maintainer, did a lot of cleanup work in that tree as well during this cycle, while Ian Abbott's changes were, once again, applied to the Comedi drivers. Geert Uytterhoeven did a lot of work in the ARM and driver trees, while Hans Verkuil also made a lot of improvements to the core Video4Linux2 subsystem.

On the "lines changed" side, Larry Finger removed the r8192ee driver from the staging tree, while Greg Kroah-Hartman removed two other drivers from staging. Alexander Duyck added the "fm10k" driver for Intel FM10000 Ethernet switch host interfaces, and Greg Ungerer removed a bunch of old m68k code.

Some 200 companies (that we were able to identify) supported development on the code merged for 3.18. The most active of those were:

Most active 3.18 employers

By changesets (None) 1244 11.0% Intel 1238 10.9% Red Hat 863 7.6% (Unknown) 828 7.3% Samsung 523 4.6% Linaro 370 3.3% IBM 340 3.0% SUSE 326 2.9% Google 324 2.9% (Consultant) 321 2.8% Freescale 238 2.1% FOSS Outreach Program for Women 238 2.1% Vision Engraving Systems 237 2.1% Texas Instruments 199 1.8% Renesas Electronics 179 1.6% MEV Limited 162 1.4% Free Electrons 155 1.4% Qualcomm 141 1.2% Oracle 135 1.2% ARM 114 1.0%

By lines changed (None) 185247 25.3% Linux Foundation 73354 10.0% Intel 73168 10.0% (Unknown) 28460 3.9% Cisco 27939 3.8% Red Hat 27335 3.7% Linaro 23586 3.2% Samsung 19228 2.6% IBM 18194 2.5% SUSE 16736 2.3% Google 14110 1.9% (Consultant) 12455 1.7% Accelerated Concepts 11986 1.6% Texas Instruments 11305 1.5% C-DAC 8400 1.1% Pengutronix 8232 1.1% Freescale 7265 1.0% (Academia) 7076 1.0% Qualcomm 5398 0.7% Code Aurora Forum 5377 0.7%

(Note that the above table has been updated; the curious can see the original version published on this page here).

As is often the case, there are few surprises here. The level of contributions from developers working on their own time remains steady at about 11%, a level it has maintained since the 3.13 kernel. So it might be safe to say that, for now, the decline in volunteer contributions appears to have leveled out.

How important are volunteer contributions to the Linux kernel? Many kernel developers started that way, so it is natural to think that a decline in volunteers will lead, eventually, to a shortage of kernel developers overall. As it happens, the period starting with the 3.13 release (roughly calendar year 2014) saw first-time contributions from 1,521 developers. Looking at who those developers worked for yields these results:

Employer	Developers
(Unknown)	651
(None)	137
Intel	115
Google	37
Samsung	35
Huawei	33
IBM	32
Red Hat	25
Freescale	21
Linaro	17

All told, 733 first-time developers were identifiably working for some company or other when their first patch was accepted into the mainline. A large portion of the unknowns above are probably volunteers, so one can guess that a roughly equal number of first-time developers were working on their own time. So roughly half of our new developers in the last year were volunteers.

The picture changes a little, though, when one narrows things down to first-time developers who contributed to more than one release. When one looks at developers who contributed to three out of the last five releases, the picture is:

Employer	Developers
(Unknown)	48
Intel	24
(None)	21
Huawei	10
IBM	7
Samsung	6
Outreach Program for Women	6
ARM	4
Linaro	4
Red Hat	3
Broadcom	3

Overall, 126 new developers contributing to at least three releases in the last year worked for companies at the time of their first contribution — rather more than the number of volunteers. So it seems fair to say that a lot of our new developers are getting their start within an employment situation, rather than contributing as volunteers then being hired.

Where are these new developers working in the kernel? If one looks at all new developers, the staging tree comes out on top; 301 developers started there, compared to 122 in drivers/net, the second-most popular starting place. But the most popular place for a three-version developer to make their first contribution is in drivers/net; 25 new developers contributed there, while 20 contributed within the staging tree. So, while staging is arguably helping to bring in new developers, a lot of the developers who start there appear to not stay in the kernel community.

Overall, the pattern looks reasonably healthy. There are multiple paths for developers looking to join our community, and it is possible for new developers to work almost anywhere in the kernel tree. That would help to explain how the kernel development community continues to grow over time. For now, there doesn't appear to be any reason to believe that we will not continue to crank out kernel releases at a high rate indefinitely.

---

(Log in to post comments)