Who wrote 3.0 - from two points of view
This kernel release inaugurates the beginning of the 3.x series of kernels. As has been mentioned many times here, there is nothing particularly special about the 3.0 release; it has been, in many ways, a relatively boring development cycle. But it still provides a good opportunity to look back over a longer period of time. But, before doing that, we'll start with this cycle, which has, as of 3.0-rc7, seen 9,007 changesets contributed by 1,110 developers. The kernel grew 113,000 lines in this development cycle - a relatively modest figure by contemporary standards.
The most active developers during this cycle were:
Most active 3.0 developers
By changesets K. Y. Srinivasan 343 3.8% David S. Miller 176 2.0% Dan Williams 149 1.7% Jonathan Cameron 119 1.3% Takashi Iwai 108 1.2% Mark Brown 91 1.0% Johannes Berg 84 0.9% Peter Zijlstra 80 0.9% Sage Weil 79 0.9% Tejun Heo 78 0.9% Joe Perches 77 0.9% Michał Mirosław 77 0.9% Konrad Rzeszutek Wilk 76 0.8% Jamie Iles 75 0.8% Alex Deucher 71 0.8% Artem Bityutskiy 69 0.8% Steven Rostedt 66 0.7% Mike Frysinger 63 0.7% Sujith Manoharan 62 0.7% Avi Kivity 58 0.6%
By changed lines Dan Williams 82466 9.1% Larry Finger 74643 8.3% Dmitry Kravkov 38960 4.3% Vasanthakumar Thiagarajan 33618 3.7% Mauro Carvalho Chehab 26815 3.0% Bing Zhao 25576 2.8% Ralph Metzler 19933 2.2% Takahiro Hirofuchi 19318 2.1% Chaoming Li 14743 1.6% Jonathan Cameron 14574 1.6% Chris Metcalf 12144 1.3% Luis R. Rodriguez 11443 1.3% Dave Jiang 11006 1.2% Wolfram Sang 9886 1.1% K. Y. Srinivasan 9709 1.1% Mark Brown 9127 1.0% Arend van Spriel 7667 0.8% Kenji Toyama 7528 0.8% Alan Cox 7449 0.8% Takashi Iwai 7410 0.8%
K. Y. Srinivasan topped the list of changeset contributors with a massive set of cleanups to the Microsoft HV driver in the staging tree; it's impressive to see how much cleanup less than 15,000 lines of code can require. David Miller made a lot of changes in the networking subsystem; some were warning fixes and such, while others were more substantial. Dan Williams contributed Intel's "isci" storage driver, merged in 3.0-rc6. Jonathan Cameron contributed a lot of work to rationalize the industrial I/O (iio) subsystem and prepare it for an eventual merge into the mainline. Takashi Iwai continues to do large amounts of work in the ALSA sound driver subsystem.
The isci driver put Dan Williams at the top of the "lines changed" column. Larry Finger's contribution is largely negative (in line counts - not in value): he removed the rt2860sta and rt2870sta drivers from the staging tree now that the mainline driver can replace them. Dmitry Kravkov appears due to a firmware update; the bnx2x driver is one of the few which still has firmware in the mainline kernel tree. Vasanthakumar Thiagarajan also removed a lot of code, mostly through the process of eliminating duplication between Atheros wireless drivers. Mauro Carvalho Chehab removed the obsolete Micronas drx397xD driver.
A total of 184 employers (that we were able to identify) participated in the 3.0 cycle; the most active among them were:
Most active 3.0 employers
By changesets (None) 1085 12.0% Red Hat 1000 11.1% Intel 839 9.3% (Unknown) 569 6.3% Novell 441 4.9% IBM 374 4.2% Microsoft 361 4.0% Atheros Communications 241 2.7% Texas Instruments 234 2.6% Broadcom 222 2.5% Oracle 187 2.1% AMD 162 1.8% Nokia 158 1.8% Fujitsu 154 1.7% 129 1.4% University of Cambridge 119 1.3% Analog Devices 118 1.3% (Consultant) 113 1.3% Samsung 103 1.1% Wolfson Microelectronics 103 1.1%
By lines changed Intel 163232 18.1% (None) 152840 16.9% Broadcom 61948 6.9% Red Hat 59079 6.5% Atheros Communications 53268 5.9% Marvell 31118 3.4% (Unknown) 29261 3.2% IBM 20587 2.3% Metzler Brothers Systementwicklung GbR 19933 2.2% Novell 19578 2.2% University of Cambridge 16969 1.9% Pengutronix 16207 1.8% Realsil Microelectronics 14876 1.6% Analog Devices 12998 1.4% Tilera 12257 1.4% Freescale 11637 1.3% Microsoft 11564 1.3% Texas Instruments 10802 1.2% Wolfson Microelectronics 10051 1.1% Samsung 9784 1.1%
There are few surprises here. Microsoft at 4% of the total changes is unusual; one assumes that presence will not be permanent: even the HV drivers can only need so much cleaning up. The percentage of changes from hobbyists continues to drop; whether that's a bad thing (the kernel is becoming increasingly unapproachable to volunteer developers) or a good thing (it's impossible for anybody who can hack the kernel to remain unemployed) is still not clear.
A longer-term look
The release of 3.0 provides as good an opportunity as any to look at the entire 2.6 series. Thanks to the BitKeeper history tree put together by Thomas Gleixner, it is possible to get detailed information back almost to the beginning of the 2.5 development cycle, which can be thought of as the set of -rc kernels leading up to 2.6.0. This information is far from complete, unfortunately. The 2.5.0 through 2.5.3 releases predate the BitKeeper transition, and thus appear as big patches from Linus. Even thereafter, a lot of early changes appear to have been contributed by the maintainer they passed through instead of the actual author; it took a while to establish the infrastructure to properly credit all work. Still, there is enough data there to work with.
The history from the beginning of the 2.5 development series covers about 9.5 years of development. During this time, some 291,664 changesets were contributed by 8,078 developers; those changes added 10.5 million lines of code. Here are the most active developers over that extended period:
Most active developers since 2.5.0
By changesets Andrew Morton 7638 2.6% David S. Miller 5203 1.8% Al Viro 3828 1.3% Greg Kroah-Hartman 3309 1.1% Russell King 3226 1.1% Alan Cox 2609 0.9% Ingo Molnar 2599 0.9% Stephen Hemminger 2535 0.9% Bartlomiej Zolnierkiewicz 2485 0.9% Linus Torvalds 2479 0.8% Christoph Hellwig 2429 0.8% Takashi Iwai 2414 0.8% Adrian Bunk 2306 0.8% Tejun Heo 2205 0.8% Thomas Gleixner 2205 0.8% Paul Mundt 2113 0.7% Dave Jones 2067 0.7% Randy Dunlap 1853 0.6% Ralf Baechle 1786 0.6% Johannes Berg 1770 0.6%
By changed lines Greg Kroah-Hartman 738134 2.3% Bartlomiej Zolnierkiewicz 553077 1.7% Andrew Morton 537737 1.7% Alan Cox 432023 1.4% Jaroslav Kysela 387649 1.2% Adrian Bunk 380691 1.2% James Bottomley 367435 1.2% Linus Torvalds 325954 1.0% Ralf Baechle 319859 1.0% Paul Mackerras 279454 0.9% Sam Ravnborg 270118 0.8% David S. Miller 254574 0.8% Christoph Hellwig 238749 0.8% Mauro Carvalho Chehab 232793 0.7% Uwe Kleine-König 215560 0.7% Russell King 209362 0.7% Benjamin Herrenschmidt 195707 0.6% Jeff Garzik 190724 0.6% Paul Mundt 185781 0.6% David Howells 183872 0.6%
It should be repeated that these numbers are highly approximate. For example, while Andrew Morton was indeed a prolific code contributor in the 2.5.x and early 2.6 days, he didn't write quite that many patches; a lot of patches from others that went through him lost their authorship information on the way. That information is generally present in the changelog - somebody could try to make a new repository with proper credits given some time - but, for now, we'll have to make do with fuzzy numbers. The per-employer numbers are necessarily even fuzzier - to the point that they are most likely not worth showing here. Suffice to say that, in general form, they resemble the numbers we have been showing for the last few years.
For those who are curious about just the post-2.6.0 kernels, the numbers don't change that much. Since 2.6.0, there have been 264,706 changesets contributed by 7,725 developers adding 8.7 million lines of code.
One other exercise with this data seemed interesting: a determination of who have been the most consistent contributors over those nine years and some. After running a script to track which developers contributed to each major release, twelve developers were found who had contributed to all 41 of them. Additionally, a handful of developers have gotten code into almost every release. The most consistent developers are:
Most consistent developers 2.6.0-3.0 Developer Releases Missed releases Linus Torvalds 41 David S. Miller 41 Greg Kroah-Hartman 41 Andrew Morton 41 Christoph Hellwig 41 Alan Stern 41 James Bottomley 41 Randy Dunlap 41 Russell King 41 Al Viro 41 Stephen Hemminger 41 Andi Kleen 41 Jens Axboe 40 v2.6.1 Jean Delvare 40 v2.6.4 Dave Jones 40 v2.6.35 Benjamin Herrenschmidt 40 v2.6.1 Jeff Garzik 40 v2.6.36 Ingo Molnar 39 v2.6.2 v2.6.5 Herbert Xu 39 v2.6.3 v2.6.5 Patrick McHardy 39 v2.6.2 v2.6.6 Dmitry Torokhov 38 v2.6.3 v2.6.4 v2.6.6 Rusty Russell 38 v2.6.1 v2.6.15 v2.6.39 Matthew Wilcox 38 v2.6.14 v2.6.36 v3.0 Dave Kleikamp 38 v2.6.26 v2.6.33 v2.6.37 Len Brown 38 v2.6.1 v2.6.17 v2.6.39 Oliver Neukum 38 v2.6.4 v2.6.14 v2.6.37 Wim Van Sebroeck 38 v2.6.4 v2.6.6 v3.0 Andrew Vasquez 38 v2.6.0 v2.6.1 v2.6.5 James Morris 38 v2.6.16 v2.6.37 v2.6.39 Neil Brown 37 v2.6.1 v2.6.2 v2.6.3 v2.6.6 Trond Myklebust 37 v2.6.1 v2.6.2 v2.6.8 v2.6.10 Paul Mackerras 37 v2.6.1 v2.6.3 v2.6.38 v2.6.39 Bjorn Helgaas 37 v2.6.3 v2.6.20 v2.6.39 v3.0 Tony Lindgren 37 v2.6.0 v2.6.1 v2.6.5 v2.6.20 Nicolas Pitre 37 v2.6.3 v2.6.4 v2.6.5 v2.6.23 Stephen Rothwell 37 v2.6.1 v2.6.2 v2.6.3 v2.6.7 David Howells 36 v2.6.1 v2.6.2 v2.6.3 v2.6.4 v2.6.6 Eric Sandeen 36 v2.6.1 v2.6.8 v2.6.11 v2.6.17 v3.0 Ralf Baechle 36 v2.6.1 v2.6.3 v2.6.4 v2.6.7 v2.6.38 Arjan van de Ven 36 v2.6.1 v2.6.3 v2.6.13 v2.6.14 v3.0 David Brownell 36 v2.6.33 v2.6.34 v2.6.37 v2.6.38 v3.0
Your editor, who only got changes into 32 releases during this time, knows what an accomplishment it is to consistently contribute to every release over such a long period of time.
But, then, creating the kernel and the development process we have over the
course of the last 20 years is an impressive accomplishment. There are
few development projects which have lasted this long, gone this far, and
have been more vital than ever. It has been fun to watch. It seems likely
that things will remain just as fun over the next 20 years - one could
argue that we have just begun.
| Index entries for this article | |
|---|---|
| Kernel | Releases/3.0 |
Posted Jul 14, 2011 5:35 UTC (Thu)
by jamesmrh2 (guest, #31680)
[Link] (2 responses)
Posted Jul 14, 2011 6:25 UTC (Thu)
by dlang (guest, #313)
[Link]
Posted Jul 14, 2011 8:35 UTC (Thu)
by neilbrown (subscriber, #359)
[Link]
2.6.1 680
and partly because Andrew Morton was getting a lot of patches attributed that didn't really belong to him. The counts for akpm patches in that first 10 are:
2.6.1 201
So about 25% of 2.6.1 and 2.6.2, and much less in the later releases.
Posted Jul 14, 2011 8:07 UTC (Thu)
by kragilkragil2 (guest, #76172)
[Link] (2 responses)
Posted Jul 14, 2011 10:38 UTC (Thu)
by patrick_g (subscriber, #44470)
[Link] (1 responses)
Posted Jul 14, 2011 14:14 UTC (Thu)
by dgm (subscriber, #49227)
[Link]
Posted Jul 14, 2011 23:48 UTC (Thu)
by mlankhorst (subscriber, #52260)
[Link] (2 responses)
Posted Jul 15, 2011 19:28 UTC (Fri)
by Julie (guest, #66693)
[Link] (1 responses)
the thing that probably is lacking is the background knowledge Following lwn for a few years helps a lot to learn about that. ;)
Posted Jul 15, 2011 20:07 UTC (Fri)
by mlankhorst (subscriber, #52260)
[Link]
When writing a bugfix for EFI I had to deal with early memory allocators and the transition to the full page allocator. For fun I looked up what allocators were used in the kernel. I came up with brk, e820, memblock, bootmem, xen's special brew, and the kernel's full page allocator. This list is probably incomplete. ;)
Posted Jul 15, 2011 0:01 UTC (Fri)
by david.a.wheeler (subscriber, #72896)
[Link] (10 responses)
Posted Jul 15, 2011 2:47 UTC (Fri)
by pr1268 (guest, #24648)
[Link] (1 responses)
Somewhat amusing, but very enlightening. Thanks for the blog entry. I also found Steve Friedl's technical discussion you linked fun—it's reassuring that the Linux kernel source isn't polluted with DWORDs or HANDLEs or all other types in ALL_CAPS. Phew!
Posted Jul 15, 2011 6:21 UTC (Fri)
by patrick_g (subscriber, #44470)
[Link]
Posted Jul 15, 2011 21:02 UTC (Fri)
by leoc (guest, #39773)
[Link] (7 responses)
Posted Jul 15, 2011 23:20 UTC (Fri)
by giraffedata (guest, #1954)
[Link] (4 responses)
Why? Because contributing code means you want to help Linux and claiming patent violation means you don't? I don't think it's that simple.
For one thing, Microsoft so far hasn't even prosecuted any of its patent claims. The main purpose for those claims seems to be to defend against insults against Microsoft of the form that a rag-tag bunch of people working for free put out something better than what the great Microsoft machine (or any other conventional software publisher) could make. The point of the claim is simply to say that Linux developers didn't do it alone.
Even if Microsoft were to sue over use of its patents in Linux, that wouldn't mean Microsoft doesn't like helping out Linux; only that it wants its fair share of the result.
Posted Jul 17, 2011 9:59 UTC (Sun)
by dgm (subscriber, #49227)
[Link]
Posted Jul 18, 2011 14:40 UTC (Mon)
by dag- (guest, #30207)
[Link] (1 responses)
Personally, if patents are there to protect corporate investments in research for the benefit of the general public, I do think the same general public should get full insight into patent settlements. I do think one (patent law) contradicts the other (closed patent-infringement settlements).
How can we make laws to protect the general public, if we don't know what backroom deals are made as a result of it? I also think if those deals were forced to be made public, support for patent law, especially in software development, will soon be impossible.
Posted Jul 18, 2011 15:25 UTC (Mon)
by giraffedata (guest, #1954)
[Link]
That's a little off-topic, since we're talking about whether there is some inconsistency or irony in Microsoft contributing code to Linux while claiming that Linux infringes some Microsoft patents. The only thing that would be relevant is whether Microsoft thinks it's getting its fair share (because if it does, then I must be wrong about Microsoft's motivation in making claims of Linux patent infringement).
Posted Jul 18, 2011 18:38 UTC (Mon)
by leoc (guest, #39773)
[Link]
If they are playing "fair", then why do they refuse to provide a list of the patents Linux allegedly violates? Seems to me that the only share they would ever consider fair is 100%.
Posted Jul 19, 2011 9:12 UTC (Tue)
by etienne (guest, #25256)
[Link] (1 responses)
Posted Jul 19, 2011 10:15 UTC (Tue)
by dgm (subscriber, #49227)
[Link]
Can I download the kernel from somewhere in microsoft.com? Is there a git tree somewhere? All those could count as "distributing".
Who wrote 3.0 - from two points of view
Who wrote 3.0 - from two points of view
Who wrote 3.0 - from two points of view
2.6.2 1252
2.6.3 1431
2.6.4 1407
2.6.5 1571
2.6.6 2020
2.6.7 2796
2.6.8 2650
2.6.9 4148
2.6.10 4510
2.6.2 477
2.6.3 294
2.6.4 415
2.6.5 345
2.6.6 618
2.6.7 764
2.6.8 191
2.6.9 102
2.6.10 143
(A quick look shows that the first few releases have several patches with
>>>> From: NeilBrown <neilb@cse.unsw.edu.au>
in the comment, but:
>>>> Author: Andrew Morton <akpm@osdl.org>
so I figure I should be in the exclusive "41-club" too!!)
MS only slightly behind IBM, really?
This could become a big headline so it is probably better to be safe.
See the messages posted on LKML with mail addresses ending with "microsoft.com".
MS only slightly behind IBM, really?
MS only slightly behind IBM, really?
Who wrote 3.0 - from two points of view
Who wrote 3.0 - from two points of view
1. Volunteers necessarily have less time than full-timers and therefore anything they swot up on at the time is likely to be dated when they come to try to put it into practice due to the current fast rate of development
2. The kernel's pretty much saturated with regards to experienced (sometimes full-time, paid) devs (at least in the areas of core work; I know Greg K-H is always looking for more contributors to staging).
What did you mean?
Who wrote 3.0 - from two points of view
These stats are so amazing that I just posted "Microsoft, co-author of the Linux kernel", to comment on this. You might find that article amusing.
Microsoft, co-author of the Linux kernel
Microsoft, co-author of the Linux kernel
Microsoft, co-author of the Linux kernel
What about the 300+ patchs during this 3.0 cycle? It can't be coding style work because that was done previously. Perhaps he need to write another article and change his previous conclusion.
Isn't it a bit weird that Microsoft is simultaneously contributing code to the Linux kernel **and** claiming that it violates their patents?
Microsoft, co-author of the Linux kernel
Microsoft, co-author of the Linux kernel
Isn't it a bit weird that Microsoft is simultaneously contributing code to the Linux kernel **and** claiming that it violates their patents?
Microsoft, co-author of the Linux kernel
Microsoft, co-author of the Linux kernel
Microsoft, co-author of the Linux kernel
Do you think Microsoft is getting a fair share ?
it wants its fair share of the result.
Microsoft, co-author of the Linux kernel
Microsoft, co-author of the Linux kernel
(For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. )
Microsoft, co-author of the Linux kernel