Some 3.8 development statistics

The release of 3.8-rc7 suggests that the 3.8 development cycle is nearing its close. This has been a busy cycle indeed, with, as of this writing, just over 12,300 non-merge changesets finding their way into the mainline. That makes 3.8 the most active development cycle ever, edging out 2.6.25 and its mere 12,243 changesets. Like it or not, the time for the traditional statistics article has come around; this time, though, your editor has tried looking at things in a different way.

But, before getting to that, here's the usual numbers. As of this writing, some 1,253 developers have contributed code to the 3.8 kernel. The most active of those were:

Most active 3.8 developers

By changesets H Hartley Sweeten 426 3.5% Bill Pemberton 381 3.1% Philipp Reisner 238 1.9% Andreas Gruenbacher 210 1.7% Lars Ellenberg 146 1.2% Mark Brown 143 1.2% Sachin Kamat 135 1.1% Al Viro 127 1.0% Tomi Valkeinen 115 0.9% Wei Yongjun 114 0.9% Axel Lin 112 0.9% Johannes Berg 104 0.8% Kevin McKinney 103 0.8% YAMANE Toshiaki 101 0.8% Ben Skeggs 100 0.8% Paulo Zanoni 100 0.8% Ian Abbott 98 0.8% Mauro Carvalho Chehab 91 0.7% Andrei Emeltchenko 84 0.7% Daniel Vetter 82 0.7%

By changed lines Greg Kroah-Hartman 42448 5.8% Sreekanth Reddy 30415 4.2% H Hartley Sweeten 22581 3.1% Naresh Kumar Inna 19378 2.7% Larry Finger 16798 2.3% Paul Walmsley 16720 2.3% Jaegeuk Kim 13470 1.9% Rajendra Nayak 10398 1.4% David Howells 9946 1.4% Wei WANG 9775 1.3% Ben Skeggs 9395 1.3% Jussi Kivilinna 8784 1.2% Philipp Reisner 8596 1.2% Eunchul Kim 8533 1.2% Bill Pemberton 8293 1.1% Nobuhiro Iwamatsu 7795 1.1% Peter Hurley 7671 1.1% Laxman Dewangan 6898 0.9% Lars-Peter Clausen 6537 0.9% Lars Ellenberg 6320 0.9%

H. Hartley Sweeten's position at the top of the changeset list should be unsurprising by now; he continues the seemingly endless task of cleaning up the Comedi data acquisition drivers. Bill Pemberton has been working to rid the kernel of the __devinit markings (and variants), reflecting the fact that we all live in a hotplug world now. Philipp Reisner, Andreas Gruenbacher, and Lars Ellenberg all contributed long lists of changes to the DRBD distributed block driver; the resulting code dump caused block maintainer Jens Axboe to promise Linus that "Following that, it was both made perfectly clear that there is going to be no more over-the-wall pulls and how the situation on individual pulls can be improved."

On the lines-changed side, Greg Kroah-Hartman worked on the __devinit removal, but also removed over 37,000 lines of code from the staging tree. Sreekanth Reddy made a number of additions to the mpt3sas SCSI driver, Naresh Kumar Inna contributed the Chelsio FCoE offload driver, and Larry Finger added the rtl8723ae wireless driver.

Some 205 employers (that we know about) supported development on the 3.8 kernel. The most active of these were:

Most active 3.8 employers

By changesets (None) 1580 12.8% Red Hat 1112 9.0% Intel 1076 8.7% (Unknown) 917 7.4% LINBIT 595 4.8% Linaro 572 4.6% Texas Instruments 492 4.0% Vision Engraving Systems 426 3.5% Samsung 410 3.3% SUSE 310 2.5% IBM 287 2.3% Google 254 2.1% Broadcom 190 1.5% (Consultant) 171 1.4% Wolfson Microelectronics 161 1.3% Freescale 129 1.0% Free Electrons 128 1.0% Parallels 123 1.0% NVidia 121 1.0% NetApp 121 1.0%

By lines changed (None) 79954 11.0% Red Hat 60515 8.3% Intel 46326 6.4% Linux Foundation 43190 5.9% (Unknown) 41097 5.7% Samsung 36596 5.0% (Consultant) 33175 4.6% LSI Logic 30415 4.2% Linaro 29030 4.0% Vision Engraving Systems 26074 3.6% LINBIT 22487 3.1% Chelsio 21534 3.0% Texas Instruments 21276 2.9% IBM 14233 2.0% Broadcom 12236 1.7% Renesas Electronics 11570 1.6% NVidia 10369 1.4% Realsil Microelectronics 9797 1.3% Qualcomm 9345 1.3% SUSE 9139 1.3%

