Are top Linux developers losing the will to code?

Core Linux developers are finding themselves managing and checking, rather than coding, as the number of kernel contributors grows and the contributor network becomes more complex.

Share

Core Linux developers are finding themselves managing and checking, rather than coding, as the number of kernel contributors grows and the contributor network becomes more complex.

That is the view of Greg Kroah-Hartman, maintainer of USB and PCI support in Linux and co author of online book Linux Device Drivers.

In the latest kernel release the most active 30 developers authored only 30% of the changes, while two years ago the top 20 developers did 80% of the changes, he said. Kroah-Hartman himself is now doing more code reviewing than coding. "That's all I do, is read patches these days," he said during a discussion at the Linux Symposium in Ottawa last month.

In theory the kernel development process involves changes going from the original author through a file or driver maintainer, to the maintainer of a major subsystem such as PCI or SCSI, to Andrew Morton for testing and finally to Linus Torvalds for a kernel release. But Kroah-Hartman said the process was much more complicated: "I tried graphing that, and that's not what happens. It's a mess. There's routing all over the place."

A graph of all the developers involved in the upcoming 2.6.22 release, as well as of the relationships of who reviewed whose patches, extends to a 40 foot print out with names in small type. The graph is on display at the Ottawa event.

The "mess" results in innovative features becoming integrated into Linux distributions much more quickly, according to Jonathan Corbet, author of the camera driver for One Laptop Per Child and another writer on Linux Device Drivers.

Previously, when developers maintained both "stable" and "development" kernels, it could have been two to three years before a feature made it from development to mainstream users. Today, by contrast, the newly released Fedora 7 distribution has the power saving tickless kernel functionality, which came out in the 2.6.21 kernel in April.

Enterprise Linux distributions that pick a single kernel.org release and maintain it for five to seven years are another reason for the complexities. Instead of waiting for a stable upstream release and then modifying it to include new functionality from development kernels, an enterprise distribution can support any of the 2.6 releases, which come out every two and a half months. Corbet said: "The patch loads carried by the distributors have shrunk quite a bit."

Find your next job with computerworld UK jobs