Weekly Edition
Return to the Kernel page
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Who wrote 3.0 - from two points of view
Linus Torvalds had hoped to release the 3.0 kernel after -rc6, but reality,
as is its wont, intervened; thus, 3.0-rc7 was released on
July 11. That probably is the last development release for 3.0, though.
Tradition dictates that we take a look at the contributor statistics for
this development cycle, which we will now do.
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:
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:
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 lookThe 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:
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:
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. (Log in to post comments)
Who wrote 3.0 - from two points of view Posted Jul 14, 2011 5:35 UTC (Thu) by jamesmrh2 (guest, #31680) [Link]
Why was 2.6.1 was so commonly missed?
Who wrote 3.0 - from two points of view Posted Jul 14, 2011 6:25 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
a combination of tracking problems and the fact that at the time many people were still using 2.4.x with little or no intention of _ever_ migrating to this scary new 2.6 thing.
Who wrote 3.0 - from two points of view Posted Jul 14, 2011 8:35 UTC (Thu) by neilbrown (subscriber, #359) [Link]
Partly 2.6.1 had a lot fewer commits to subsequent releases. Commit counts for the first 10 are:
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.
MS only slightly behind IBM, really? Posted Jul 14, 2011 8:07 UTC (Thu) by kragilkragil2 (guest, #76172) [Link]
But K. Y. Srinivasan is a Novell employee, right?
This could become a big headline so it is probably better to be safe.
MS only slightly behind IBM, really? Posted Jul 14, 2011 10:38 UTC (Thu) by patrick_g (subscriber, #44470) [Link] See the messages posted on LKML with mail addresses ending with "microsoft.com".
MS only slightly behind IBM, really? Posted Jul 14, 2011 14:14 UTC (Thu) by dgm (subscriber, #49227) [Link]
Wow. Should I take my skates in my next visit to hell?
Who wrote 3.0 - from two points of view Posted Jul 14, 2011 23:48 UTC (Thu) by mlankhorst (subscriber, #52260) [Link]
I respectfully disagree with the assertion that linux kernel development is hard for newcomers. However the thing that probably is lacking is the background knowledge every kernel hacker takes for granted. Following lwn for a few years helps a lot to learn about that. ;)
Who wrote 3.0 - from two points of view Posted Jul 15, 2011 19:28 UTC (Fri) by Julie (✭ supporter ✭, #66693) [Link] the thing that probably is lacking is the background knowledge I'm a bit confused by your comment, I had taken Jon's remark about it becoming difficult for new volunteer developers to participate as meaning the same as the above (newcomers don't _have_ that knowledge). Along with a couple of other potential difficulties: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? Following lwn for a few years helps a lot to learn about that. ;) Well, I can't agree with you here - I think that following LWN for a few years has become pretty _essential_ for learning about that ;-)
Who wrote 3.0 - from two points of view Posted Jul 15, 2011 20:07 UTC (Fri) by mlankhorst (subscriber, #52260) [Link]
With background knowledge I meant all the things you have to worry about in kernel space that might not happen in userspace. Atomics, interrupt contexts, rcu, the fact that not the whole world is a VAX^Wx86.
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. ;)
Microsoft, co-author of the Linux kernel Posted Jul 15, 2011 0:01 UTC (Fri) by david.a.wheeler (guest, #72896) [Link] 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 Posted Jul 15, 2011 2:47 UTC (Fri) by pr1268 (subscriber, #24648) [Link] 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!
Microsoft, co-author of the Linux kernel Posted Jul 15, 2011 6:21 UTC (Fri) by patrick_g (subscriber, #44470) [Link]
If I understand correctly Steve Friedl's technical discussion, it was only about the 200+ initial patchs to clean the MS driver before entering -staging.
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.
Microsoft, co-author of the Linux kernel Posted Jul 15, 2011 21:02 UTC (Fri) by leoc (subscriber, #39773) [Link] 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 Posted Jul 15, 2011 23:20 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Isn't it a bit weird that Microsoft is simultaneously contributing code to the Linux kernel **and** claiming that it violates their patents? 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.
Microsoft, co-author of the Linux kernel Posted Jul 17, 2011 9:59 UTC (Sun) by dgm (subscriber, #49227) [Link]
Look up TomTom vs. Microsoft. I may be instructive for you.
Microsoft, co-author of the Linux kernel Posted Jul 18, 2011 14:40 UTC (Mon) by dag- (subscriber, #30207) [Link]
Do you think Microsoft is getting a fair share ? I think they get more than they deserve, if they deserve anything at all. And no, we don't know how much they settle for patent-infringements with those large hardware vendors, but I don't think they deserve the tiniest bit.
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.
Microsoft, co-author of the Linux kernel Posted Jul 18, 2011 15:25 UTC (Mon) by giraffedata (subscriber, #1954) [Link] Do you think Microsoft is getting a fair share ? 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).
Microsoft, co-author of the Linux kernel Posted Jul 18, 2011 18:38 UTC (Mon) by leoc (subscriber, #39773) [Link] it wants its fair share of the result.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%.
Microsoft, co-author of the Linux kernel Posted Jul 19, 2011 9:12 UTC (Tue) by etienne (subscriber, #25256) [Link]
IANAL, but by contributing, don't they also give patent rights to "the Program"?
(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 Posted Jul 19, 2011 10:15 UTC (Tue) by dgm (subscriber, #49227) [Link]
IANAL either, but Microsoft is not distributing "the program" (the Linux Kernel) here. I don't know if the set of patches can be considered "the program" by themselves.
Can I download the kernel from somewhere in microsoft.com? Is there a git tree somewhere? All those could count as "distributing".
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||