Red Hat remains in its traditional position at the top of the list — but not by much. Perhaps more significant is that some companies that have long shown up in the top 20 have fallen off the list this time; those companies include AMD and Oracle. Meanwhile, we continue to see an increasingly strong showing from companies in the mobile and embedded area.

What are they working on?

Many of the companies in the above list have obvious objectives for their work in the kernel; LINBIT, for example, is a business built around DRBD, and Wolfson Microelectronics is in the business of selling a lot of audio hardware. But if companies just focused on driver work, there would be nobody left to do the core kernel work; thus, a look at what parts of the kernel any specific company is working on will say something about how broad its objectives are. To that end, your editor set out to hack on the gitdm tool to focus on one company at a time. So, for example, from the 3.3 kernel onward (essentially, from the beginning of 2012 to the present), Red Hat's changes clustered in these areas:

Red Hat
%	Subsystem	Notes
34%	drivers/	9% gpu, 6% media, 6% net, 3% md
20%	fs/	3% xfs, 3% nfsd, 2% cifs, 2% gfs2, 1% btrfs, 1% ext4
14%	include/
8%	net/
8%	tools/
7%	arch/x86/
7%	kernel/
2%	mm/

(Patches touching more than one subsystem are counted in each, so the percentages can add up to over 100%.)

Red Hat puts a lot of effort into making drivers work, but also has a strong interest in the filesystem subtree. The large proportion of patches going into tools/ reflects Red Hat's continued development of the perf tool.

Intel's focus during the same time period is somewhat different:

Intel
%	Subsystem	Notes
66%	drivers/	22% net, 17% gpu, 4% scsi, 3% acpi, 3% usb
17%	net/	7% bluetooth, 5% mac80211, 3% nfc
13%	include/
7%	arch/x86
3%	fs/

Intel is a hardware company, so the bulk of its effort is focused on making its products work well in the Linux kernel. Improving memory management or general-purpose filesystems is mostly left for others.

Google's presence in the kernel development community has grown considerably in the last few years. In this case, the pattern of development is different yet again:

Google
%	Subsystem	Notes
27%	drivers/	4% net, 4% pci, 3% staging, 3% input, 3% gpu
22%	net/	11% ipv4, 5% core, 5% ipv6
21%	include/
11%	mm/
10%	fs/	6% ext4, 1% proc
8%	kernel/
6%	arch/arm
5%	arch/x86
4%	Documentation/

Google has an obvious interest in making the Internet work better, and much of its work in the kernel is aimed toward that goal. But the company also wants Android to work better (thus more driver work, ARM architecture work) and better scalability in general, leading to a lot of core kernel work. Much of Google's work is visible to the outside world in one way or another, so it is nice to see that the company has been reasonably diligent about keeping the relevant documentation current.

While we are on the subject of ARM, what about Linaro? This consortium is very much about hardware enablement, so it would not be surprising to see a focus on the ARM architecture subsystem. And, indeed, that's how it looks:

Linaro
%	Subsystem	Notes
47%	drivers/	5% pinctrl, 4% clk, 4% mmc, 4% mfd, 3% gpu, 3% media
36%	arch/arm
12%	include/
9%	kernel/
6%	sound/
5%	Documentation/
2%	fs/	1.5% pstore

Almost everything Linaro does is focused on making the hardware work better; even much of the work on the core kernel is dedicated to timekeeping. And while lots of work in Documentation/ is always welcome, in this case, it mostly consists of device tree snippets.

Finally, what about the largest group of all — developers who are working on their own time? Here is where those developers put their energies:

Unaffiliated developers
%	Subsystem	Notes
68%	drivers/	13% staging, 12% net, 10% gpu, 8% media, 6% usb, 2% hid
14%	arch/	5% arm, 2% mips, 2% x86, 2% sparc
8%	include/
6%	net/	2% batman-adv
3%	fs/
2%	Documentation/
2%	sound/
1%	kernel/

Volunteer developers, it seems, share a strong interest in making their own hardware work; they are also the source of many of the patches going into the staging tree. That suggests that, in a time when much of the kernel is becoming more complex and less approachable, the staging tree is providing a way for new developers to get into the kernel and learn the ropes in a relatively low-pressure setting. The continued health of the community depends on a steady flow of new developers, so providing an easy path for developers to get into kernel development can only be a good thing.

And, certainly, from the information found here, one should be able to conclude that the development community remains in good health overall. We are about to complete our busiest development cycle ever with no real signs of strain. For the time being, things seem to be functioning quite well.

---

(Log in to post comments)