Who wrote 2.6.33

By Jonathan Corbet
February 9, 2010

The release of the 2.6.33-rc7 prepatch indicates that this development cycle is headed toward a close, even if Linus thinks that a -rc8 will be necessary. As has become traditional, LWN has taken a look at some statistics related to this cycle and where the code came from.

As of this writing, 10,500 non-merge commits have found their way into 2.6.33 - fairly normal by recent standards. These changes added almost 900,000 lines while deleting almost 520,000 others; as a result, the kernel grew by a mere 380,000 lines this time around. According to the most recent regression list, 97 regressions have been reported in 2.6.33, of which 20 remain unresolved.

Some 1,152 developers contributed code to 2.6.33. The most active of those were:

Most active 2.6.33 developers

By changesets

Ben Hutchings 145 1.4%

Frederic Weisbecker 145 1.4%

Arnaldo Carvalho de Melo 138 1.3%

Luis R. Rodriguez 130 1.2%

Masami Hiramatsu 128 1.2%

Bartlomiej Zolnierkiewicz 124 1.2%

Eric Dumazet 108 1.0%

Alan Cox 105 1.0%

Manu Abraham 102 1.0%

Thomas Gleixner 101 1.0%

Eric W. Biederman 97 0.9%

Roel Kluin 91 0.9%

Alexander Duyck 88 0.8%

Paul Mundt 87 0.8%

Johannes Berg 80 0.8%

Wey-Yi Guy 77 0.7%

Alex Deucher 76 0.7%

Jean Delvare 73 0.7%

Al Viro 72 0.7%

By changed lines

Bartlomiej Zolnierkiewicz 206468 18.1%

Henk de Groot 50355 4.4%

Jerry Chuang 49627 4.3%

Ben Skeggs 37555 3.3%

Philipp Reisner 23182 2.0%

Eilon Greenstein 23123 2.0%

Tomi Valkeinen 22508 2.0%

Mike Frysinger 13116 1.1%

Ben Hutchings 12680 1.1%

Jakob Bornecrantz 11613 1.0%

Wu Zhangjin 11325 1.0%

Greg Kroah-Hartman 10468 0.9%

Rajendra Nayak 9978 0.9%

Manu Abraham 9625 0.8%

jack wang 9171 0.8%

Masami Hiramatsu 8973 0.8%

Alan Cox 7672 0.7%

David VomLehn 7331 0.6%

Arnaldo Carvalho de Melo 7217 0.6%

While some of the usual names appear at the top of this list, there are some newcomers as well. Ben Hutchings did a lot of work with network drivers, including the addition of the SolarFlare SFC9000 driver (which has several co-authors). Frederic Weisbecker has been active in a number of areas, adding the hardware breakpoints code, removing the big kernel lock from the reiserfs filesystem, and working with tracing and the perf tool. Arnaldo Carvalho de Melo's work is almost all with the perf events subsystem and the perf tool in particular. Luis Rodriguez continues to work all over the wireless driver subsystem, and with the Atheros drivers in particular, and Masami Hiramatsu's largest contribution is the dynamic probing work.

In the "lines changed" column, Bartlomiej Zolnierkiewicz continues to work in fixing up some wireless drivers in the staging tree, deleting a lot of code in the process; he also continues his IDE driver work. Henk de Groot added the Agere driver for HERMES II chipsets, Jerry Chuang added the Realtek rtl8192u driver, and Ben Skeggs added much of the Nouveau driver.

Contributions to 2.6.33 came from 182 employers that your editor was able to identify. The most active of those are:

Most active 2.6.33 employers

By changesets

(None) 1535 14.6%

Red Hat 1223 11.6%

Intel 1011 9.6%

(Unknown) 868 8.3%

IBM 500 4.8%

Novell 390 3.7%

Nokia 319 3.0%

(Consultant) 316 3.0%

Fujitsu 204 1.9%

Texas Instruments 199 1.9%

Atheros Communications 169 1.6%

(Academia) 166 1.6%

AMD 165 1.6%

Oracle 136 1.3%

Analog Devices 130 1.2%

Renesas Technology 126 1.2%

Pengutronix 125 1.2%

HP 124 1.2%

Solarflare Communications 123 1.2%

By lines changed

(None) 304895 26.7%

(Unknown) 109716 9.6%

Red Hat 92991 8.1%

Broadcom 54272 4.8%

Realtek 49951 4.4%

Intel 46302 4.1%

Nokia 37505 3.3%

Novell 27235 2.4%

IBM 26783 2.3%

(Consultant) 25845 2.3%

