Linux stakeholders have a general idea of what's coming. Device support, high-end servers, and embedded systems are areas of future focus, Morton says. At IBM, virtualization for Linux-on-Intel, hardware-level security, workload management, and Power processor architecture are on the Linux to-do list. And Red Hat Systems provides a 12-month view into its product-development plans. Due in 2005 are a version of Red Hat's Enterprise Linux based on the 2.6 kernel, plus security and RHN monitoring.
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.