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.
IBM's Frye acknowledges, however, that Linux contributors queue up projects based on their own interpretation of customer needs. "You scratch your own itch," he says. And delivery dates tend to be vague.
Compare that to Microsoft, where thousands of developers pound out code for centrally planned releases under predetermined deadlines. Microsoft's road map calls for at least five operating-system releases in 2005 (Windows Server 2003 Service Pack 1, Windows Server 2003 and Windows XP for 32-bit/64-bit processors, Windows Server 2003 R2, and Windows Server 2003, Compute Cluster Edition), followed by Longhorn client in 2006, and Longhorn server in 2007.
Microsoft may be inconsistent in hitting its dates--some of the above products have already missed initial deadlines--but for IT professionals trying to plan business-technology projects, it's at least a timeline to pin on the wall. And Microsoft is learning to avoid getting bogged down by its own multiyear development projects. Increasingly, it's introducing new capabilities in the form of incremental feature packs, service packs, and releases like R2 that are something less than full-blown upgrades.
IBM's Frye sees no reason for the Linux camp to produce its own road map, arguing it's better to keep customers focused on "what's there today." Besides, he says, CIOs can get closed-door briefings from Linux distributors if necessary. Yet, his explanation seems a bit like a rationalization for a community-oriented development process that simply hasn't gotten around to centralized, long-term planning.
What's more, OSDL's micro-branch approach has raised questions among Linux programmers. "Without stable, reference milestones it will artificially increase the barrier to moving beyond dependence on a single vendor," one observer wrote in July in an online forum on LWN.net, a Web site focused on Linux happenings. "Innovation outside the corporate sponsored environment dries up ... Goodbye, Linux."
Torvalds and Morton remain open minded, and Torvalds says Linux 2.7 is "probably going to happen eventually," maybe within a few months.
It's conceivable that the best development methodology borrows from both models. Microsoft customers might benefit from the rapid, incremental updates favored by the Linux kernel managers, while Linux users would presumably find it easier to plan ahead with a road map similar to what Microsoft provides.
Why not have all three: A secure and stable kernel, regular updates with new functionality, and a three-year road map? Maybe Torvalds and Gates stand to learn something from each other.