Texas Instruments 24232 2.1%

LINBIT 23247 2.0%

Analog Devices 19677 1.7%

VMWare 16045 1.4%

Samsung 15707 1.4%

Solarflare Communications 15054 1.3%

JiangSu Lemote Corp. 11439 1.0%

AMD 9218 0.8%

Universal Scientific Industrial Co. 9194 0.8%

As usual, Red Hat maintains its position at the top of the list, but others are gaining; we may yet see a day when Red Hat is just one of several major contributors. Some readers may be surprised to see Broadcom near the top of the list, given that this company's reputation for contribution is not the best. The truth of the matter is that Broadcom has several developers contributing to various drivers in the networking and SCSI subsystems; it's only in the wireless realm that the trouble starts.

For the fun of it, your editor typed the "changeset percent" numbers for the last ten releases into a spreadsheet and got this plot:

[Contributor
percentages]

The percentages are surprisingly stable over the course of almost three years. The most obviously identifiable trends, perhaps, are the steady increases in the contributions from Intel and Nokia.

All told, the process continues to function smoothly. The occasional complaint about certain companies not fully participating in the process notwithstanding, the picture is one of hundreds of companies cooperating to a high degree to create the Linux kernel despite their fierce competition elsewhere. The significant percentage of code coming from developers working on their own time shows that Linux is not just a corporate phenomenon, though. We have built a development community which is able to incorporate the interests and work of an astonishingly wide variety of people into a single kernel.

As always, thanks are due to Greg Kroah-Hartman, who has done a great deal of work to reduce the size of the "(Unknown)" entries in the tables above.

Index entries for this article
Kernel	Releases/2.6.33

to post comments

Who wrote 2.6.33

