What's next for Linux? That's harder to answer than you might think. Linux developers haven't created a technical road map that outlines future releases of their open-source operating system. At the same time, changes in the way Linux gets developed have compressed kernel updates into shorter cycles. The result: Linux is getting better faster, but it's unclear what shape it will take in the years ahead.

The current version of the Linux kernel, 2.6, was released 12 months ago by its keepers at the Open Source Development Lab. The logical successor would be Linux 2.7, but neither Linus Torvalds, who oversees Linux kernel development at OSDL, nor Andrew Morton, OSDL's lead Linux kernel maintainer, are predicting what Linux 2.7 will contain or when work will begin.

"We don't have a road map," Morton says. "The direction the kernel gets taken is determined by those who contribute [to it.]" That approach stands in contrast to the one taken by Bill Gates' team at Microsoft, where Windows releases aren't only planned, but publicly disclosed, for the next three years.

Until recently, two Linux kernels were developed in parallel: a "stable" kernel such as Linux 2.4 to be used by distributors, and a developers' kernel that served as a basis for future versions. But Torvalds and Morton are experimenting with a different approach, one in which feature add-ons go directly to the stable kernel rather than a developers' offshoot that's two or three years in the making. So, Linux 2.6 now serves both purposes, which partly explains why there have been nine updates to it in 12 months. The latest snapshot is Linux 2.6.9, which rolls together fixes and improvements made over the past year.

The idea sprang from a July meeting of Linux developers in Ottawa, Canada. "One of the things that became obvious was that the stable kernels are getting more important than the development kernels," Torvalds says via E-mail. "Not just because they are important to users, but even developers liked it, since it avoids forward- [and] back-porting of fixes and features."

Morton describes the concept in terms of "micro-branches," where the Linux kernel gets updated every two or three months. "The need for large kernel branches has lessened because the kernel's quality has improved," he writes in a message. "Plus we've improved our processes and we now have more and better programmers, so our ability to absorb quite large changes into the 2- to 3-month 2.6 development cycle is proving to be acceptable."

It sounds great in theory: New features are added at quarterly intervals, giving users the dual advantages of stability and an ever-expanding feature set. But it's not without risk--the potential for vulnerabilities or unforeseen problems goes up. And, the shortened development cycle makes it even harder for technology professionals using Linux to plan around one major release that's, say, 18 months down the road.

Torvalds and Morton admit the approach is subject to change. "If at some point we observe that the current processes simply aren't producing an acceptable result for some reason then, yes, we might go back to the old scheme of having a major multiyear branch," Morton says. "Or we might do something else."

Morton refers people in search of a Linux road map to the influential technology companies that contribute resources and code to Linux, such as Bull, IBM, and Novell. But IBM defers, too. "We don't keep a separate road map," says Dan Frye, VP of development of IBM's Linux technology center in Beaverton, Ore.