According to the study, about 10,000 changes are integrated into the kernel with each new version; since 2005, more than 6,100 programmers working for over 600 different companies have contributed patches to the kernel. After peaking in 2.6.30, the number of changes integrated per version has apparently decreased slightly. The study found that the rate has been 5.2 changes per hour, which is a little below the figure in the 2009 study. Since then, the source code of the Linux kernel has grown by 1.5 million lines.
More than 1,000 developers typically contribute changes for each kernel version, although the bulk of the work is done by a small number of developers. In the past five-and-a-half years, the ten leading developers contributed about 10% of the changes; the top 30 contributed almost 22%. According to the study, the most active developers include David S. Miller, Ingo Molnar and Al Viro; in the review period between 2.6.30 and 2.6.35, Paul Mundt, Johannes Berg and Peter Zijlstra were the top developers. The authors point out that Linus Torvalds is not among the top 30 developers: "Linus remains an active and crucial part of the development process; his contribution cannot be measured just by the number of changes made." This is also said to be true for other senior kernel developers who invest more time in review and management tasks.
Particularly at the beginning, the document also explains some of the methods used by the kernel hackers in the ongoing development of the Linux kernel. Readers of the Kernel Log will already be familiar with such things as the ongoing development of the series 2.6 kernel with its 3-month development cycle, with the stable series, and with other kernel branches.
The authors of the study also looked at the changes to the stable kernels. Most of the changes were integrated in series 32, which is a "Long Term Stable Release" that will be maintained over several years just like 2.6.27 before it; most stable kernels are typically discontinued once the next version has been established and has overcome any teething problems.
The authors of the study themselves point out that, for instance, the stated corporate affiliations of developers are approximate – developers may have changed employers or done personal work out of their offices. However, they consider the figures close enough to support a number of conclusions.
There are probably other areas where the evaluation methods create inaccuracies which may cause individual developers or companies to score well with a relatively small amount of contributed work. For instance, the kernel sources include various firmware images in the form of ASCII files. Some of these files are quite large and frequently modified in a way which makes the changes seem huge even if only a few minor details were modified. Two commits merged for 2.6.37 can serve as an example to illustrate this: The first patch is over 1 Megabyte in size and removes two proprietary firmware files for Broadcom hardware amounting to 22,000 lines of "code"; a 1.7 Mbyte patch integrates two newer firmware files and an extra third one, which then makes the kernel grow by 38,000 lines. There was no quick way of establishing how much similar changes to earlier kernel versions are reflected in the review.
Co-author Greg Kroah-Hartman probably benefited a little from the aging process of the staging area, which holds code that doesn't meet the kernel developers' or code programmers' quality standards. Reviewing this code is far less work than what's required for the other subsystems the developer maintains. Furthermore, there is more coming and going in the staging area than in the rest of the kernel – for instance, various drivers were removed only a few months after they were first integrated, simply because nobody looked after them. Occasionally, similar or identical code was added to the kernel several times via related Wi-Fi drivers and was, therefore, also considered several times in the evaluation.
The number of changes integrated, on the other hand, gives an advantage to developers who submit many small changes (which is usually encouraged) instead of a few large changes. While such weaknesses and inaccuracies can never be avoided completely, they are no reason to discount the value of the study; it provides many good indicators and insights if the focus is shifted away from the details.