Panel moderator Steven J. Vaughn-Nichols questioned OSDL's John Cherry, IBM's Greg Kelleher, Open Country's Laurent Gharda, Novell's Guy Lunardi, AMD's Steven McDowell, Intel's Waldo Bastian, and Red Hat's Jonathan Blanford. The first question addressed the differences between corporate and consumer desktop systems in regards to application support, systems management, and adoption strategy. All the panelists agreed that corporate and consumer desktops faced distinct enough differences to warrant different strategic thinking. While consumers choose their operating system for its applications, corporations choose their OS for its management infrastructure -- while not all desktops in an enterprise are identical, they are all standardized and thus synchronized and upgraded together. Most are centrally (and, increasingly, remotely) managed.
Next, the panel discussed niches where Linux has gained significant traction. The panel mentioned low-wage countries where licensing costs for other operating systems can rapidly burn through corporate budgets, and atypical markets, such as education in South America.
On the subject of accelerating desktop adoption, Bastian responded that Linux needs a set of common tools and interfaces for application development; while it is possible for independent software vendors to build applications that work on 90% of Linux desktops, it is still difficult to do so, and the remaining 10% need help as well.
Meeting that remaining need is the goal of the Portland project, named for the site (Portland, Ore.) of OSDL's desktop architects' meeting in December 2005. Portland is designing a toolkit-independent application program interface that can connect to GNOME, KDE, or any other desktop environment. McDowell announced that a preview release of the API specification and OSDL's reference implementation is available today. The plan is to keep the spec in beta for the time being, respond to feedback from participants, and launch the final release in June. Red Hat and SUSE both intend to ship an implementation of the Portland API.
Kelleher said that supporting multiple desktop environments is equal parts technical roadblock and source of confusion for ISVs, which adds up to a deterrent.
The panel then brought up the subject of device drivers, and what is required to accelerate the timely inclusion of new drivers into the Linux kernel. Cherry said that the main requirement is a central place to which hardware manufacturers can go for information and assistance. Lunardi added that commercial distros like SUSE and Red Hat can fulfill that role; they can get preproduction and sample hardware from manufacturers, while individual hackers often cannot.
At this point an audience member interrupted to ask what can be done to get non-GPL code included as part of the default install -- enterprises and large organizations, he said, cannot afford to repeatedly jump through the hoops of separate processes for certain hardware drivers in a large deployment. Here the panel disagreed; Blanford insisted that the community must demand open drivers, while Lunardi contended that it must deal with closed drivers and thus should take a pragmatic approach.
Finally, the panel addressed what OSDL is doing help the situation. Cherry described the organization's role as working with members where common problems need solutions. "We're often asked, 'When is OSDL making a distro?' he noted, "but that's not what we're doing." He ran down a list of OSDL's upcoming summits and events, including follow-up meetings with the desktop architects group, and additional meetings to consider issues such as power management and multimedia frameworks. Lunardi added that OSDL meetings have made progress and are continuing to do so, as they are led by the distros themselves, who have the greatest need to provide integration.
Moderator Vaughn-Nichols summed up his take on the future of Linux desktop integration by comparing it to the Unix wars of a generation ago. The Unix vendors lost out to Microsoft because they could never agree on anything, he said, but the Linux community understands that lesson -- that cooperation is mandatory -- and is committed to not repeating the same mistakes.