Live: Amazon Event Wednesday Probe Crashes Into Asteroid Prime Day 2: Oct. 11-12 Tesla AI Day Hurricane Ian Satellite Images Save on iPad Pro Refurbs Apple Watch Ultra Review EarthLink Internet Review
Want CNET to notify you of price drops and the latest stories?
No, thank you

Linux development: Too fast, too furious?

Is Linux moving too fast for its own good?

Is Linux pushing the envelope a bit too far, too fast? That's the question posed by Charlie Babcock's interesting article on the pace and scope of Linux development. Dan Frye argues that Linux represents a "first-of-a-kind developer community." Most people don't recognize this, thinking that all open-source projects are similar to Linux.

Not at all. The breadth of its community differs from most projects. Its ambition, too. This may actually be as much cause for alarm as it is for celebration:

Torvalds is pushing open-source development tactics to new extremes. As the kernel grows in size and complexity, the rapid-fire iterations are straining the capacity of the community of volunteers who test and debug them.

Yet Torvalds can't let off the gas, for two reasons. First, Linux can't afford to fall behind technically, or it'll lose ever-demanding business users. The new kernel, for example, has hooks to take advantage of the latest virtualization capabilities embedded in Intel and Advanced Micro Devices processors. Second, Linux needs to feed its developer community. New features keep coders from getting bored and moving on to other projects, and they attract new talent as coders age or drop out of the process.

Yet, as Charlie points out, this speed comes at the price of bugs. Open source has long prided itself on a community approach to bug resolution, but there's a certain velocity of development that outstrips the pace of bug resolution. We may already be there with Linux.

By erring on the side of speeding Linux's development, Torvalds is counting on the basic open-source principle that many users testing frequent releases of the code are more likely to catch defects than a more structured testing process. Linux bugs crop up constantly as additions to the kernel are found not to work on certain hardware or to clash with other software, either inside or outside the kernel. Developers who submit code are expected to troubleshoot bugs as they crop up, but often they don't.

Does it matter? After all, Linux has basically already made its name throughout a wide range of industries. A few bugs won't stop this, just as multitudinous bugs in Windows through the years have done little to halt its market penetration.

Which begs the question: what reputation does Linux want to have? Cutting-edge (and flaky) innovation or more modestly paced (and stable) innovation? Perhaps this suggests a false choice, but it's clear that there must be a significant amount of testing that goes into new code to match that expended on the development of the code itself. Microsoft could also develop at breakneck speed--writing code superfast is not the exclusive province of open source.

Where open source is supposed to excel, and usually does, is in bringing a myriad of viewpoints to bear on code, whatever the pace of development. That's what I'd like to see more of: disparate developers writing code for their disparate needs, and many eyeballs making shallow the bugs that inevitably arise.

What do you think?

Off-topic: Speaking of marrying development with quality control, you should download Radiohead's song "Reckoner." It is one of the most astounding songs I've ever heard. Beautiful with a slight touch of the downtrodden.