Posted Feb 11, 2010 6:27 UTC (Thu) by dlang (guest, #313) [Link] (6 responses)

I'm impressed that the amount of changes from people known to not be paied to work on the kernel remains so high.

Who wrote 2.6.33

Posted Feb 11, 2010 12:35 UTC (Thu) by bmr (guest, #33167) [Link] (5 responses)

Isn't it more that they are not known to be paid than that they are known not to be paid? Not sure I've seen anything that clarified this one way or another so sorry if I missed something!

"(None)"

Posted Feb 11, 2010 15:20 UTC (Thu) by corbet (editor, #1) [Link] (4 responses)

The "None" figure is people who are known to be working on their own time - they have told us so. Those we don't know about are the "Unknown" number instead.

"(None)"

Posted Feb 12, 2010 0:21 UTC (Fri) by nevets (subscriber, #11875) [Link] (3 responses)

How many are college students? When people think of working on their own time, you can imagine an engineer that is doing one job during the day and hacking on Linux at night.

Even though, I started as that type of work with Linux, today I bet a lot of it is professors using Linux as a learning tool and then those students get hooked on working on the kernel. It's not that they are not paid to do it, it may more likely be that they are not yet paid to do it.

I believe that Frederic Weisbecker falls under this category.

"(None)"

Posted Feb 12, 2010 2:04 UTC (Fri) by eparis123 (guest, #59739) [Link] (2 responses)

It's not that they are not paid to do it, it may more likely be that they are not yet paid to do it.

I've personally been in this category and been contacted by Greg, where I replied being in the 'enthusiast' group. Yes, I'm a college student, but I did all my patches without any outside influence.

How come you want to consider this as 'paid' work?

"(None)"

Posted Feb 12, 2010 3:06 UTC (Fri) by nevets (subscriber, #11875) [Link] (1 responses)

I don't consider it paid work. I was just saying that the OP was surprised that the "(None)" was still at the top. My point is that I'm not surprised. I would be surprised if most of those in the "(None)" group were not college students.

I'm actually quite happy to see that number so high, for the same reason I used the word "yet". Because I know with such a large knowledge base coming up, there will be no limit to how far Linux will go. This "(None)" group will soon be in the paid to do Linux group, and hopefully there will be more inspiring new engineers joining that "(None)" group where it will always be at the top.

"(None)"

Posted Feb 17, 2010 20:45 UTC (Wed) by nlucas (subscriber, #33793) [Link]

I'm one in the "(None)" group too, with a one-liner patch to fix a
regression on a driver. Although I've done it as a paid worker, the kernel
is not what I work with. Just come across that bug when trying to understand
why a piece of hardware we use stopped working.

I don't consider that as paid kernel work, just a one time contribution by
sheer luck.

I'm sure there are lots of people like me in that situation.

Who wrote 2.6.33

Posted Feb 11, 2010 8:20 UTC (Thu) by vblum (guest, #1151) [Link]

is the Novell dent this time a one-time phenomenon?

Who wrote 2.6.33

Posted Feb 11, 2010 10:44 UTC (Thu) by hppnq (guest, #14462) [Link] (5 responses)

As usual, Red Hat maintains its position at the top of the list

It is not at all at the top of the list. Maybe you mean "at the top of the list where we discard the four times bigger contribution[*] of people who can't be identified as associated with a particular company".

[*] Actual lines of kernel code changed.

Who wrote 2.6.33

Posted Feb 11, 2010 20:45 UTC (Thu) by dlang (guest, #313) [Link]

"None" is people known not to be working on a companies dime.

"Unknown" is the people who can't be identified as associated with a particular company.

Who wrote 2.6.33

Posted Feb 16, 2010 23:30 UTC (Tue) by roelofs (guest, #2599) [Link] (3 responses)

[*] Actual lines of kernel code changed.

Er...did we overlook the title of the graph? Specifically the "changesets" and "company" parts? ;-)

(Also see the upstream clarification about what "(None)" means.)

Greg

Who wrote 2.6.33

Posted Feb 17, 2010 11:22 UTC (Wed) by hppnq (guest, #14462) [Link] (2 responses)

Er...did we overlook the title of the graph? Specifically the "changesets" and "company" parts? ;-)

In the graph the large contribution that cannot be attributed to specific company-sponsored efforts is indeed completely discarded, when compared to the list, where the two categories "None" and "Unknown" are at the top of the list (I mentioned lines of code changed).

(Also see the upstream clarification about what "(None)" means.)

I observed that "number three in the list" is not "top of the list", especially since the article recognizes the "None" contribution as "significant".

Who wrote 2.6.33

Posted Feb 18, 2010 19:19 UTC (Thu) by efexis (guest, #26355) [Link] (1 responses)

"where the two categories "None" and "Unknown" are at the top of the list"

Out of context, they yes do look to be at the top of the list. Within context, however, the collection referred to as '(none)' is merely above the list, for purpose of completeness if nothing else, as the list that is being discussed is as the title says: "Most active 2.6.33 employers"... as '(none)' isn't an employer, it can't be top of the list of active employers, which means that RedHat is at the top. By definition.

As with '(unknown)', it's highly unlikely that all the changes under '(unknown)' are from a single employer, so it's unlikely that from that collection there is going to be someone who can top RedHat in the list.

"I observed that "number three in the list" is not "top of the list""

Nup, you observed that you can be top of one set without being top of all sets :-)

Who wrote 2.6.33

Posted Feb 19, 2010 8:07 UTC (Fri) by hppnq (guest, #14462) [Link]

If what you are thinking is that one should take the "None" and "Unknown" categories out of the list titled "Most active employers", because we are only considering positively identified company contributions to the Linux kernel, then let's skip the step where I recommend basic courses in English, logic and statistics and just conclude that that's the scenario I was pointing out in my original comment.

If you insist on leaving the academic trail and you want to play word games: see the title of the bloody article. Consider taking those courses. Skip set theory.

If you were joking -- and I honestly hope you are -- I had a good laugh! Especially the "above the list" was a brilliant trouvaille.

It's too early to count

Posted Feb 11, 2010 17:10 UTC (Thu) by proski (guest, #104) [Link] (1 responses)

The bugfixes that go into late release candidates may be small in size, but they are sometimes big in impact. Some of those fixes require a lot of work and patience.

It's too early to count

Posted Feb 12, 2010 2:07 UTC (Fri) by eparis123 (guest, #59739) [Link]

Indeed. I guess a classification by bugfixes count is very worthwhile, where
a single line of change can be the result of days of frustration.

Who wrote 2.6.33

Posted Feb 11, 2010 20:11 UTC (Thu) by daney (guest, #24551) [Link] (2 responses)

I wonder if more complete data can be made available from you analysis. Some might want to know how close to the top 19 they were. Could you make the top 100, or perhaps all, available as a separate article?

Who wrote 2.6.33

Posted Feb 11, 2010 20:44 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

I believe the scripts that generate these tables are freely available, grab them and the git tree and you can run your own analysis.

there's not a link in this article to the analysis scripts, but I think they've had one in past articles (Corbett, would it make sense to try and include a link to the scripts in all the articles?)

Who wrote 2.6.33

Posted Feb 12, 2010 11:58 UTC (Fri) by patrick_g (subscriber, #44470) [Link]

There is also this site : http://www.remword.com/kps_result/
The numbers are a little bit differents. I don't know why.

Who wrote 2.6.33

Posted Feb 12, 2010 8:25 UTC (Fri) by atl (guest, #5255) [Link] (3 responses)

The truth of the matter is that Broadcom has several developers contributing to various drivers in the networking and SCSI subsystems; it's only in the wireless realm that the trouble starts.

Not really :( Their MIPS SOC solutions for stbs are completely missing from the main kernel, which is very annoying when you are stuck with 2.6.12 "vendor" kernel and no way to move forward.

Who wrote 2.6.33

Posted Feb 13, 2010 18:47 UTC (Sat) by mb (subscriber, #50428) [Link] (1 responses)

> Their MIPS SOC solutions for stbs are completely missing from the main kernel,

Which arch are you talking about? BCM63xx?

Broadcom stuff

Posted Feb 15, 2010 10:14 UTC (Mon) by atl (guest, #5255) [Link]

Not really. I'm talking about bcm74xx. These are chipsets used in iptv, cable and satellite stbs. The kernel claims to be 2.6.12 but it really is 2.6.12 + patched in kgdb, random mips patches from 2.6.15, jffs patches from "i'dont know where" (it is different that 2.6.12 and 2.6.15), mtd patches, and basically standard crappy vendor code all over the place. Most of the files in different directories are copy and pasted with minor changes (io register definitions, etc).

ls linux-2.6.12-brcm-4.2/arch/mips/brcmstb

Kconfig brcm93563 brcm97038c0 brcm97112 brcm97312 brcm97315bbx brcm97319 brcm97328 brcm97400b0 brcm97401c0 brcm97403a0 brcm97455 common
brcm93560 brcm97038 brcm97110 brcm97115 brcm97314 brcm97317 brcm97320 brcm97329 brcm97401a0 brcm97402b0s brcm97440a0 brcm97456 lib
brcm93560b0 brcm97038b0 brcm97111 brcm97118a0 brcm97315 brcm97318 brcm97327 brcm97400a0 brcm97401b0 brcm97402s brcm97440b0 brcm97456b0

The patch to 2.6.12 can be downloaded here:
http://hdtvbg.com/foss/linux-stb-4.2.patch.gz

The sad part is that all this is accompanied by 40k binary driver that only have couple of ioctl so it doesn't really need to be binary but because of this crap I can't really port their stuff to something more recent.

Atheros are just as stupid

Posted Feb 15, 2010 19:18 UTC (Mon) by dion (guest, #2764) [Link]

Heh, funny you should mention it, due to the utter pig-headedness of Atheros I'm now stuck with Linux 2.6.15 with broken ECMP support on the ar7240 MIPS SoC.

It's absolutely incredible that Atheros and Broadcom feel that it's ok for them to profit from Linux support for their chips, yet they insist on NDAs and refusing to do anything to document their chips.

Someone with a vicious lawyer ought to educate Atheros about the GPL in a way that reminds them that a lot (most?) of their SoCs are sold to people who like to put Linux on them and proper Linux support only helps them sell more chips.

What could Atheros or Broadcom possibly hope to gain from keeping their datasheets secret?

Who wrote 2.6.33

Posted Feb 18, 2010 7:12 UTC (Thu) by DYN_DaTa (guest, #34072) [Link] (3 responses)

Once again: Canonical, Where Art Thou?. Oh, well ...

Who wrote 2.6.33

Posted Feb 18, 2010 9:27 UTC (Thu) by mangoo (guest, #32602) [Link] (1 responses)

They have far more contributions in userspace, which is also needed.

Who wrote 2.6.33

Posted Feb 19, 2010 0:52 UTC (Fri) by jengelh (subscriber, #33263) [Link]

Let's look at userspace thus. (Yes, it's a little older.)

So RedHat's customers subsidise Ubuntu -- how is this a bad thing?

Posted Feb 19, 2010 1:57 UTC (Fri) by xoddam (subscriber, #2322) [Link]

I have no problem with Canonical funding and promoting a nice free desktop OS from off-the-shelf free parts other people have developed, rather than directly funding those parts.

I use Ubuntu on the desktop and CentOS on the server, mostly. But my economic activity (via my employer and hosting providers) pays real money to RedHat, whereas I never gave a penny to Canonical or the tiny-but-heroic CentOS team.

Free software is an ecosystem, not a mere labour exchange.

Who wrote 2.6.33

Posted Feb 18, 2010 21:48 UTC (Thu) by bzolnier (guest, #28067) [Link]

Thanks for "Changes contributed by company" graph -- it is very informative.

Would it be possible to get a similar graph for "Signoffs contributed by company"?